3 ms·

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/

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 https://en.wikipedia.org/wiki/Worse_is_better - Intelligence is compression (at least in one perspective) https://youtu.be/izqSvm-YAww?t=376 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/geohot/tinygrad https://github.com/karpathy/nanoGPT https://github.com/karpathy/nanoGPT - Satisficing https://en.wikipedia.org/wiki/Satisficing https://en.wikipedia.org/wiki/Satisficing - Perfect is the enemy of good https://en.wikipedia.org/wiki/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.

lytefm 4y ago
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.
- mmis1000 4y ago
  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.
imwillofficial 4y ago
I found this list helpful. Thank you.
coffeebeqn 4y ago
I would show them some Rich Hickey - Simple made easy https://m.youtube.com/watch?v=LKtk3HCgTa8 https://m.youtube.com/watch?v=LKtk3HCgTa8 And hope they see the light
theptip 4y ago
I like this general approach. One more to add to the list: https://grugbrain.dev/ https://grugbrain.dev/
- lytefm 4y ago
  > 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 https://github.com/everythingishacked/Pants
- defaultcompany 4y ago
  Yes! Complexity is Apex predator of grug brain developer.

lytefm 4y ago

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.

mmis1000 4y ago
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.

imwillofficial 4y ago

I found this list helpful. Thank you.

coffeebeqn 4y ago

I would show them some Rich Hickey - Simple made easy https://m.youtube.com/watch?v=LKtk3HCgTa8 https://m.youtube.com/watch?v=LKtk3HCgTa8 And hope they see the light

theptip 4y ago

I like this general approach. One more to add to the list: https://grugbrain.dev/ https://grugbrain.dev/

lytefm 4y ago
> 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 https://github.com/everythingishacked/Pants
defaultcompany 4y ago
Yes! Complexity is Apex predator of grug brain developer.