How individual contributors get stuck (2017)

&gt; 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<p>Taking it one step further. Noticing how you — yourself — get stuck is a superpower. But it&#x27;s hard...really hard.<p>When I get stuck on troubleshooting an issue, I can sometimes fall in this trap that my wife calls the &quot;blackhole.&quot; I obsess over it. I cannot rid the problem from my mind. My 2.5 year old even sees it in my eyes ; she&#x27;ll glance up at me, wondering where I am.<p>Before reaching this &quot;blackhole&quot; state, I can start to feel when I get tunnel vision.... at which point, I distance myself from the problem.<p>Hands off the keyboard.<p>Go for a walk.<p>And almost EVERY damn time, I&#x27;m able to solve the problem easily. Just needed a fresh pair of (my own) eyes, a moment to get &quot;unstuck&quot;.

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&#x27;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&#x27;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&#x2F;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&#x2F; product to follow up later with a final decision that we&#x27;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.

&gt; Helping other people instead of doing their assigned tasks<p>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.<p>I&#x27;ve been there. It sucks. You end up calling it a &quot;blocker&quot; and then managers get involved to unblock you which leads to resentment from the people&#x2F;teams who were told to drop their other important stuff to help you, and then they half-ass it and it doesn&#x27;t do much good anyway.<p>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.

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.<p>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&#x27;s happening.<p>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&#x27;t, can&#x27;t, or won&#x27;t.

It&#x27;s possible to take anything good to excess. For every piece of advice, <i>someone</i> probably needs to hear the opposite.<p>But... if your manager is displeased with <i>most ICs</i> 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.

&quot;1. Finish the last 10–20% of a project&quot;<p>This isn&#x27;t getting stuck, the &quot;last 20%&quot; of a project takes 80% of the time. This is when you start to get the REAL requirements.

Some of these aren&#x27;t necessarily bad.<p>Sometimes when you&#x27;re rebuilding the entire world its good to get distracted with jumping into some firefighting (even when &quot;not on call&quot;) to get the dopamine hit of fixing a problem and being the goddamn hero.<p>Then you can go back in two or three days or something to being Sisyphus.<p>As the currently top voted comment points out that sometimes going off and doing other things can also help &quot;unstick&quot; you when you&#x27;re feeling overwhelmed and burned out on one particular problem.<p>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&#x27;s the highest priority thing you should be working on at any given time.

When I&#x27;ve gotten stuck it&#x27;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&#x27;t implement the feature in an architecturally sound way without a significant refactor.<p>This has happened to me many times.

&gt;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.<p>But Sloppy gets promoted while Stuck gets a &quot;meets expectations&quot;.<p>The key is in knowing when it&#x27;s ok to be sloppy.

Discussed at the time:<p><i>How Do Individual Contributors Get Stuck? A Primer (2017)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21169212" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21169212</a> - Oct 2019 (83 comments)

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.<p>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&#x27;t say this is a bad thing for the team&#x27;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.<p>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&#x2F;how-to videos (YT, Udemy) or moving every two years to a new team.

Obsessing over authentication and authorization. I&#x27;ve known no greater time sink.

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

Good list. Its not unlike what I keep on the wall. I call it the potholes on the road. Whenever I feel like I&#x27;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.<p>This is how I stay on target and finish things. Perfection is only a justifying set of sweet lies that prevent finishing.

This is a great article. In just looking at the lists of where&#x2F;why ICs get stuck I feel enabled to grow as an IC.

Maybe a little meta, but when did the programmers -&gt; individual contributors transition happen?<p>Until a few years ago saying and writing &quot;programmers&quot; on forums like HN was still prevalent, and then, after a certain moment, I started seeing &quot;ICs&quot; more and more.

&gt; Helping other people instead of doing their assigned tasks<p>Hehe, that&#x27;s totally me. That one is really hard, though, because it&#x27;s also arguably my job. Keeping other people unblocked is the best way to accelerate the team&#x27;s overall output.

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.

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.

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

Needed to hear this