Live data from Hacker News

How individual contributors get stuck (2017)

elidedbranches.com

81–90 of 97 posts

Re: How individual contributors get stuck (2017)

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

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!

Re: How individual contributors get stuck (2017)

#82
post #70

Earlier quoted context omitted.

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

Re: How individual contributors get stuck (2017)

#83

Earlier quoted context omitted.

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

Re: How individual contributors get stuck (2017)

#84

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

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.

Re: How individual contributors get stuck (2017)

#85
post #69

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

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

Re: How individual contributors get stuck (2017)

#86
post #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 mea…

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.

Re: How individual contributors get stuck (2017)

#88
post #54

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

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.

Re: How individual contributors get stuck (2017)

#90

Earlier quoted context omitted.

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

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.

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

Post reply on HN