Don't mop the floor. Fix the leaky faucet. #

I spent 13 years of my career thinking I have to solve every problem 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 why I "lost" again, as if my entire life is not to make any mistakes at all.

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

What I learned is, it's impossible to prove that you are truly right or wrong, because fundamentally we are bounded by reality itself to quantum strings theory, and we cannot even tell what is going on at lower levels. So clearly we cannot infinitely go down and prove everything. This is "The regress argument" that I discovered myself after just 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 reduce complexity. Best programmers find a rusty leaking old faucet and turn it off.

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

And the one who installed this faucet said in their git commit „it's an MVP, details are in bug tracker ticket ABC-123". Bug tracker gone, that person no longer works there and you are the archaeologist that just 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 the faucet and you must write it down immediately as a specification. This is the problem you must at least acknowledge exists because it 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 don't know where this spec belongs? You don't write product specs? Well, that's certainly a problem. But you might be the one who finally does. Go read Joel Spolsky's Painless Functional Specifications on how exactly. Then come back here.

Now, here is what I learned.

Engineers are building semantic graph structures in their heads and then they are using it to write the code. The quality of that structure is the most valuable thing. And I figured out how to express this structure 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. But this post isn't even about it.

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

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

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

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

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