How individual contributors get stuck (2017) | Hacker News Reader

How individual contributors get stuck (2017)

elidedbranches.com

219 pointsglennericksen90 comments

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

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

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.

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.

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

We're so convinced consciousness is doing the solving that more is always better.

Winner.

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.

It's one of the themes of Zen and the Art of Motorcycle Maintenance. A book on programming if I've ever read one.

I've heard it being called Focussed Mode and Diffuse Mode, as described here - 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%2...

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?

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.

"Banging your head" usually means lots of trial and error, that is all error. But beyond uploading information, every experiment creates new information. ("I haven't failed - I've discovered 1,000 ways that won't work!" https://quoteinvestigator.com/2012/07/31/edison-lot-results/)

When the search space is exponential, with too many combinations to try, pruning off a branch is enormously helpful (and perfectly harmless... provided the solution doesn't happen to lie on that branch - those are my most stuck times).

One signal is when I can't think of anything else to try - that means I've extracted all the information I can. The trouble is, I'm pretty good at thinking of things to try.

There have been plenty of times for me where I was like "oh I'll stop for now, hopefully the answer will come in the shower" or while I'm falling asleep or while I'm doing groceries or something, but never does. There goes two weeks, no progress. Eventually I have to sit down, focus, and think.

So it's not a lesson I've learned, but I don't think it's a lesson I should learn either.

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.

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.

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

Thank you for the reminder! I didn't do the Wordle this morning and would have missed it today if not for your comment :)

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.

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.

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?

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

It's not scientific literature, but I got the inspiration from the book "Pragmatic Thinking and Learning".

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

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.

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.

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.

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

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.

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.

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

Comic: https://bonkersworld.net/organizational-charts

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.

It's when the bits that were "unknown unknowns" start to matter.

exactly, usually it turns out the final 20% are actually >50%

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Yeah, and that sucks for sure. And it's a measure of management quality as to how they incorporate your feedback on this

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.

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

Eh, sometimes the predecessor is me, the fact that a large refactor remains between me and the end goal is still a blocker.

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.

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.

Data structures being badly designed is a perfectly valid and common blocker. That is why we try to design things correctly, after all - to avoid blocking future engineers when they try to change the system. Badly designed data structures can make a system impossible to extend. Regardless of who is to blame, we need to call such things out so that people actually pay attention to data design in the future, and avoid things that are extremely costly but necessary to fix. So I'd say it is productive to point it out.

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.

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

It was, in fact, not me.

And the tradeoffs did not make sense. This was a simple case of bad normalization - a missed many to one relationship. It just so happens that it happened to be a relationship at the center of a very large platform, and is baked through many services. And without fixing it early-ish, we'd be fighting the schema for the next 10 - 20 years and creating unmanageable complexity in the process, all the while making it harder for ourselves to eventually fix it.

So I'm just pointing out something factual. Sometimes making sure something doesn't happen again means calling a spade a spade. If that means pointing out a mistake, then we absolutely should.

I wasn't really suggesting you were. I was pointing out that your described situation is actually pretty rare. Your opening " ... it's usually ..." suggested the anecdote you offered generalized easily, but that isn't true.

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!

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

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

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.

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.

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.

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.

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.

Everywhere I have worked, "IC" meant "not a people manager," so no, it is not a term which can be substituted with "programmer."

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.

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

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.

It’s nothing to do with Agile. It’s just a short way to say “employees who are not managers.”

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

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.

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

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.

I would sooner create a second ticket that represents the blocking task and link it as a blocker to the first ticket.

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

Reply on news.ycombinator.com