3 ms·

You have to first identify the percentage of developers that fall into the over-engineer class. If it’s 30%, then it’s possible 30% of your team will over-abstr

You have to first identify the percentage of developers that fall into the over-engineer class. If it’s 30%, then it’s possible 30% of your team will over-abstract, and if you make them a principal, they will over engineer most of the codebase. These are scary people, because at least the duck-tape ‘just get it done’ people write sloppy but simple code (always needs to be cleaned up, but this is a lower load cognitively than unraveling the mental models of the over-engineers). Both can test one’s patience. To keep running with the analogy, the sloppy developers will just take a credit card and max it out. The over-engineers will do credit default swaps on mortgage backed securities and tie up the whole economy.

nicoburns 6y ago
> If it’s 30%, then it’s possible 30% of your team will over-abstract, and if you make them a principal, they will over engineer most of the codebase. Isn't the idea to make a non-over-abstracting engineer the principal, and then they will bring everyone else into line with code review, etc.
- runawaybottle 6y ago
  Business usually values speed. If you over engineer or just duck tape everything, so long as you are fast about it, you’ll be on the short list to be a principal. Wrong values propel them to the top.
harryf 6y ago
Great extension to the analogy! In my experience over-engineering class are the most damaging of all and I feel like the article and general discussion of technical debt largely ignores this. I'd also add two subsets of the over-engineers. One subset are those that create frameworks to solve problems vs. address the problem directly. The other are those that introduce (language / datastore / build tool / etc.)-of-the-week to a codebase in an ad-hoc manner. And I'll admit, I've been both of those once upon a time...
rightbyte 6y ago
Ye I prefer a flat mess over an deep mess anyday.

nicoburns 6y ago

> If it’s 30%, then it’s possible 30% of your team will over-abstract, and if you make them a principal, they will over engineer most of the codebase. Isn't the idea to make a non-over-abstracting engineer the principal, and then they will bring everyone else into line with code review, etc.

runawaybottle 6y ago
Business usually values speed. If you over engineer or just duck tape everything, so long as you are fast about it, you’ll be on the short list to be a principal. Wrong values propel them to the top.

harryf 6y ago

Great extension to the analogy! In my experience over-engineering class are the most damaging of all and I feel like the article and general discussion of technical debt largely ignores this. I'd also add two subsets of the over-engineers. One subset are those that create frameworks to solve problems vs. address the problem directly. The other are those that introduce (language / datastore / build tool / etc.)-of-the-week to a codebase in an ad-hoc manner. And I'll admit, I've been both of those once upon a time...

rightbyte 6y ago

Ye I prefer a flat mess over an deep mess anyday.