4 ms·

What looks overcomplicated to a 1x engineer may be quite simple to the 10x. This in fact the most painful point to overcome with them: that not everybody is as

What looks overcomplicated to a 1x engineer may be quite simple to the 10x. This in fact the most painful point to overcome with them: that not everybody is as skilled as them so the software should be designed and written accordingly. 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.

StavrosK 11y ago
I disagree. The entire practice of development is making simple parts and linking them together in a simple manner to create more complex parts that are still simple to understand at their level. 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.
- emcq 11y ago
  This is not strictly true, and happens when complexity is needed for some of the simple lower level parts or due to the libraries and tools available changing over time. 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 https://en.m.wikipedia.org/wiki/Fast_inverse_square_root
  - StavrosK 11y ago
    This is about optimizations, which are the exception to the rule. Optimizations are just a necessary evil, they aren't what we should base our coding standards around. As you also pointed out about hardware support, we tend to stick these in as lower a level as possible, so we can back to our simple and elegant abstractions as quickly as possible.
- esailija 11y ago
  I find whenever some code is "simple", it's just not really doing anything at all and whatever it's actually doing, it's doing it badly. E.g. it's not handling anything other than some basic cases and performs horribly.
laxatives 11y ago
No I strongly disagree. The better engineer should take a complex problem and create layers of abstraction such that any idiot can manage the problem. It isn't sufficient to just solve harder problems, they need to rotate the basis such that it becomes a simpler problem, or change the problem so that it is simple, or comprised of simple components.
qb45 11y ago
> not everybody is as skilled as them so the software should be designed and written accordingly. 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! Man, I hate people at times.
- marshray 11y ago
  I can relate to a situation where a container of iterators is the seemingly correct solution yet not necessarily the best thing to adopt for maintenance considerations. 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.
- YngwieMalware 11y ago
  I think this is what code commenting is for, though
rifung 11y ago
My advisor said to me "A really smart person isn't one who comes up with complicated solutions to solve difficult problems but someone who can make very simple and elegant solutions to complicated problems." I'm inclined to agree with him.

StavrosK 11y ago

I disagree. The entire practice of development is making simple parts and linking them together in a simple manner to create more complex parts that are still simple to understand at their level. 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.

emcq 11y ago
This is not strictly true, and happens when complexity is needed for some of the simple lower level parts or due to the libraries and tools available changing over time. 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 https://en.m.wikipedia.org/wiki/Fast_inverse_square_root
- StavrosK 11y ago
  This is about optimizations, which are the exception to the rule. Optimizations are just a necessary evil, they aren't what we should base our coding standards around. As you also pointed out about hardware support, we tend to stick these in as lower a level as possible, so we can back to our simple and elegant abstractions as quickly as possible.
esailija 11y ago
I find whenever some code is "simple", it's just not really doing anything at all and whatever it's actually doing, it's doing it badly. E.g. it's not handling anything other than some basic cases and performs horribly.

laxatives 11y ago

No I strongly disagree. The better engineer should take a complex problem and create layers of abstraction such that any idiot can manage the problem. It isn't sufficient to just solve harder problems, they need to rotate the basis such that it becomes a simpler problem, or change the problem so that it is simple, or comprised of simple components.

qb45 11y ago

> not everybody is as skilled as them so the software should be designed and written accordingly. 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! Man, I hate people at times.

marshray 11y ago
I can relate to a situation where a container of iterators is the seemingly correct solution yet not necessarily the best thing to adopt for maintenance considerations. 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.
YngwieMalware 11y ago
I think this is what code commenting is for, though

rifung 11y ago

My advisor said to me "A really smart person isn't one who comes up with complicated solutions to solve difficult problems but someone who can make very simple and elegant solutions to complicated problems." I'm inclined to agree with him.