3 ms·

Funny that you mention this, because it reminds me to a developer archetype that I noticed a few times, that I call "80/20 optimizer" for lack of a better name.

Funny that you mention this, because it reminds me to a developer archetype that I noticed a few times, that I call "80/20 optimizer" for lack of a better name. I was thinking about writing an article about this. I call them 80/20 optimizers because they seem fixated with getting the most stuff done with the least effort. Why do something to 100% in 100% the time when you can get 5 things 80% done? That's a good principle in theory. Delivering value incrementally and being smart about your efforts is positive, particularly in small and fast paced companies. However these people take it to the extreme. These are the developers that will crank out solutions fast that seem to work, but things fall apart once they leave. Once you open the lid, you find a system that barely qualifies as a PoC, with messy code, no documentation, manually set up infrastructure and config, etc. As you mention the key here is that the time it takes the team to find this has to be longer than their tenure in the project to make this work. Specifically the people I'm talking about are deliberate about this. Managers love them because "they get shit done", so they usually get promoted or moved to another initiative, so it is someone else's problem to deal with their mess. If they are particularly devious, they might use this as a double whammy: the poor souls that have to deal with their crap will look even worse compared with them (why does Mary need 1 week to implement a simple feature when Bill wrote the entire thing in 2 weeks?). These people move laterally and up in an organization, and if the chicken ever come home to roost, they will simply change companies. Remember, you don't need to fool everyone all the time, you just need to fool the right people long enough.

Mawr 3y ago
This is a tough one. Efficiency is what tends to be the ultimate goal of any venture, and getting 5 things 80% done instead of 1 thing 100% done is incredibly efficient. Moreover, no matter what course of action you choose, it will have downsides, you only get to choose which ones. I'm not so sure that the downsides of this hyper-efficient approach are worse than those of the alternatives. There's a bit of human bias at work here, you focus on the downsides in front of you because those are the ones you can see. However, you ignore the downsides other approaches would have because you can't see them. That doesn't mean they don't exist. Another aspect, it's considerably easier to find and solve problems with an implemented solution than an unimplemented one. That's what this hyper-optimized approach is likely great at - paving the way for other engineers. In the end, I think you need a few such 80/20 engineers on your team, but they must be coupled with a few "completionist" types as well, who'll come in afterwards to bring everything up to standard.

Mawr 3y ago

This is a tough one. Efficiency is what tends to be the ultimate goal of any venture, and getting 5 things 80% done instead of 1 thing 100% done is incredibly efficient. Moreover, no matter what course of action you choose, it will have downsides, you only get to choose which ones. I'm not so sure that the downsides of this hyper-efficient approach are worse than those of the alternatives. There's a bit of human bias at work here, you focus on the downsides in front of you because those are the ones you can see. However, you ignore the downsides other approaches would have because you can't see them. That doesn't mean they don't exist. Another aspect, it's considerably easier to find and solve problems with an implemented solution than an unimplemented one. That's what this hyper-optimized approach is likely great at - paving the way for other engineers. In the end, I think you need a few such 80/20 engineers on your team, but they must be coupled with a few "completionist" types as well, who'll come in afterwards to bring everything up to standard.