There is a huge benefit to not knowing that you're exceptional: you get to try things out like a simpleton would. A simpleton is allowed to mix and match silly things together and no one would bat an eye. Some things would work, and then you'd attribute it to luck, some things wouldn't and it would be expected. The expectations are so low, almost any result is acceptable. And it's a great place to be if one does not have a brain that gets high on dopamine from solving complex, ambitious problems.

I was about ten years into my engineering career when I started to suspect that I might not be a simpleton after all. That is, for the first 30 years of my life I have been quite certain that I wasn't particularly smart. I could code, loved math, but I'd make a stupid mistake every once in a while and the thought of competitive programming or any time-constrained thinking was making me nauseous.

I remember how it happened: I was looking at some popular open-source library code and thinking "Wow, I do know how to do this better. This person doesn't. How come?".

Dare to Simplify

The revelation, as obvious as it seems now, was that a complicated solution does not mean a smart one. Or, as Ernst Friedrich Schumacher, renowned author of a very forward-thinking collection of essays "Small Is Beautiful: A Study of Economics As If People Mattered", put it:

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.

Simple, the way I see it, is what happens when you refine an idea or a solution. I imagine this is how it would feel to chisel a stone till a statue reveals itself. Except the ideas are abstract and malleable, and if you chiseled off a piece you needed - you can reattach it back with no repercussions.

And you'd think - "chisel away, who'd stop you?", except we built our society on the ideals of elite complexity. We write legal documents in a language intentionally ambiguous, we measure academic papers by their length and we still use lines of code as a metric of productivity. Spreading the idea that this is stupid would be seen as blasphemy, wouldn't it? The Simplicity Police would come after you, demanding to stop reinventing the wheel, to do things how they've always been done, to let people bathe in the sea of npm packages in peace and to keep your purist's ideas to yourself.

It's harder to do things the right way, even harder to figure out what the right way is. And, let's face it - the majority of us are exhausted from all the hard mental labour we're already doing.

But that shouldn't prevent me or you from trying.

Dare to Reinvent

I think Andy Hunt and Dave Thomas did us a huge disservice with their DRY (Don't Repeat Yourself) principle. In their book, "The Pragmatic Programmer", they said:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Except, knowledge is subjective. We interpret it in different ways, we use it differently in different contexts. And the codebase is a living organism that is supposed to reflect the current needs and limitations of the system.

I love software engineering because, unlike, let's say, a surgeon, you get unlimited amount of do-overs. You can pick up any piece, redo it, undo it and make it work. As impressive as some digital masterpieces are, the code is closer to a very resilient play-doh than to a marble - it can and should be worked with over and over again. And if you've ever left your play-doh out for too long and let it DRY, you can imagine why I'm not too happy about doing it on purpose with the codebases.

Instead of overly academic DRY and SOLID principles, how about we go for something more creative, like Python Zen:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

I think that's way more fun, way less rigid, and, most importantly, you get to look at your creations with a critical eye and think of ways to continue making it better indefinitely.

Dare to Ship

There is another principle I have a quarrel with.

We had "Done is better than perfect" framed in the Starflow office. I loved working there and I definitely appreciated the reminder that no one is expecting perfection from me. But software is "done" when it is no longer being used and maintained. While it's alive and is in the hands of people using it - it's not done and should be continuously perfected and shipped to the users.

One would think that with all that agile talk we'd learn that small frequent releases mean a couple of days or weeks, not months. I should know - I have a personal project where the release cycle is nearing a year.

I think there are plenty of reasons why it's hard to keep the pace of iterations. Some things do need a little extra time to think through, but I think mostly it's the fear. And the younger the project, the more choices we have - the more we tend to be afraid of making a wrong one.

And here's something I wish I'd leaned sooner:

You want to have people who occasionally get really angry when you're making a well-meaning, but wrong decision about your product. Because that means that they care about your creations and they're giving you the most obvious and precious feedback.

Happy customers are great and what you're aiming for, but the angry ones are the next best thing. And it absolutely beats the lukewarm and polite indifference. The graveyard of projects, if one existed, would definitely have "What a great idea!" and "You know what could be even cooler?!" written on more than one tombstone.

So murder your darlings strategically, cut off everything that doesn't serve the purpose or make the product awesome, ruthlessly and don't let simplicity police stop you from having fun while doing what you love.