There are several concepts that are integral to being both a great software developer and, frankly, a great human being. Most of these do double duty.
In short:
There ain’t no such thing as a free lunch
Look down that road
Less is more
Murder your darlings
Code just in time
The Seven Ps
These are closely related and often overlap.
The most important practice for any dev (or human) is to fully grok the significance of a phrase popularized in part by the sci-fi author Robert Heinlein in his best work, The Moon Is a Harsh Mistress. He called it TANSTAAFL:
There ain’t no such thing as a free lunch
There are many other similar formulations in English, each spotlighting a different aspect:
To eat one’s cake and have it to†
A “get out of jail free” card (Monopoly)
Something for nothing
You can probably think of others.
Eating one’s cake but still having it is like the goose that laid the golden egg. Essentially, you don’t have to pay for the cake again by buying another one, you can just keep eating it forever. Sweet!
Getting out of jail free means not being held accountable for your actions. This is the number one aspiration of all infants. You get to do the crime but you don’t have to do the time. Sorry, Baretta.
But then Robert Blake came very close to proving this true, escaping a criminal charge for murder but losing the civil case. Nice try, Robert. You should have watched your show.
But all of these idioms essentially reduce down to the third one: something for nothing.
There is no such thing. Despite fervent belief by most humans:
No one ever gets away with anything.
Never. There is always a cost, a consequence, even if it is merely the destruction of your soul. You cannot commit rape without becoming a rapist, and you cannot commit murder without becoming a murderer. And that shit don’t wash off. Ask Lady Macbeth.
Yet who would have thought the old man to have had so much blood in him?
Paul Virilio, the French cultural theorist and æsthetic philosopher, coined the term the integral accident to describe a phenomenon he had observed, namely, that there is no such thing as a free lunch.
Virilio noted that:
When you invent the ship, you also invent the shipwreck; when you invent the plane you also invent the plane crash; and when you invent electricity, you invent electrocution ... Every technology carries its own negativity, which is invented at the same time as technical progress.
An example of this viewed from the opposite pole is Isaac Newton’s Third Law of Motion:
To every action, there is always opposed an equal reaction.
There is a cost to every action (and, often, a cost to every failure to take action).
Too often devs (and humans in general) act without thought for the consequences or the costs. These costs are not limited to the price paid for a product or service, but include also the opportunity costs: the others options you gave up when you chose one.
The first rule of life and software development is: Look before you leap. Consider the consequences of your actions and of not taking those actions before you act (or choose not to act).
Look down that road before you travel it
I have mentioned elsewhere that William S. Burroughs, the seminal Beat Generation writer, admonished his readers in the foreword to one of his books (I thought it might be Junkie, but damned if I can find it now), to “look down that road” before choosing heroin addiction.
That turns out to be excellent advice in all areas of life, not just drug use.
It is not enough to limit ourselves to the proximate costs of our activities. We need to keep Virilio’s “integral accident” firmly in mind and consider the long term consequences of everything we do.
For example, when the inventors of Facebook (whoever they really were) came up with the idea, did they stop to consider the long term effects of social media?
Did they discuss the proliferation of propaganda, online bullying, echo chambers, censorship, the end of privacy, the global surveillance state, the effect on society and interpersonal relationships, etc.? Or did they think only of how cool their app would be and how filthy rich they were all going to get?
I think we can guess the answer to that, and we are all worse off for it. After all, the app began as a way for college upperclassmen to identify potential freshman date rape victims. Why do you think it is called “face” book?
That said, it took a woman to help invent Tinder.
Most devs, and perhaps most humans, are gleefully engaged in activities that have gruesome consequences for others, and for themselves, right up to and including the extinction of the human race. But we never look down that road to see what it is we are creating.
We just assume that we’ll be given a get out of jail free card. Good luck with that.
Less is more
The architect Ludwig Mies van der Rohe coined the phrase “less is more” in reference to minimalist architecture.
Actually, the phrase can be traced back to the German poet Christoph Martin Wieland who wrote “Und minder ist oft mehr, wie Lessings Prinz uns lehrt“ (And less is often more, as Lessing's Prince teaches us) via Robert Browning’s poem Men and Women (1855): ”Well, less is more, Lucrezia”.
The idea is, simply, that one should not build anything not needed for the accomplishment of the goal. This presumes, of course, that you considered the cost and looked down that road before you set the goal. Yeah, how likely is that?
This idea of not adding gratuitous features was captured by William of Ockham, who put it simply (if he did indeed say this):
Do not needlessly multiply entities.
This is known as Occam’s razor in philosophy where it is a “problem-solving principle”, but its applications range so much more widely.
It is often mis-paraphrased as “the simplest solution is the right one”. But that is wrong. Utterly wrong. It has left out the key word in his admonition, which is “needlessly”.
Hence it is not enjoining us to pick the simplest “solution”, but the simplest solution all else being equal. In other words, if the simpler solution does not solve the problem equally as well, then it is not the better solution.
That’s important.
What Ockham is really saying is, less is more: add only necessary features to your product or service and then stop. Add nothing more than is necessary to accomplish the goal.
As I like to put it: no gratuitous nothing.
Murder your darlings
This is another oft misattributed quotation. The true original author was Arthur Quiller-Couch. He wrote:
If you here require a practical rule of me, I will present you with this: ‘Whenever you feel an impulse to perpetrate a piece of exceptionally fine writing, obey it—whole-heartedly—and delete it before sending your manuscript to press. Murder your darlings’.
He was referring to writing, but this applies equally well to all creative efforts, including especially coding.
We get our egos attached to certain turns of phrase or certain ideas or certain lines of code, and our critical faculties fail. Those lines of code have no business being there, but we just like them so much we can’t let go.
LET GO. Murder your darlings.
If you can’t rationally justify the inclusion of some object or idea, then leave it out. You may think it is oh-so-cool. I promise you that the next dev will think it is self-indulgent junk.
Be ruthless. To hell with Ruth.
As many wits have commented in different forms over the centuries, the way to sculpt an elephant is to get a block of marble and chip away anything that doesn’t look like an elephant.
Easier said than done. But a good way to refactor is to keep removing bits of code and check if everything still works. If it doesn’t, put the code back. If it does, repeat the process until there is nothing else to remove that doesn’t affect the functionality.
And the best way to refactor is continually, as you code. Keep it lean as you go.
Do it “just in time”
I have mentioned many times—perhaps because it was a life-altering event—something that Guillermo Rauch said to me more than a decade ago as I was showing him my “darlings”, namely, an absurdly overengineered app of which I was stupidly proud:
Oh, Charles! Never write a line of code until you have to.
That moment was an earth-shaking epiphany for me. Let’s just say the lights lit up and sirens sounded.
The irony is that I had been saying this same thing for nearly two decades, but in reference to learning:
Never learn anything until you have to.
In short, given the longevity of most knowledge and skills, especially in coding, which can be measured almost in microseconds, don’t learn anything until just before you need it.
Learn too soon and it will rust, bust, and collect dust; learn to late and, well, it’s too late. Rather than learning “just in case” or “just too late”, learn “just in time”.
Why the hell had it never occurred to me to apply that to my coding?
Well, to be fair, I was a sole entrepreneur back then, so the jobs I got tended to be fairly simple. How then to learn more powerful approaches? So I overengineered on purpose.
Of course, this was also violating my “learn just in time” principle, but I was so eager to try tools such as RabbitMQ that it mattered not that I had no use for a message queue.
In short, I forgot to murder my darlings.
Once I began to apply his advice, which I now call “just-in-time coding”, my coding improved dramatically and I became far more effective and efficient.
But I must admit that unlearning past bad behavior was quite onerous and I often caught myself looking longingly at powerful tech that I absolutely did not need.
Never write a line of code until you must.
The Seven Ps
This is one more practice that is often forgotten. I originally heard this in a Dirty Harry movie (damned if I can remember which, but I can hear Clint Eastwood saying it) as the “Six Ps”:
You forgot the Six Ps: Proper planning prevents piss poor performance.
Years later, I discovered that some use the Seven Ps: proper planning and preparation prevents piss poor performance. I am not sure that the “preparation” really adds much, but just to be sure, I am going with the Seven Ps here.
Too many devs get excited and jump straight to coding. Coding, prototyping, and wire-framing can help with planning, but planning is the key to successful coding.
I’m not talking waterfall here: that’s about specification, not planning.
Planning, asking around, looking to see how others have done it, considering your options: all these make for better code. And sometimes reveal that you don’t need to code at all.
So there are seven best practices that can make you a great coder. More importantly, all of them can equally be applied to life itself, and can make you a happier, healthier, better human being. Have fun with them.
† ”To eat one’s cake and have it to” is often said backwards, probably more often than not. But it is easy to have a piece of cake and then eat it. It is quite a bit trickier to eat a piece of cake but still have it. Putting it the right way around makes the intent clearer.