Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How individual contributors get stuck (2017)

elidedbranches.com

Post reply on HN
Print view View original

31–40 of 97 posts

Re: How individual contributors get stuck (2017)

#31

Post by jack_h »

121789 wrote: post #27
stonemetal12 wrote: post #8

Earlier quoted context omitted.

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.

Re: How individual contributors get stuck (2017)

#33

Post by pacaro »

Trasmatta wrote: post #15
Aqueous wrote: 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.

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.

Re: How individual contributors get stuck (2017)

#34

Post by mgkimsal »

cecilpl2 wrote: post #16
Aqueous wrote: 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.

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

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.

Re: How individual contributors get stuck (2017)

#35

Post by Trasmatta »

pacaro wrote: post #33
Trasmatta wrote: post #15

Earlier quoted context omitted.

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

Re: How individual contributors get stuck (2017)

#36

Post by bradstewart »

itsmemattchung wrote: post #7
fatnoah wrote: post #3

Earlier quoted context omitted.

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

Re: How individual contributors get stuck (2017)

#37

Post by corrral »

paganel wrote: 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.

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

Re: How individual contributors get stuck (2017)

#38

Post by ramesh31 »

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

Re: How individual contributors get stuck (2017)

#39

Post by pacaro »

Trasmatta wrote: post #35
pacaro wrote: post #33

Earlier quoted context omitted.

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

Re: How individual contributors get stuck (2017)

#40

Post by ClumsyPilot »

sanitycheck wrote: post #18

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

exactly, usually it turns out the final 20% are actually >50%
Post reply on HN