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

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.

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

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.

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.

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

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.

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.

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

Discussed at the time:

How Do Individual Contributors Get Stuck? A Primer (2017) - https://news.ycombinator.com/item?id=21169212 - 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.

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.

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

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

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.

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.

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.

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

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

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.

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.

Unclear specifications in the edge cases is the definition of requirements engineering and the reason why such an approach usually isn’t the best for any moderately complex application.

If the person who wrote the requirements could formulate them precisely, they might as well have done it themselves in code rather than as requirements.

As a coder you just have to get used to it. Your job is to fill in the blanks so the higher ups can focus on the big picture.

This is why iterative planning (agile) has become so popular. You implement the most important use cases first and from there go through the edge cases together.

Please take this the right way, but blaming your predecessors is not a productive mindset, nor is it really the topic of this post.

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

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.

I've been hearing these sorts of complaints since I started working. Bob leaves, immediately people need to rewrite Bob's code because it sucks. The truth is often that the other person doesn't fully understand it. Writing code is easy, reading code is hard.

There is almost always a way to work around something. "Architecturally sound" is in the eyes of the beholder, and unless you're building the next Google, a sub-optimal solution may be perfectly fine. That's what we're paid the big bucks for: to develop a solution, one that works "good enough", without having to constantly rewrite... sorry, "refactor"... the entire project.

This isn't always the case though. Sometimes the code really does suck!

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.

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.

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

I've assumed it's a FAANGism. This is the only place I see the term used.

Terminology copied from large code factories and assembly lines, such as google, facebook and other modern day Chryslers and Fords. Beats "worker" or "resource".

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.

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