Live data from Hacker News

How individual contributors get stuck (2017)

elidedbranches.com

41–50 of 97 posts

Re: How individual contributors get stuck (2017)

#42
post #6

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.

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.

Re: How individual contributors get stuck (2017)

#43

Earlier quoted context omitted.

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

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

Re: How individual contributors get stuck (2017)

#44
post #6

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.

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

Re: How individual contributors get stuck (2017)

#45
post #39

Earlier quoted context omitted.

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.

Re: How individual contributors get stuck (2017)

#46

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

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

Re: How individual contributors get stuck (2017)

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

Re: How individual contributors get stuck (2017)

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

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

Re: How individual contributors get stuck (2017)

#50

Earlier quoted context omitted.

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

We're so convinced consciousness is doing the solving that more is always better.
Post reply on HN