The "10x engineer" I worked for quit and left me with an extremely over-complicated piece of software to manage. He's a sweet guy and a good friend, but really left me holding the bag because he was not happy.
In my (limited) experience, those that don't learn this tend to do all by themselves "because the others can't do shit", get overworked and are unpleasant to work with. Those who do are able instead to focus on the most important (and interesting) parts while letting the others taking their boring share.
Your computer is extremely complicated, but it can be broken down to parts that are simple to understand in each level. That's pretty much the entire benefit of a good engineer. They know how to make self-contained things whose purpose and interface with the rest of the system is easily understandable.
For example, lets say the 10x engineer wrote fast inverse square root [0]. Most people would look at the code and not understand what's going on. It requires a lot of domain knowledge but provided nice speeedups at the time. Is it more complicated than necessary for some problems? Absolutely. However when used frequently as originally intended that speedup allows for more compute to be spent on higher level components useful to the rest of the team. It would also be a pain to maintain for those unfamiliar with some of the details but can be well encapsulated into a simple function call in a math library.
Thw other case this illustrates is that code evolves and a solution available now to make a system simpler may not have been available in the past. Today the same code for fast inverse square root is outdated in favor of hardware calls, so if observing the code now it is certainly over complicated for the solutions available at hand.
[0] https://en.m.wikipedia.org/wiki/Fast_inverse_square_root
I don't know if I'm a 10x dev, but I've heard this mantra few times.
It's most annoying when it happens because I actually strive to make something simple. Like I once needed to index members of some C++ STL container, so I used std::map<key, container::iterator>. It went like that:
- WTF? A map of iterators? It's complicated! Remove it!
- But the objects need to sit in this container and this extra index is also required.
- But... but.. It's complicated! Remove it!
Containers tend to persist over relatively large blocks of code, whereas iterator invalidation can be very tricky and most people get bitten by it at some point.
I'm inclined to agree with him.
That's why this whole topic is stupid.