9 ms·

How individual contributors get stuck (2017)

219 points by glennericksen 4y ago

itsmemattchung 4y ago
> 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".
- fatnoah 4y ago
  >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 4y ago
    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 4y ago
      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 4y ago
        > 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.
      - itsmemattchung 4y ago
        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 4y ago
        It's one of the themes of Zen and the Art of Motorcycle Maintenance. A book on programming if I've ever read one.
        pramodbiligiri 4y ago
        I've heard it being called Focussed Mode and Diffuse Mode, as described here - https://fs.blog/focused-diffuse-thinking/ https://fs.blog/focused-diffuse-thinking/ Bret Victor links to this book called Psychology of Invention in the Mathematical Field, which talks a lot about this too - http://worrydream.com/refs/Hadamard%20-%20The%20psychology%20of%20invention%20in%20the%20mathematical%20field.pdf http://worrydream.com/refs/Hadamard%20-%20The%20psychology%2...
      - barrysteve 4y ago
        We're so convinced consciousness is doing the solving that more is always better.
        datavirtue 4y ago
        Winner.
      - hyperpallium2 4y ago
        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?
    - datavirtue 4y ago
      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.
- cheschire 4y ago
  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 4y ago
    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!"
    - PebblesRox 4y ago
      Thank you for the reminder! I didn't do the Wordle this morning and would have missed it today if not for your comment :)
- agumonkey 4y ago
  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.
- deleted 4y ago
  [deleted]
- bcbrown 4y ago
  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 4y ago
    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?
    - bcbrown 4y ago
      It's not scientific literature, but I got the inspiration from the book "Pragmatic Thinking and Learning".
    - ruraljuror 4y ago
      Barbara Oakley talks about it in a Mind for Numbers: “I generally liked to work on my more difficult subjects, like math, in the morning, when I was fresh. I still practice this approach today. I have some of my best mental breakthroughs in the bathroom and shower—it’s when I take my mind off the subject that the diffuse mode is able to work its magic.”
- zzo38computer 4y ago
  I also like to go for walk outside, and otherwise to take a break from it. It does not always help, but often it does help. (I think it is not quite as close as "almost every time", but it does help.)
- m463 4y ago
  My problems get unstuck in bed, in the languishing between waking and getting out of bed. I think we mull over things when we sleep and wake up with answers... as long as we don't let them dissipate like a dream. related and interesting - the sleep doctor david walker mentioned was that when we're learning something physical skill, sleep causes lots of sped-up simulation, and we wake up better at the skill.
paganel 4y ago
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.
- RC_ITR 4y ago
  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).
  - codingdave 4y ago
    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.
    - deleted 4y ago
      [deleted]
    - RC_ITR 4y ago
      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 4y ago
      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.
    - davidthewatson 4y ago
Aqueous 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      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 4y ago
        Yeah, and that sucks for sure. And it's a measure of management quality as to how they incorporate your feedback on this
        Trasmatta 4y ago
        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.
LanceH 4y ago
Obsessing over authentication and authorization. I've known no greater time sink.
samrocksc 4y ago
This is really nice...plenty to think on.
sanitycheck 4y ago
"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.
- bpicolo 4y ago
  It's when the bits that were "unknown unknowns" start to matter.
- ClumsyPilot 4y ago
  exactly, usually it turns out the final 20% are actually >50%
- D-Coder 4y ago
  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.
  - sanitycheck 4y ago
    I learned that too. Then years later I learned that asking too many questions early on that people don't know the answer to gets me a reputation of being "awkward", "negative" or "not a team player". It's not "agile" to properly understand a problem before trying to solve it, apparently! These days I limit the early questions to ones on which fundamental architecture and technology decisions rest. My estimates incorporate an "unknown unknowns" line.
- sgtnoodle 4y ago
  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.
  - thaumasiotes 4y ago
    It's not so much that high-value problems have a long tail to chase down. All problems are like that; the difference for high-value problems is that working on the tail is worth doing, because the problem is high-value.
