Hacker News Reader

Comment by mrighele | Hacker News Reader

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.

View on HN

> 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.

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.

I think this is what code commenting is for, though

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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com