Everyone in tech loves to hate on the over-engineers or the under-engineers.

Over-engineers say:

  • Software engineering is declining!
  • No one understands underlying hardware or algorithms anymore!
  • No one truly understands this system, look at their dependencies! They depend on millions of lines of code!
  • I’ll write huge style guides, set up technical committees, gatekeep all code changes and re-write the whole system from scratch. Then everything will be great and I’ll finally sleep at night.

Under-engineers say:

  • Git sucks! Code reviews suck! OOP sucks! Architectural design sucks!
  • Everyone is wasting their time, just throw something together and push it out!
  • I love hacking, I’ll spend all evening and weekends doing it, I’m always happy to jump on top of my bugs to squash them :^)

Tech draws in people who are super passionate about theory or super passionate about application.

The middle ground is left frustratingly empty.

The art of engineering is in choosing the right pattern at the right time for the right problem.

Both over-engineers and under-engineers are guilty of ignoring this art.

The meta-problem here is how does one solve a problem.

Both parties treat the meta-problem as solved.

In reality, they’re both doing what they find most fun, and aren’t even trying to solve the meta-problem.

They’re applying a one-size fits all approach, projecting out the world they want to exist; but the reality is:

Life is nuanced

All good software engineering tools, techniques and paradigms are there to enable you to handle the appropriate level of complexity.

An over-engineer will completely fail to launch a simple project and so in that context won’t deliver anything of value.

But their mindset may be what is needed for say; a clinical grade medical device running on embedded devices.

An under-engineer will completely fail to improve a vast complex system and so in that context won’t deliver anything of value.

But their mindset may be what is needed for say; building a new fan site for a buzzing hot topic, where time is of the essence, and flare is more valued by users than robustness.

So all engineers can be “just right engineers” by moving to an appropriate environment. But in practice very few will slot into a perfect role for their default make-up.

The engineers I respect most are those who adapt to their environment.

Just right engineers say:

  • This approach would have huge value, but requires huge investment. The return on investment is too low, so we will not use it at this point of time
  • This approach is high risk, high reward. There are no low risk, high rewards alternatives; so lets commit.
  • We are currently using an approach that would enable future functionality we would love to build, but we don’t know if / when we will build it; and for now it is adding huge overhead to our process holding us back. We will drop it for now.
  • We have not invested in tooling, and now that we are scaling it is massively holding us back; time to commit to building these enablers

The key being applying the art of engineering

Avoiding doing something too soon or too late

Following the nuances of life

Moving fast enough that you take action to shake out unknown unknowns

Moving slow enough to observe the consequences of your actions, and spot opportunity to enhance productivity

All software engineering should be a balancing act between committing to deliver value now and increasing your future ability to deliver value