51–60 of 97 posts
> 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…
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.…
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.…
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?
"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.
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…
Earlier quoted context omitted.
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…
Furthermore, if the story you tell yourself is “I’m great, the main thing that I get stuck on is when others mess up and I need to fix it”, then even if that is in fact true, you miss an opportunity for acquiring self-knowledge by investigating the patterns of self-inflicted stuckness.
Put differently, maybe the mistakes of others are outside your control, but your own weak spots (everybody has them, it’s fine) are within your control to improve upon. And one of the more important jobs of a good manager is to use the 30k ft view to help individuals to spot and work on improving these patterns.
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…
The slowest-to-ship engineers are the ones who refuse to do a bit of design thinking or copywriting when they hit the inevitable unspecced case and instead think "not my job!". It really is your job to find all of those cases, but going a bit outside your domain to suggest the simplest solution (usually by coding it up) rather than spinning up the meeting merry-go-round is going to make you 2x more valuable than the engineer who just gets blocked.
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…
I'm not sure what you mean. In a corporate job ladder, anyone who isn't strictly a manager and writes at least SOME code is classified as an IC. That's not to say that there are no managers who also write code, though.
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.
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.