[HN Gopher] How individual contributors get stuck (2017)
___________________________________________________________________
How individual contributors get stuck (2017)
Author : glennericksen
Score : 168 points
Date : 2022-06-28 13:53 UTC (9 hours ago)
(HTM) web link (www.elidedbranches.com)
(TXT) w3m dump (www.elidedbranches.com)
| [deleted]
| efficax wrote:
| To me the biggest blocker is unclear requirements in the edge
| cases (this is maybe the final 10-20% of a project). You get to a
| point where it's unclear which of a few options to move forward
| with, in a way that will affect the UX of the feature, and this
| isn't mapped out in the story or the wireframes. So you have to
| go back to product and get direction, which often takes a lot of
| time (product loves to meet, to measure, to a/b test, in my
| experience they hate to just make a decision). In smaller orgs
| this is often easier, the engineer can just decide, and then make
| a note w/ product to follow up later with a final decision that
| we'll follow back with later, and only if it seems better than
| whatever decision was made. In a big org, process gets in the way
| here.
| rgbrgb wrote:
| Good point, but why can't you do the same thing in a big org?
| Of course there are different kinds of orgs, but in my
| experience doing what you described (just make a decision
| yourself and note it to stakeholders later) is always the most
| expedient. The only ways I've seen it go wrong is if that
| decision entails a lot of work (choose the simple thing) or you
| get overly committed to a direction and don't actually want to
| come back to iterate it.
|
| The slowest-to-ship engineers are the ones who refuse to do a
| bit of design thinking or copywriting when they hit the
| inevitable unspecced case and instead think "not my job!". It
| really is your job to find all of those cases, but going a bit
| outside your domain to suggest the simplest solution (usually
| by coding it up) rather than spinning up the meeting merry-go-
| round is going to make you 2x more valuable than the engineer
| who just gets blocked.
| BlargMcLarg wrote:
| >Of course there are different kinds of orgs
|
| And a lot of those orgs do 'spinning up the meeting merry-go-
| round' as a baseline.
|
| I would love to find solutions, run them through other
| developers to make sure it won't be a disaster to maintain,
| and present them. But more often than not, anything beyond 5
| minutes of investment isn't worth the personal time
| investment given the organization. There are just too many
| hurdles.
|
| From my experience, most developers are still treated like
| idiot savant children capable of doing the one thing the
| 'helicopter parent' managers can't do.
| allenu wrote:
| I've encountered this so many times in my career, having worked
| on a lot of UI that product and UX designers came up with.
|
| At first I would spot potential missing pieces in the UI
| designs as they were proposed and would work with PM and design
| to come up with workarounds. I did also notice that PMs like to
| set up meetings to go over them, but often the specific details
| don't have a massive impact on the actual usability, but still
| a decision has to be made.
|
| In the early stages, so much of the product design is
| hypothetical to everyone. Even though you could drill down on
| specific details, nobody really wants to, unless you're the
| engineer who has to implement it. This often means it's hard to
| communicate precisely the design issue you need to address (and
| often, it's "only" an issue because the implementation has to
| choose an option).
|
| So, what I eventually would do over time was just work as far
| as I could until I had a concrete issue I could demo and
| explain easily to PM and design. Before I'd bring up the issue
| to them, however, I'd come up with a couple of best-effort
| solutions. (Not completed, although sometimes I could hack
| something together.) Usually I'd prefer one solution over the
| other. I'd present both options and give enough pros/cons to
| show why my preferred was better, but I wouldn't tell them
| necessarily that that was my preference, just the facts about
| what you get with it over the other.
|
| More often than not, product and design would just go with my
| recommendation. It's true that they really don't care about a
| lot of nitty gritty details, and often they have bigger fish to
| fry, so it's a great way of making progress.
|
| Obviously, there are some tricks to how you present the pros
| and cons to ensure you get your way, but obviously as a senior
| member of the team, you need to do what you think is best of
| the team and overall product.
| dieselgate wrote:
| This is a great article. In just looking at the lists of
| where/why ICs get stuck I feel enabled to grow as an IC.
| tunesmith wrote:
| > Helping other people instead of doing their assigned tasks
|
| Hehe, that's totally me. That one is really hard, though, because
| it's also arguably my job. Keeping other people unblocked is the
| best way to accelerate the team's overall output.
| pc86 wrote:
| We've taken to reassigning tickets when getting consulted on
| something and while I was pretty skeptical about the practice,
| it actually works pretty well. Coworker needs your help, so
| reassigns ticket 1234 to you. You know the ticket's assigned to
| you, they can move on to something else without constantly
| getting questions about the status, etc. Some tools are better
| at tracking time from multiple people on one ticket than
| others, so YMMV.
| ramesh31 wrote:
| >Sloppy looks like never getting sidetracked from the main
| project but never finishing anything completely, letting the
| finishing touches of the last project drop as you rush heedlessly
| into the next project.
|
| But Sloppy gets promoted while Stuck gets a "meets expectations".
|
| The key is in knowing when it's ok to be sloppy.
| adamius wrote:
| Good list. Its not unlike what I keep on the wall. I call it the
| potholes on the road. Whenever I feel like I'm stuck I try to
| remember to check the list. If its on the list I can relax a bit
| and to at least whatever otherwise useful extent forgive myself.
|
| This is how I stay on target and finish things. Perfection is
| only a justifying set of sweet lies that prevent finishing.
| dang wrote:
| Discussed at the time:
|
| _How Do Individual Contributors Get Stuck? A Primer (2017)_ -
| https://news.ycombinator.com/item?id=21169212 - Oct 2019 (83
| comments)
| lamontcg wrote:
| Some of these aren't necessarily bad.
|
| Sometimes when you're rebuilding the entire world its good to get
| distracted with jumping into some firefighting (even when "not on
| call") to get the dopamine hit of fixing a problem and being the
| goddamn hero.
|
| Then you can go back in two or three days or something to being
| Sisyphus.
|
| As the currently top voted comment points out that sometimes
| going off and doing other things can also help "unstick" you when
| you're feeling overwhelmed and burned out on one particular
| problem.
|
| It is actually kind of annoying to have a manager that ALWAYS
| wants you to be not distracted and ALWAYS perfectly focused on
| whatever is your top priority. That just gets exhausting after
| awhile, even if you technically agree that's the highest priority
| thing you should be working on at any given time.
| BlargMcLarg wrote:
| If only management would use their inflation in statistics to
| realize, if monthly contributions are consistent, there is
| nothing to worry about having a bad week.
| paganel wrote:
| Maybe a little meta, but when did the programmers -> individual
| contributors transition happen?
|
| Until a few years ago saying and writing "programmers" on forums
| like HN was still prevalent, and then, after a certain moment, I
| started seeing "ICs" more and more.
| kevinventullo wrote:
| "IC" encompasses programmer-adjacent roles like design, data
| science, roles closer to hardware. Also, even within software
| engineering, many aspects of the role do not involve
| programming per se: design, documentation, rollout planning,
| etc.
| corrral wrote:
| I've assumed it's a FAANGism. This is the only place I see the
| term used.
| stonemetal12 wrote:
| It is wider than just HN. At work, IC tends to be the term used
| by management. Mostly I think it came with "agile" and the
| attempt to stop "not my job" responses to getting stuff done.
| twblalock wrote:
| It's nothing to do with Agile. It's just a short way to say
| "employees who are not managers."
| 121789 wrote:
| I think it's the complete opposite - IC was created
| (rightfully IMO) by technical contributors to reject the idea
| that the only way to progress in your career and make a
| bigger impact is to go into management. It's just the
| recognition of a parallel career path
| jack_h wrote:
| If that was its purpose it failed. Many (most?) companies
| have no progression path other than management, but they'll
| happily call you an IC.
| RC_ITR wrote:
| Well, it was easy to be part of a team (even if you weren't
| really) when you were physically collocated with said team.
|
| But now, unless you _really really_ are part of that team, you
| are an IC. Programming, by nature of what it is and who does
| it, always had a bunch of IC 's, but now the phenomenon is more
| clear due to remote (which is something I recommend a lot of
| people on here thing about as they design their career).
| saddd wrote:
| I'm not sure what you mean. In a corporate job ladder, anyone
| who isn't strictly a manager and writes at least SOME code is
| classified as an IC. That's not to say that there are no
| managers who also write code, though.
| RC_ITR wrote:
| Yeah and I'm saying, from experience, people 'fall into'
| being a manager by nature of informal mentorship
| relationships that happen in person, but now you have to
| more aggressively 'opt-in' to be a manager.
| DragonStrength wrote:
| Everywhere I have worked, "IC" meant "not a people manager,"
| so no, it is not a term which can be substituted with
| "programmer."
| codingdave wrote:
| That isn't what IC means - it means "not management". You do
| your job, whatever that may be and whomever you may be teamed
| with, but do not have direct reports.
| davidthewatson wrote:
| I find it interesting that IC once meant, "integrated
| circuit" in the same culture which exists here now, but
| decades earlier. Having been on both sides of the false
| dichotomy that's drawn between management and individual
| contributors, my experience has been that great ICs don't
| necessarily need management and great management are often
| great precisely because of their individual contribution.
| It's paradoxical that perfection may emerge despite the
| fact that product, process, and people exist on a spectrum
| that produces so much conflict. One wonders whether product
| perfection is, in fact, emergent with respect to the
| conflict around people and process.
| RC_ITR wrote:
| Yeah and I'm saying, from experience, people 'fall into'
| being a manager by nature of informal mentorship
| relationships that happen in person, but now you have to
| more aggressively 'opt-in' to be a manager.
| astrange wrote:
| If you're a high level IC you can have people temporarily
| assigned to you, though; it's assumed that you could be
| doing managing if you wanted to, and sometimes you just
| can't do your projects by yourself.
| [deleted]
| marcosdumay wrote:
| IC is anybody that isn't management. Programmer means anybody
| that creates programs.
|
| This article did indeed confuse the two (probably because the
| author manages programmers but does not program herself), but
| they are independent concepts. All combinations of IC/not IC
| and programmer/not programmer exist.
| yrgulation wrote:
| Terminology copied from large code factories and assembly
| lines, such as google, facebook and other modern day Chryslers
| and Fords. Beats "worker" or "resource".
| itsmemattchung wrote:
| > Noticing how people get stuck is a super power, and one that
| many great tech leads (and yes, managers) rely on to get big
| things done
|
| Taking it one step further. Noticing how you -- yourself -- get
| stuck is a superpower. But it's hard...really hard.
|
| When I get stuck on troubleshooting an issue, I can sometimes
| fall in this trap that my wife calls the "blackhole." I obsess
| over it. I cannot rid the problem from my mind. My 2.5 year old
| even sees it in my eyes ; she'll glance up at me, wondering where
| I am.
|
| Before reaching this "blackhole" state, I can start to feel when
| I get tunnel vision.... at which point, I distance myself from
| the problem.
|
| Hands off the keyboard.
|
| Go for a walk.
|
| And almost EVERY damn time, I'm able to solve the problem easily.
| Just needed a fresh pair of (my own) eyes, a moment to get
| "unstuck".
| [deleted]
| agumonkey wrote:
| I'm trying to gather thoughts on how to approach problem
| solving or long task in a way to chunk steps just right to
| match my natural stamina.
|
| There are a few things that make working ok if not delightful:
|
| - generating ideas to try
|
| - having an idea of the space covered
|
| - keeping track of progress (even a well marked dead end feels
| good, it's done work) .. bookmarks in a way
|
| - placing little context notes on bookmarks so when you jump in
| you're ready to plug your mind in more easily
|
| - crafting a bed to try an idea with very low friction. Take a
| good amount of time to devise your bench/lab and then iterate
| smoothly.
|
| - all of this with the notion of quickly converging toward
| what's good and trim what's not
|
| I'm failing hard at it right now but I still believe it's one
| good way.
| cheschire wrote:
| This is why I start wordle in the morning, and if I don't feel
| "close" after 3 guesses, I put it away until the evening.
| scrumbledober wrote:
| this sounds much less stressful than my wife and I doing it
| before bed every night and realizing most nights "oh shit
| it's 11:45 we have to do wordle in the next 15 minutes!"
| fatnoah wrote:
| >Before reaching this "blackhole" state, I can start to feel
| when I get tunnel vision.... at which point, I distance myself
| from the problem.
|
| I learned to do this as well after many late nights of making
| no progress, only to basically solve the issue in the shower or
| on the way to work the next day.
| itsmemattchung wrote:
| I definitely feel its one of the lessons I learn over and
| over again. The brain has a great way to convince us: "Just a
| little more longer... you'll figre it out.
|
| Sometimes grit is just NOT the answer.
| bradstewart wrote:
| This is so, so true. At this point, I'm not sure it's a
| lesson I'll _ever_ learn.
|
| Despite experiencing the "shower solution" repeatedly over
| the years, I _still_ cannot get myself to let go and take a
| step back until I 'm literally too exhausted to continue.
|
| When I'm thinking clearly, it's obvious the optimal answer
| is "take a break". But when I'm "in the stuck", taking a
| break seems like the worst possible answer. Every. Time.
| jasonladuke0311 wrote:
| > At this point, I'm not sure it's a lesson I'll ever
| learn.
|
| Same here. I've found myself going down rabbit holes so
| ridiculously orthogonal to the actual problem that I was
| embarrassed for myself.
| barrysteve wrote:
| We're so convinced consciousness is doing the solving
| that more is always better.
| datavirtue wrote:
| Winner.
| itsmemattchung wrote:
| There _must_ be some psychological or clinical term for
| this: to be stuck in some fixated state that prevents
| forward progress unless a break is actually taken.
| wiredfool wrote:
| It's one of the themes of Zen and the Art of Motorcycle
| Maintenance. A book on programming if I've ever read one.
| hyperpallium2 wrote:
| It may be that "being stuck" is "uploading the problem
| and interconnections"... a necessary pre-condition for
| the walk, the shower etc to work.
|
| It could be that one is stuck longer than necessary for
| uploading... or it could be that one is only able to let
| go when uploading is complete...
|
| What evidence would show which it is?
| bradstewart wrote:
| You're on to something here.
|
| If I had some signal that indicated "sufficient
| information uploaded, algorithm running" it'd be easy to
| stop. But the (obvious) problem is that signal is,
| usually, the discovery of the solution. Which happens
| well after all the being stuck.
|
| There is something comforting about accepting that
| banging my head against a wall might just be a
| requirement of figuring the thing out, though.
| datavirtue wrote:
| At the first sign of inhibited progress I go do something
| else. It's like a reflex action now. It's almost painful
| how much I have to rely on my subconscious mind to develop
| software. Conscious mind stops working optimally...have to
| quit. It's not worth energy expenditure or stress.
| bcbrown wrote:
| My office used to be right by the local art museum, and I was a
| member. Whenever I felt stuck, I'd go take a half hour to look
| at art, and usually a solution would quickly come to mind.
| itsmemattchung wrote:
| I'm seriously intrigued by how the unconscious mind works as
| it relates to problem solving. Anybody here have
| recommendations to literature that digs into this beautiful
| phenomenon of taking breaks/walks resulting in the answer
| manifesting itself?
| LanceH wrote:
| Obsessing over authentication and authorization. I've known no
| greater time sink.
| Aqueous wrote:
| When I've gotten stuck it's usually because the previous engineer
| completely screwed up the data structure design and in doing so
| made it impossible to change. This boxes me in because I can't
| implement the feature in an architecturally sound way without a
| significant refactor.
|
| This has happened to me many times.
| Trasmatta wrote:
| Oh God this is where I'm at now. A series of questionable
| decisions over the past 7 years have now solidified our
| codebase into a horrible set of patterns that make even adding
| a single new database column that we need to feed to the
| frontend a Herculean task. It's so demotivating.
| pacaro wrote:
| This is where the fun begins for some of us. Coming in to a
| codebase that has been growth focused for 10 years but now
| needs to be rock solid and yet also allow the next 10 years
| growth.
| Trasmatta wrote:
| It would be fun if that's what I was tasked with doing, but
| instead I'm doing feature development, and being asked why
| this small simple things are taking so long...
| pacaro wrote:
| Yeah, and that sucks for sure. And it's a measure of
| management quality as to how they incorporate your
| feedback on this
| Trasmatta wrote:
| Yeah definitely. I've been giving feedback about this for
| around 2 years and there's some movement, but there
| doesn't seem to be anyone at the company driving
| architectural decisions, so nothing really seems to be
| going anywhere.
| ska wrote:
| [narrator] The previous engineer was themself, 18 months ago.
|
| I turns out that usually (not universally!) the problem isn't
| that the previous person did a bad job, but rather that they
| made a set of tradeoffs that made sense at the time, and make
| less sense now.
|
| Or it could be that you work with uncharacteristically
| incompetent engineers, but that's not the first place to look.
| cecilpl2 wrote:
| Please take this the right way, but blaming your predecessors
| is not a productive mindset, nor is it really the topic of this
| post.
| mgkimsal wrote:
| But there are times when it's a valid explanation of the
| current situation people find themselves in.
|
| When you get questioned about "why isn't this done yet?
| $previousDevX said it would only take a day!"
|
| ... what words/phrasing can you use that don't - implicitly
| or explicitly - 'blame' your predecessor in some fashion?
|
| And as @ervine pointed out, there may be times when I'm the
| predecessor, but was hamstrung by time deadlines earlier and
| now have far more debt to unravel than existed 6 months
| earlier. But even then... while _I_ am the predecessor,
| someone else made the decision to cut my effort short
| earlier, and we all still live with that decision now.
| theptip wrote:
| It's true, but kind of a non-sequiteur. The post isn't
| about getting blocked in general, it's about the internal
| reasons/ways that individuals tend to get stuck on their
| own.
|
| Furthermore, if the story you tell yourself is "I'm great,
| the main thing that I get stuck on is when others mess up
| and I need to fix it", then even if that is in fact true,
| you miss an opportunity for acquiring self-knowledge by
| investigating the patterns of self-inflicted stuckness.
|
| Put differently, maybe the mistakes of others are outside
| your control, but your own weak spots (everybody has them,
| it's fine) are within your control to improve upon. And one
| of the more important jobs of a good manager is to use the
| 30k ft view to help individuals to spot and work on
| improving these patterns.
| ervine wrote:
| Eh, sometimes the predecessor is me, the fact that a large
| refactor remains between me and the end goal is still a
| blocker.
| CamouflagedKiwi wrote:
| It may well be that you're entirely correct, and this is what's
| happened. But another dev out there might say the same thing in
| a different situation, and the answer could be that they've
| gotten stuck refactoring other people's code that didn't need
| to be.
| VyseofArcadia wrote:
| > Helping other people instead of doing their assigned tasks
|
| This leads you to another sort of stuck, though. When an engineer
| needs help, but everyone who could help is too busy with their
| assigned tasks.
|
| I've been there. It sucks. You end up calling it a "blocker" and
| then managers get involved to unblock you which leads to
| resentment from the people/teams who were told to drop their
| other important stuff to help you, and then they half-ass it and
| it doesn't do much good anyway.
|
| Then again, this was when I was at the large org whose chart in
| comic form has all the teams pointing guns at each other.
| dskloet wrote:
| Comic: https://bonkersworld.net/organizational-charts
| samrocksc wrote:
| This is really nice...plenty to think on.
| voidmain wrote:
| It's possible to take anything good to excess. For every piece of
| advice, _someone_ probably needs to hear the opposite.
|
| But... if your manager is displeased with _most ICs_ for
| brainstorming, considering edge cases, researching possible
| solutions, refactoring, helping other people, testing, and
| automating... you should probably consider working somewhere
| else. These are all things the industry does too little of, and
| that my company puts significant effort into encouraging and
| rewarding. They are also important steps in growing into
| (technical or people) leadership roles. And they are nowhere near
| the top of the list of things that people waste time on.
| sanitycheck wrote:
| "1. Finish the last 10-20% of a project"
|
| This isn't getting stuck, the "last 20%" of a project takes 80%
| of the time. This is when you start to get the REAL requirements.
| ClumsyPilot wrote:
| exactly, usually it turns out the final 20% are actually >50%
| bpicolo wrote:
| It's when the bits that were "unknown unknowns" start to
| matter.
| sgtnoodle wrote:
| A lot of problems worth solving have a long tail of 9's to
| chase down, i.e. 99.999%
|
| Self driving cars is one of those projects.
| D-Coder wrote:
| Early in my career, I learned that if I wasn't sure how
| something was supposed to work, I needed to ask sooner rather
| than later, because it was unlikely to get clearer all by
| itself. No matter how ignorant it made me look.
| giantg2 wrote:
| I wonder how I get stuck and how to fix it. I wonder where these
| people with the superpowers to identify it are in my org.
| kelseyfrog wrote:
| In my 15 years of experience, I see people get people get stuck
| when they need to ask for help in much greater prevalence than
| the other categories. This is often coupled with a perspective
| drawn from toxic meritocracy - those who work harder get more
| done. They are often sides of the same coin.
|
| What it looks like practically is a team member whose tasks start
| to slip, mutate, and start to get called done without anything
| actually delivering the goods. It takes a supportive team or an
| active manager to stop and recognize what's happening.
|
| Depending on the individual, either ego or fear are the primary
| drivers of the action and while everyone has their own demons to
| wrestle, those who make great contributors can recognize their
| demons and take steps to confront them. Mid devs often don't,
| can't, or won't.
___________________________________________________________________
(page generated 2022-06-28 23:01 UTC)