4 ms·

My goodness, are you me? This mirrors my experience to a T, almost exactly when I’ve tried to change process for the better. By far the one that hits the most i

My goodness, are you me? This mirrors my experience to a T, almost exactly when I’ve tried to change process for the better. By far the one that hits the most is be rude: “well, just start fixing things then.” It was a daily struggle to have to work around the nay-say and lazy and equivocation and it was so demoralizing knowing that there was a simple fix but people didn’t want to do it because it would out their incompetence and start to reveal the tremendous pile of tech debt they’ve built everything else on. The most funny thing was that this was not a huge organization at all, it was small for the scale they were working at but certain individuals have ossified the culture to a point where you would have thought it was hundreds of others. So frustrating, day in and day out. > leadership had totally lost control of the zoo This kills me So glad to see I’m not alone!

samhuk 3y ago
Regarding tech leadership: Perhaps I've just been unlucky, but a rather depressing proportion of tech leadership that I have been under in the past appear to have seeked the role in order to: 1. Hide lack of engineering aptitude. 2. Put less work in. If i'm on the right track with that, then it well explains why they don't care about cultivating a good engineering culture and let everything devolve into a zoo - i.e. everybody feels like everyone is out to get each other, no team work, rep farming, and all that nonsense. Regarding getting work done: I agree, I actually believe that it's the cause of the slow death of many companies: A gradual acceptance of nay-sayers, laziness, and "losers", that is to say an acceptance of people who just think that everything is lost, there's no point to fixing anything, and instead choses to spend their time placating why nothing can be done about anything. It's depressing, and was traumatic for when I was working in those environments in the past. (I like to think) I'm a get shit done and deliver awesome products kind of guy, so these "loser" engineers and leaders are a true PITA.
- hinkley 3y ago
  It can be tough because a lot of the work I do that gets me or keeps me in a technical leadership position is building lieutenants. That necessitates me transferring ownership of things to them, so they can grow or at least demonstrate to the organization that they have adulting skills and need a raise. That can look a lot like me trying to do less work. Most of the time what I’m doing instead is looking at problems we “didn’t have time for” but are about to bury us. I can only juggle so many balls at once. What’s your favorite color? <hands you one>
inkcapmushroom 3y ago
>people didn’t want to do it because it would out their incompetence and start to reveal the tremendous pile of tech debt they’ve built everything else on All part of the great circle of (software) life. Once they pass on from the company, you'll rip out their old, ossified way of doing things, and then when your new purer way hits the hard reality of business requirements and other considerations that don't fit in the nice world of software abstraction, you end up adding patches and edge cases and caveats until your software ends up looking a lot like the old one. And then a new dev comes in and complains that your process is terrible and they could do it so much better...
hinkley 3y ago
I had level 5’s telling me this shit when I was a (mis-leveled) 3 and they were doing the management bullshit thing of “bring me solutions not problems” bitch what do you think a staff/principal engineers job is if it isn’t finding problems before they find us? In a code as packed to the gills with tribal knowledge people don’t even know where the problems live. They just see the problem. They stopped saying this when I reminded them that if I knew the answer I’d have their job. They still never actually lead anything.
cratermoon 3y ago
“well, just start fixing things then.” Also a real problem when management and leadership discourage working outside the "standard process" and incentives punish working around it. The person responsible won't work on it, and anyone else who could resolve the issue won't because they know they'll get dinged for not following the process.

samhuk 3y ago

Regarding tech leadership: Perhaps I've just been unlucky, but a rather depressing proportion of tech leadership that I have been under in the past appear to have seeked the role in order to: 1. Hide lack of engineering aptitude. 2. Put less work in. If i'm on the right track with that, then it well explains why they don't care about cultivating a good engineering culture and let everything devolve into a zoo - i.e. everybody feels like everyone is out to get each other, no team work, rep farming, and all that nonsense. Regarding getting work done: I agree, I actually believe that it's the cause of the slow death of many companies: A gradual acceptance of nay-sayers, laziness, and "losers", that is to say an acceptance of people who just think that everything is lost, there's no point to fixing anything, and instead choses to spend their time placating why nothing can be done about anything. It's depressing, and was traumatic for when I was working in those environments in the past. (I like to think) I'm a get shit done and deliver awesome products kind of guy, so these "loser" engineers and leaders are a true PITA.

hinkley 3y ago
It can be tough because a lot of the work I do that gets me or keeps me in a technical leadership position is building lieutenants. That necessitates me transferring ownership of things to them, so they can grow or at least demonstrate to the organization that they have adulting skills and need a raise. That can look a lot like me trying to do less work. Most of the time what I’m doing instead is looking at problems we “didn’t have time for” but are about to bury us. I can only juggle so many balls at once. What’s your favorite color? <hands you one>

inkcapmushroom 3y ago

>people didn’t want to do it because it would out their incompetence and start to reveal the tremendous pile of tech debt they’ve built everything else on All part of the great circle of (software) life. Once they pass on from the company, you'll rip out their old, ossified way of doing things, and then when your new purer way hits the hard reality of business requirements and other considerations that don't fit in the nice world of software abstraction, you end up adding patches and edge cases and caveats until your software ends up looking a lot like the old one. And then a new dev comes in and complains that your process is terrible and they could do it so much better...

hinkley 3y ago

I had level 5’s telling me this shit when I was a (mis-leveled) 3 and they were doing the management bullshit thing of “bring me solutions not problems” bitch what do you think a staff/principal engineers job is if it isn’t finding problems before they find us? In a code as packed to the gills with tribal knowledge people don’t even know where the problems live. They just see the problem. They stopped saying this when I reminded them that if I knew the answer I’d have their job. They still never actually lead anything.

cratermoon 3y ago

“well, just start fixing things then.” Also a real problem when management and leadership discourage working outside the "standard process" and incentives punish working around it. The person responsible won't work on it, and anyone else who could resolve the issue won't because they know they'll get dinged for not following the process.