"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.
Self driving cars is one of those projects.
61–70 of 97 posts
"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.
Self driving cars is one of those projects.
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…
Good point, but why can't you do the same thing in a big org? Of course there are different kinds of orgs, but in my experience doing what you described (just make a decision yourself and note it to stakeholders later) is always the most expedient. The only ways I've seen it go wrong is if that decision entails a lot of work (choose the simple thing) or you get overly committed to a direction and don't actually want…
And a lot of those orgs do 'spinning up the meeting merry-go-round' as a baseline.
I would love to find solutions, run them through other developers to make sure it won't be a disaster to maintain, and present them. But more often than not, anything beyond 5 minutes of investment isn't worth the personal time investment given the organization. There are just too many hurdles.
From my experience, most developers are still treated like idiot savant children capable of doing the one thing the 'helicopter parent' managers can't do.
This is how I stay on target and finish things. Perfection is only a justifying set of sweet lies that prevent finishing.
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.
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.…
We're so convinced consciousness is doing the solving that more is always better.
Earlier quoted context omitted.
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…
That isn't what IC means - it means "not management". You do your job, whatever that may be and whomever you may be teamed with, but do not have direct reports.
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.
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.
> 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.
> 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…