[HN Gopher] Pacing: the most important skill in startup engineer...
___________________________________________________________________
Pacing: the most important skill in startup engineering leadership
Author : hasheddan
Score : 45 points
Date : 2024-03-12 14:48 UTC (2 days ago)
(HTM) web link (danielmangum.com)
(TXT) w3m dump (danielmangum.com)
| arminiusreturns wrote:
| > The key to finding the right balance is honesty, transparency,
| and constant measurement.
|
| The first two are payed only lip service in all but the most
| exceptional startups. My last one there was so little honesty and
| transparency despite the outward appearance of such being
| polished to seem as if it was.
|
| I think the problem is the boards, especially when you have an
| engineer heavy founder set, those savvy investor types run
| circles around the C-suite. I literally had my CTO tell me when
| complaining about some big partners "there is a power imbalance
| and they know it" as an excuse to not even try to stop their bad
| behavior!
|
| Add in sleazy lawyers and it's a recipe for culture disaster.
| dilippkumar wrote:
| Just want to point out how nice it is to read justified text. It
| absolutely makes a huge difference.
| kemiller2002 wrote:
| Unless you're dyslexic, then you might not be reading it at
| all.
| hartator wrote:
| > As an avid endurance runner, I am very familiar with the
| importance of good pacing, and the perils of doing it poorly. If
| you go out too hard in a race, you are destined to crash and
| burn. On the other hand, if you start too slow, you may have too
| much time to make up before the end of the race. At every moment
| throughout a run, you need to be in-tune with your body,
| understanding the limits of how hard you can push given your
| current position in the race.
|
| I know it's not a popular opinion, but I hate sport metaphors for
| business. They make no sense even with tiniest scrutiny.
|
| Isn't endurance running as mean of transportation completely
| disrupted by bicycle, cars, or public transportation? Wouldn't
| endurance running even with perfect pace actually kill you if you
| don't stop?
| swatcoder wrote:
| What do you mean by disrupted here? And don't you have to stop
| riding a bicycle or driving a car eventually too?
|
| Endurance _racing_ , which is what they're actually talking
| about as they care about "making time", is a sport that also
| appears almost identically in cycling and driving. And in all
| those contexts it's just an elective hobby that helps paint a
| picture about pacing, goals, and burnout. It's not about
| transportation at all.
|
| But as far as running goes for transportation, it's 500,000
| year old technique that ultimately requires no manufacturing or
| contraptions and runs on foraged berries. Other options may
| creep into use for a millenia or two, but it's not going
| anywhere.
| pflenker wrote:
| A metaphor aims to illustrate a specific point better. It does
| not aim to be a full equivalent of the thing itself. This does
| not only apply to sports metaphors.
|
| Sports metaphors are common because the are usually easy to
| grasp.
|
| And I think in this specific case it makes a ton of things to
| not pick any metaphor, but an endurance run as opposed to ... a
| sprint, which is currently THE most common (albeit only
| implicitly used)sports metaphor in the software engineering
| industry.
| 082349872349872 wrote:
| Once upon a time, while hiking, an elderly fellow shared his
| three rules for multi-day hikes:
|
| - look backwards from time to time (so you'll know from where
| you came in case it's necessary to backtrack)
|
| - know where you think you should be after X hours hike, and
| compare your actual surroundings to ensure they match
| sufficiently with the deduced location
|
| - if you do get lost, never leave your drainage (when things
| are going poorly, don't make them worse)
|
| We later learned he was a program manager for the
| https://en.wikipedia.org/wiki/Rockwell_X-30 , and not only did
| we use all three rules literally when got lost about half a
| week later, I've used them metaphorically on all manner of
| software projects since.
| jakelazaroff wrote:
| Could you elaborate? I'm not sure what it means to apply
| these to software development (at least, 1 and 3).
|
| Also, what does drainage mean in this context?
| Jtsummers wrote:
| Retrospection, orientation, and I'll re-phrase the last one
| as "maybe stop digging that hole before it's so deep you
| can't climb out." (I'm guessing on that last one, not heard
| drainage used that way either.)
|
| Retrospection: Periodically examine what you've made and
| how, identifying the good, the bad, and the ugly. Try to
| structure your future work to produce more of the good and
| less of the bad and ugly.
|
| Orientation: Periodically check to see if you're making
| what you meant to make, is what the customer wanted you to
| make, and is _still_ what the customer wants you to make.
|
| "Stop digging": Ok, you have a bit of code that's almost
| right, but it fails some tests. Add an extra conditional
| here, copy/paste a function there, change a constant in the
| copied code, voila problem solved. Oh, failing another
| test, let's repeat, and repeat. In the end you have 10x (or
| more) the necessary code and anyone looking at it would,
| rightfully, mock you for copying a 10 line function
| multiple times to make "render_with_black_background",
| "render_with_blue_background",
| "render_with_green_background", etc. when you, maybe, could
| have made it a parameter (with a default value) instead.
| It's related to the previous two in the sense that if
| you're actually retrospecting and periodically orienting,
| you probably won't dig the hole too deep.
| nickjj wrote:
| > if you do get lost, never leave your drainage (when things
| are going poorly, don't make them worse)
|
| I read drainage as a water source and it might still work. In
| general rivers or any type of running water will have a
| higher chance of leading to another human being vs not with
| no other context.
|
| You could relate that to software development by emulating
| running water in the sense that progress is being made if
| you're moving in a direction that's not fighting the current
| or stagnating. This could be taken in a number of different
| ways such as working on things that naturally let you make
| progress instead of fighting against it or getting lost and
| going in circles.
| throwway120385 wrote:
| In the mountains a drainage gives you a set of guard rails
| and a set of bounds on a topographical map. Sometimes
| walking a half a mile in a direction gives you perspective
| on a peak or another feature that you can identify on the
| map based on the shape and then you can shoot bearings and
| locate yourself. Also if you follow water downhill you'll
| reach successively larger bodies of running or pooled water
| until you reach the sea.
|
| I've been on a hike or two with my wife where knowing where
| the running water is versus where it should be saved us
| several hours of being lost.
| thih9 wrote:
| What is drainage in this context?
| dasil003 wrote:
| Any metaphor can have holes poked in it. Same as all narrative
| are reductive and leave out innumerable salient facts. The map
| is not the territory. It doesn't mean analogies aren't useful.
|
| As a cross-country mountain biker and long-time software
| engineer, there is a hell of a lot of analogues between mental
| and physical endurance even if the activities are completely
| different.
| ilaksh wrote:
| Overall excellent point about pacing. But I have to point out an
| issue:
|
| "Missing a goal is not necessarily signal that your pace is too
| slow. In fact, it often means that you simply didn't plan well
| for a more difficult portion of the race."
|
| He did try to stretch the metaphor by mentioning inclement
| weather, but overall, software engineering is not similar to
| running a race.
|
| For some features, you literally do not know what could be around
| the corner. It could be a huge crevasse. There is no known
| accurate map of the area. Your plans are more like wishes you
| make in front of a well before you throw a coin in.
|
| If you had a good map then you wouldn't necessarily be doing
| software development. It would be more like just configuration
| and deployment.
|
| That is why I would like to add that if you run into what seems
| like a roadblock, don't blame the staff. They didn't put it
| there. Give them time to figure out how to dismantle it or go
| around.
___________________________________________________________________
(page generated 2024-03-14 23:01 UTC)