DEV Community

Cover image for We are bad at programming

Posted on

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.


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.


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.

Discussion (9)

leouofa profile image
Leonid Medovyy

I like the point about resisting dogmatism. Truth is this advice can be applied to anything.

Let’s look at Music. Look at what Jimmy Hendrix was able to accomplish when he decided to include what others perceived as interference into his music. We can see the same example into the pole vaulting, or the invention of Brazilian Jiu Jitsu.

In terms of getting better as a programmer. It’s a creative endeavor that requires a lot of practice.

Practicing a lot will obviously help, and so will becoming more creative as a whole. Learning music, painting, participating in sports will make you a better programmer.

You will have more places to draw inspiration from. Just look at the idea of “bubble sort”. We’re literally drawing inspiration from watching bubbles.

orioolbs profile image
Oriol Buqueras • Edited on

What really helps me is doing something similar to TDD. If I think of the cases that I have to test, it helps me think and understand exactly what I have to develop. Still, it's difficult to do this in a new environment where you don't know the project that much, but at least it makes you realise of some doubts that you have, and then you can always ask.

scottshipp profile image
scottshipp Author

Another related practice: rubber ducking

orioolbs profile image
Oriol Buqueras

I didn't know about it, I just Googled it and I'm quite amazed, what a method! I'll give it a try, no joke!😂

robdwaller profile image
Rob Waller

This depends on what we're talking about.

Are we talking about coding? Or are we talking about building software?

There are plenty of good coders writing decent code, and we know how to become better coders.

Building software is a different kettle of fish, involves far greater complexity, and lots of different people, not just coders. Do we struggle to build software? Yes. Can we improve how we build software? Yes, but only a small part of the problem relates to code and coders.

ben profile image
Ben Halpern

If there is one step change I'd want to see in software development it is in testing developer experience.

I agree with everything you say here, but I feel like testing approaches these days don't live up to may ultimate satisfactions. The tradeoffs between rigidity and soundness just aren't where I want them to be for my ideal. Even the best tools that exist are quite unsatisfactory for me.

I enjoy TDD and love a good regression test to save my butt and help me contribute with confidence, but having tried a lot of tools out there — some of which are definitely upgrades over the most popular tools, I still feel like everything falls short of where I feel it could be.

scottshipp profile image
scottshipp Author

Hear, hear! I have the same (poor) experience and end up writing a lot of my own scripts to try and paper over the ugly corners of my tooling. But, yeah, this is a huge area of growth for us all to explore together. A hearty amen to that

darkwiiplayer profile image

The one and only principle that allows us to write bug-free code is KISS; with the only downside is that we can even get that wrong.

hdgk profile image

Im to lazy to read the whole thing, but very interesting indeed.