Live data from Hacker News

How individual contributors get stuck (2017)

elidedbranches.com

21–30 of 97 posts

Re: How individual contributors get stuck (2017)

#21
post #4

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.

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.

Re: How individual contributors get stuck (2017)

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

Re: How individual contributors get stuck (2017)

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

Re: How individual contributors get stuck (2017)

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

Re: How individual contributors get stuck (2017)

#25
post #5
post #4

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…

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

Re: How individual contributors get stuck (2017)

#26

> 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 min…

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

Re: How individual contributors get stuck (2017)

#27
post #4

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.

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

Re: How individual contributors get stuck (2017)

#29
post #4

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.

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

Re: How individual contributors get stuck (2017)

#30

> 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 min…

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.

Post reply on HN