VyseofArcadia 4y ago
> 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 4y ago
  Comic: https://bonkersworld.net/organizational-charts https://bonkersworld.net/organizational-charts
kelseyfrog 4y ago
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.
efficax 4y ago
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 4y ago
  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 4y ago
    >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.
deleted 4y ago
[deleted]
giantg2 4y ago
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.
ramesh31 4y ago
>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.
dang 4y ago
Discussed at the time: How Do Individual Contributors Get Stuck? A Primer (2017) - https://news.ycombinator.com/item?id=21169212 https://news.ycombinator.com/item?id=21169212 - Oct 2019 (83 comments)
dieselgate 4y ago
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.
lamontcg 4y ago
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 4y ago
  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.
adamius 4y ago
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.
tunesmith 4y ago
> 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 4y ago
  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.
  - benjaminbachman 4y ago
    I would sooner create a second ticket that represents the blocking task and link it as a blocker to the first ticket.
voidmain 4y ago
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.
deleted 4y ago
[deleted]
zzo38computer 4y ago
I do not work with a team, but some of the things listed there will still apply to programmers not working with a team, too. I know, because I have experienced them myself, too.
kc10 4y ago
Good list. From my past experiences, any time working in the same project for over two years results in repetition of the same work, similar stack and closed group of people. The same group of people solving similar problems the way they are used to. The more experienced a person is in the team, more time is spent on enabling others, more time spent in meetings, process related stuff etc. I don't say this is a bad thing for the team's goals, but the personal growth and tech exposure will be limited. Overtime, the person will become a star in that team or organization, but may lack the skills in demand outside the organization. I think staying close to latest techstack is super important for an IC for a longer career outside their current organization. That either means dedicating few hours a work on personal projects in latest technologies, watching YT, tech/how-to videos (YT, Udemy) or moving every two years to a new team.
kazinator 4y ago
Here is one that was missed: - Working on something that requires a complicated, flaky, manual test setup that is resistant to clean automation (e.g. involving hardware).
squarebizchris 4y ago
Needed to hear this

219 points by glennericksen 4y ago

> 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".

fatnoah 4y ago
>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 4y ago
  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 4y ago
    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 4y ago
      > 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.
    - itsmemattchung 4y ago
      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 4y ago
        It's one of the themes of Zen and the Art of Motorcycle Maintenance. A book on programming if I've ever read one.
      - pramodbiligiri 4y ago
        I've heard it being called Focussed Mode and Diffuse Mode, as described here - https://fs.blog/focused-diffuse-thinking/ https://fs.blog/focused-diffuse-thinking/ Bret Victor links to this book called Psychology of Invention in the Mathematical Field, which talks a lot about this too - http://worrydream.com/refs/Hadamard%20-%20The%20psychology%20of%20invention%20in%20the%20mathematical%20field.pdf http://worrydream.com/refs/Hadamard%20-%20The%20psychology%2...
    - barrysteve 4y ago
      We're so convinced consciousness is doing the solving that more is always better.
      - datavirtue 4y ago
        Winner.
    - hyperpallium2 4y ago
      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?
  - datavirtue 4y ago
    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.
cheschire 4y ago
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 4y ago
  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!"
  - PebblesRox 4y ago
    Thank you for the reminder! I didn't do the Wordle this morning and would have missed it today if not for your comment :)
agumonkey 4y ago
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.
deleted 4y ago
[deleted]
bcbrown 4y ago
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 4y ago
  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?
  - bcbrown 4y ago
    It's not scientific literature, but I got the inspiration from the book "Pragmatic Thinking and Learning".
  - ruraljuror 4y ago
    Barbara Oakley talks about it in a Mind for Numbers: “I generally liked to work on my more difficult subjects, like math, in the morning, when I was fresh. I still practice this approach today. I have some of my best mental breakthroughs in the bathroom and shower—it’s when I take my mind off the subject that the diffuse mode is able to work its magic.”
