Why simplicity should be every engineer's immediate goal

Systems run best when designed to run downhill

Ultimate vs Immediate Goals

In How to Focus: A Monastic Guide for an Age of Distraction, young monks ask a master how to reconcile their tendency to chase goals with their vocation to focus on the present. The master differentiates between an ultimate goal (telos) and an immediate goal (scopos). Pursuing the ultimate goal provides purpose, while pursuing the immediate goal provides focus.

The merchant’s ultimate goal of profit keeps them centered when trouble happens at sea. The soldiers’ ultimate goal of honor helps them face the danger of their campaigns. So what’s the monks’ ultimate goal? Salvation. Makes sense, but too abstract for the young monks to act on daily. So the master recommends pursuing salvation by focusing on the immediate goal of “clarity of heart,” achieved through solitude, fasts, labor, and reading.

This empowered the young monks to channel their existing ambition into daily habits rather than attempting to remove their ambition.

5th-century monks aren’t the only ones who can direct the power of flawed nature toward good. Although our goals are less noble, engineers also have the opportunity to work with our nature — or against it.

I’ll recommend a goal at the end. But first, we have to start with the question:

“What is our nature as software engineers?”

What we do naturally

We build things. Not because we have to, but because we can’t stop. 52% of devs code for fun even after coding all day.

We automate the boring stuff. Give a dev a mindlessly repetitive task and watch him spend three times as long building a buggy script to eliminate it.

We learn obsessively. Yes, partly to keep up with the industry’s pace. But things can only move so fast because so many of us refuse to wait for permission to pick up a new skill. We’ll find the docs, read the src, and figure things out regardless.

We give a sh*t about craft. Tech debt is the top frustration at work, cited by 62% of us — ahead of tool reliability, deployment pipelines, and security issues. We hate living in a mess (especially if we didn’t create it).

We give back. 25% of developers actively contribute to open-source, which doesn’t include those who volunteer to help with issues, docs, sponsorship, or organizing.

We’re drawn to hard problems. Two out of three developers say they are motivated by a passion for learning new things, and the problems that excite us most are the ones nobody has cleanly solved yet.

What we naturally resist

Context switching. The average digital worker toggles between apps and websites nearly 1,200 times per day and spends 4 hours per week reorienting themselves. I don’t know the numbers for devs, but I bet they’re worse. It requires sustained focus to hold the codebase in our working memory, which is why everyone hates silly meetings and interruptions.

Devs in Japan are 4X less likely to struggle with context switching than those in the UK. (IDK what to do with that fact yet, but it’s interesting.)

Waiting for CI. Slow feedback loops also break the flow.

Hollow metrics. We know productivity KPIs are BS: 66% of developers don’t believe or aren’t sure that current metrics reflect their real contribution.

Fixing other people’s messes. We hate spending time debugging legacy code, untangling connective tissue between APIs, and working around workarounds. Unless we made the mess, then it’s fine.

Estimation theater. Estimating costs and timelines while requirements change every other day and everything is on fire seems silly.

Meetings. Most engineers spend nearly a third of their week in meetings. We resist this instinctively, because we know exactly what we could have shipped instead.

Put it all together, and you get a group of creative, crafty builders who are motivated by hard problems and are allergic to inefficiency. We just want to ship things that matter and leave the codebase better than we found it.

Application

Now that we know ourselves, we can pick goals that work with our nature rather than against it.

This is easy for your day job: your ultimate goal is to maximize value — generate more revenue or reduce expenses (cringe, I know). Feel free to adopt a more altruistic goal on your employer’s behalf, but don’t complain when you get cut during the next layoff.

For your side project, pick whatever ultimate goal resonates.

Some ideas:

• Fix a personal pain point

• Learn a tool that excites you

• Make enough to replace your main income

• Build the tool you always wished existed

The important point is that you commit to one ultimate goal. Don’t optimize for four things simultaneously.

The traps hide in the immediate goal, as it often leads to complexity. Initially, complex feels like progress. It’s challenging, exciting. It gives you an excuse to learn and write more code. More features, more services, more dependencies.

But complex things don’t last.

That’s why I humbly recommend making your immediate goal to preserve simplicity.

Fix your problem with a simple stack. Learn a new thing, simply. Make enough $ to replace your main job ... using simple workflows.

This works because it embraces our tendency to find creative solutions. Instead of adding, however, it forces us to use that creativity to subtract. Instead of dragging kludgy abstractions along, it asks us to find cleaner ones. Deleting a thousand lines of code that you spent months writing doesn’t feel great, but replacing 950 lines with 50 feels amazing.

Simple software is natural software. It’s easier to scan at 6 am, easier to write at 6 pm, and easier to fix at 1 am. That's why it has a chance to survive long enough for you to reach your ultimate goal.

Systems run best when designed to run downhill
— John Gall

What’s another thing we do naturally that I left out? Reply to LMK.

Recommendations

Data

• Developer Ecosystem 2025 | JetBrain’s survey of 25k devs

• Developers want more, more, more | Stack Overflow’s 2024 survey

• State of AI 2025 | How devs use AI

• The Context Switching Crisis | Hivel AI 2025

• What Motivates Open Source Software Contributors | Opensource.com

Books

• Systemantics: how systems work and especially how they fail | Fun wisdom

• How to Focus: A Monastic Guide for an Age of Distraction

• A Philosophy of Software Design | John Ousterhoust

• Getting Real | 37signals | Canonical argument for less