Best practices and an elephant

Haven't I learned from engaging in bad practices?

Everybody agrees: learn more things. It’s good for you, makes you better.

Learn a functional language, learn an imperative language. Learn about asynchronous programming.

Use an ahead-of-time compiled, statically-typed language, then use a dynamically-typed and interpreted language.

Try frontend, try backend, try CSS, try GraphQL, try REST. Make a game, or build a distributed system.

I could go on but you get the idea. I wrote about some of it a few years ago.

We all agree. Okay, yes, maybe we won’t agree on what exactly is worthwhile to learn – I’m sure I can find someone out there saying one must never try CSS – but I do think the majority of you would nod if I’d say one should learn more good things. Good, proven languages; best practices; great tools.

Lately, though, I’ve been wondering: what about the bad things? Haven’t I learned a lot too from doing the big no-nos, from engaging in bad practices, by doing the opposite of what I once thought was The Right Way?

This is where the elephant comes in. Do you know the parabel of the blind men and an elephant? If not you can click on that link and read about it and come back here, but since no one in the history of reading on the internet has ever done that before continuing to read, here’s the first paragraph:

The parable of the blind men and an elephant is a story of a group of blind men who have never come across an elephant before and who learn and imagine what the elephant is like by touching it.

Each blind man feels a different part of the elephant’s body, but only one part, such as the side or the tusk. They then describe the elephant based on their limited experience and their descriptions of the elephant are different from each other. In some versions, they come to suspect that the other person is dishonest and they come to blows.

The moral of the parable is that humans have a tendency to claim absolute truth based on their limited, subjective experience as they ignore other people’s limited, subjective experiences which may be equally true.

Believe me, I’m fully aware of what a request this is, but: try to imagine now, as a first example, the idea of automated software testing as the elephant.

With that picture in mind, let me ask you this: aren’t you the guy touching only the elephant’s butt if you’ve only ever done TDD and wrote the tests first? Aren’t you missing something if you’ve never tried writing the tests after the code, or, hell, skipping the tests altogether?

I think so. I think that conflicting, contradicting experiences are very useful for learning. The more parts of the elephant we touch, the more perspectives we accumulate, the more comprehensive our understanding of the subject becomes.

So try TDD but also try writing tests last. Try writing no tests and see how far you get.

Try to deploy on every commit, then try deploying only every week, or every month; deploy only on Fridays and then never on Fridays.

Try copy & pasting code, first a little, then a few files. Try to never copy & paste code and only use 3rd-party dependencies. See how far you get.

Automate everything, then try do everything manually.

Add tech debt, ignore a bug, maybe even: reinvent the wheel.

Use a framework, then don’t use a framework, then build your framework.

Use only global variables, make some spaghetti code, have a single file for the whole project.

The important thing is to try different things, to gain perspectives, to touch the elephant from every side.

What’s the elephant? Software engineering? Programming in general? Life? Who knows, but I do believe that seeing it from every possible angle not only makes you better at it but gives you richer experience of it.