zzo38computer 4y ago
I also like to go for walk outside, and otherwise to take a break from it. It does not always help, but often it does help. (I think it is not quite as close as "almost every time", but it does help.)
m463 4y ago
My problems get unstuck in bed, in the languishing between waking and getting out of bed. I think we mull over things when we sleep and wake up with answers... as long as we don't let them dissipate like a dream. related and interesting - the sleep doctor david walker mentioned was that when we're learning something physical skill, sleep causes lots of sped-up simulation, and we wake up better at the skill.

paganel 4y ago

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.

RC_ITR 4y ago
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).
- codingdave 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - RC_ITR 4y ago
    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 4y ago
    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.
  - davidthewatson 4y ago

Aqueous 4y ago

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 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      Yeah, and that sucks for sure. And it's a measure of management quality as to how they incorporate your feedback on this
      - Trasmatta 4y ago
        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.

LanceH 4y ago

Obsessing over authentication and authorization. I've known no greater time sink.

samrocksc 4y ago

This is really nice...plenty to think on.

sanitycheck 4y ago

"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.

bpicolo 4y ago
It's when the bits that were "unknown unknowns" start to matter.
ClumsyPilot 4y ago
exactly, usually it turns out the final 20% are actually >50%
D-Coder 4y ago
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.
- sanitycheck 4y ago
  I learned that too. Then years later I learned that asking too many questions early on that people don't know the answer to gets me a reputation of being "awkward", "negative" or "not a team player". It's not "agile" to properly understand a problem before trying to solve it, apparently! These days I limit the early questions to ones on which fundamental architecture and technology decisions rest. My estimates incorporate an "unknown unknowns" line.
sgtnoodle 4y ago
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.
- thaumasiotes 4y ago
  It's not so much that high-value problems have a long tail to chase down. All problems are like that; the difference for high-value problems is that working on the tail is worth doing, because the problem is high-value.

VyseofArcadia 4y ago

> 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 4y ago
Comic: https://bonkersworld.net/organizational-charts https://bonkersworld.net/organizational-charts

kelseyfrog 4y ago

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.

efficax 4y ago

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 4y ago
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 4y ago
  >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.

deleted 4y ago

[deleted]

giantg2 4y ago

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.

ramesh31 4y ago

>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.

dang 4y ago

Discussed at the time: How Do Individual Contributors Get Stuck? A Primer (2017) - https://news.ycombinator.com/item?id=21169212 https://news.ycombinator.com/item?id=21169212 - Oct 2019 (83 comments)

dieselgate 4y ago

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.

lamontcg 4y ago

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 4y ago
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.

adamius 4y ago

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.

tunesmith 4y ago

> 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 4y ago
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.
- benjaminbachman 4y ago
  I would sooner create a second ticket that represents the blocking task and link it as a blocker to the first ticket.

voidmain 4y ago

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.

deleted 4y ago

[deleted]

zzo38computer 4y ago

I do not work with a team, but some of the things listed there will still apply to programmers not working with a team, too. I know, because I have experienced them myself, too.

kc10 4y ago

Good list. From my past experiences, any time working in the same project for over two years results in repetition of the same work, similar stack and closed group of people. The same group of people solving similar problems the way they are used to. The more experienced a person is in the team, more time is spent on enabling others, more time spent in meetings, process related stuff etc. I don't say this is a bad thing for the team's goals, but the personal growth and tech exposure will be limited. Overtime, the person will become a star in that team or organization, but may lack the skills in demand outside the organization. I think staying close to latest techstack is super important for an IC for a longer career outside their current organization. That either means dedicating few hours a work on personal projects in latest technologies, watching YT, tech/how-to videos (YT, Udemy) or moving every two years to a new team.

kazinator 4y ago

Here is one that was missed: - Working on something that requires a complicated, flaky, manual test setup that is resistant to clean automation (e.g. involving hardware).

squarebizchris 4y ago

Needed to hear this