Don't mop the floor. Fix the leaky faucet.: Complexity is a choice. Simplicity is also a choice. Look for the root cause.

I spent 13 years of my career thinking I have to solve every problem<br>life throws at me. Go watch Rambo: First Blood. I'm literally John.

Was.

After my last engagement with Codility I spent two months figuring out<br>why I "lost" again, as if my entire life is not to make any mistakes<br>at all.

I designed a system that I could use to prove that the system I have<br>built is correct. That it doesn't contain mistakes and you can easily<br>test if it does. It's a semantic graph plus verification layer, but not<br>gonna talk about it here.

What I learned is, it's impossible to prove that you are truly right or<br>wrong, because fundamentally we are bounded by reality itself to quantum<br>strings theory, and we cannot even tell what is going on at lower<br>levels. So clearly we cannot infinitely go down and prove everything.<br>This is "The regress argument" that I discovered myself after just<br>thinking very hard with my own brain while I was developing the system.

You might think that Engineering is making complex systems.

It is not.

If you watch Rich Hickey's talk you will understand why. Best engineers<br>reduce complexity. Best programmers find a rusty leaking old faucet and<br>turn it off.

What happens when faucet leaks ? You get a pool of water. And your first<br>intuition is to mop the floor. And if you never ever look up and ask<br>yourself „why the hell am I mopping this every day?", you might never<br>discover there was a faucet installed 10 years ago.

And the one who installed this faucet said in their git commit „it's an<br>MVP, details are in bug tracker ticket ABC-123". Bug tracker gone, that<br>person no longer works there and you are the archaeologist that just<br>discovered this.

So what do you do? Build on top of that leaky rusty faucet?

No, please don't do it. Stop. This is genuinely a good thing you found<br>the faucet and you must write it down immediately as a specification.<br>This is the problem you must at least acknowledge exists because it<br>already "leaks" into your system.

Have you written it down?

No you haven't.

Go back and document this problem that nobody else documented. Oh, you<br>don't know where this spec belongs? You don't write product specs?<br>Well, that's certainly a problem. But you might be the one who finally<br>does. Go read Joel Spolsky's Painless Functional Specifications on how<br>exactly. Then come back here.

Now, here is what I learned.

Engineers are building semantic graph structures in their heads and then<br>they are using it to write the code. The quality of that structure is<br>the most valuable thing. And I figured out how to express this structure<br>with a simple set of database tables, and relations between them.

And this is how Coherence (the project I'm building solo) came to life.<br>But this post isn't even about it.

What I want to show is that complexity is a choice. Simplicity is also<br>a choice. And engineers are building semantic relationships between what<br>product must do and what the actual bounded system — code — does.

And yes, it is always easier to add more graph nodes over existing<br>"monolith" graph with 1,000,000 lines of code.

But the best engineers I have seen are not doing that. They go dig that<br>graph of complexity and figure out how to rip it apart and substitute<br>with a simpler solution.

And once you realize this you will become at least Staff-level engineer.<br>Because now you, my friends, you see where the leaky faucets are and how<br>exactly they produce complexity and work nobody needs to do, after you<br>just fix the "source" of your problems.

Don't mop the floor. Fix the leaky faucet, goddammit.

#engineering

#complexity

#craftsmanship

last updated: 2026-06-05