Live data from Hacker News

How individual contributors get stuck (2017)

elidedbranches.com

71–80 of 97 posts

Re: How individual contributors get stuck (2017)

#71

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

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.

Re: How individual contributors get stuck (2017)

#72
post #70

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

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?

Re: How individual contributors get stuck (2017)

#73
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…

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.

Re: How individual contributors get stuck (2017)

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

Re: How individual contributors get stuck (2017)

#77

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

Re: How individual contributors get stuck (2017)

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

Re: How individual contributors get stuck (2017)

#79

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

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.

Re: How individual contributors get stuck (2017)

#80

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

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.

Post reply on HN