Comment by hosolmaz | Hacker News Reader

Comment by hosolmaz | Hacker News Reader

If an engineer is truly smart, they can be reasoned with. You can use the following concepts to craft an argument:

- Worse is better: https://en.wikipedia.org/wiki/Worse_is_better

- Intelligence is compression (at least in one perspective) https://youtu.be/izqSvm-YAww?t=376

- Many smart developers try to reduce code, not multiply it: https://github.com/geohot/tinygrad https://github.com/karpathy/nanoGPT

- Satisficing https://en.wikipedia.org/wiki/Satisficing

- Perfect is the enemy of good https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

A perfectionist engineer optimizes their code to represent reality perfectly and wastes a lot of time along the way. Their objective function is the discrepancy between the code and reality, and they try to minimize that.

You can offer alternative objective functions:

- Minimize time to implement a requested feature

- Maximize survivability of the company

A good engineer is one that finds the right trade-off between "the right thing" which might be deadly for the company and "the worse thing" which enables the company to develop features fast and remain competitive.

At least, these are the arguments I use on myself to prevent myself from overengineering.

I agree. If an engineer comes fresh from university/ leet code/ certain companies and hasn't yet adopted the kind of mindset you're looking for, teach them!

If they are actually smart as in „intelligent, humble and curious“ they'll understand and adapt.

During my first two years as a developer, I was also in the „a double for-loop? Not under my watch!“ - camp and wrote a lot of „clever“ code that often was a waste of time or even caused problems lateron.

With experience + reading more about software engineering „in practise” as opposed to „in academic theory“, I learned to prefer solutions that don't use many layers of abstraction, are simple enough for a junior engineer to understand, easy to maintain and actually add value for the business.

A smart engineer knows that engineering time is limited and expensive - and acts accordingly.

An experienced engineer will know it is sometimes better to have a simple and short solution that `when bugged, you can fix it in 30 minutes` than a complete full solution that `you will never be able to find out where did it went wrong`.

Somethings the extension points you designed is never used, but it still has maintenance cost. And that really should be avoided.

I like this general approach. One more to add to the list:

https://grugbrain.dev/

> because as grug brain developer get older he forget important things, like what had for breakfast or if put pants on

Luckily, there is this: https://github.com/everythingishacked/Pants

Yes! Complexity is Apex predator of grug brain developer.

I would show them some Rich Hickey - Simple made easy https://m.youtube.com/watch?v=LKtk3HCgTa8

And hope they see the light

I found this list helpful. Thank you.

Reply on news.ycombinator.com