We are bad at programming

Photo by nikko macaspac on Unsplash

I am inspired today because Dan Luu has a mic-drop tweet:

That's some harsh truth! So harsh, I feel like we need to say it again:

We are bad at programming

But what's the solution? Can we make a better programming language? 🤔

There is no programming language—no matter how structured—that will prevent programmers from making bad programs.

      Larry Flon

Oh shoot. Alright then. What about a better OS? 🤔

UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things.
      Doug Gwyn

Ha ha ha ha ha. Well, I have macOh...wait. 🤔

Ahem. Well, there's always disciplined testing and debugging.

If debugging is the process of removing bugs, then programming must be the process of putting them in.

      Edsger W. Dijkstra

Hmm ... so you're saying that you can't debug your code as fast as you bug your code? 🤔

There are two ways to write error-free programs; only the third one works.

      Alan J. Perlis

Hmmm. I see. Well ... great. 😩

The starting point

He actually offers an entire thread on this topic that's worth reading. One of the things he says is that in programming, "we basically have no idea how to improve."

He concludes that the reason for this is that "we can observe that most advice is useless or counterproductive."

Good advice

I don't think he's saying we're 100% doomed. If you read between the lines, he's just offering that perhaps we should put our thinking caps on. I love how Dan's tweet offers a starting point rather than a solution: approach learning as though you are bad at programming.

The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague.

      Edsger Dijkstra

I can tell you a couple hard-earned lessons from my own 14 years of software experience. I know what it's like to be a bad programmer, and to become a better one, so here's a handful of items that might help.

Experience

First, experience does help. It's important to gain your own experience and then to trust it. There will be lessons learned the hard way with meltdowns in production, but those lessons really can't be learned another way. But another simpler way this comes up is that seeing is believing. Everyone should write a lot of code and experiment in a sandbox and observe the results. (REPL's are awesome!)

One huge upside to learning from experience is that it is continual. You're never going to stop having new experiences and so you're never going to stop learning new things.

Keep an open mind and resist dogmatism

Actually, something I've learned in just the last five years is that things you would never dream of doing in one context actually make sense in other contexts. So I've concluded something new: resist dogmatism.

What is dogmatism? It's those "only," "always," and "never" ideas like "Never use a singleton" or "only use Gradle."

Well, guess what? Most of these statements are false, and reality is more nuanced than it first appears. When you're a programmer just starting out it's fine to adopt some "universal truths" but prepare to be surprised and let your grip relax.

Deliberate practice

Third, deliberate practice actually helps you grow a lot. One way to do this is with code katas. Constant deliberate practice is one thing that I have never regretted.

Testing, testing, and more testing

Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.

      Edsger W. Dijkstra

While it's true that testing doesn't prove you have no bugs, writing tests helps you think about things you didn't think about.

All code is guilty, until proven innocent.

      Anonymous

It's mainly for this reason that I approach writing code from TDD.

The main benefit of TDD to me is that it forces you to put your code in front of its first user: the tests. And this results in making your code handle itself much more gracefully.

The way forward

I'm sure there's more I could say, but much of it is out there already, as you can tell from all the quotes in this ramble. Don't forget to at least go read old classics like Clean Code, The Pragmatic Programmer, Working Effectively with Legacy Code, etc. if at least to learn how to reason about code and coding.

May you approach coding as though you are a bad programmer.

And may the users of our software forgive us all.