We are bad at programming
Tags: programming, beginners, career
Published: 2021-09-30 14:39:12

---
title: We are bad at programming
published: true
description: Dan Luu finally said it out loud. Now what do we do about it?
tags: programming,beginners,career
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n472gv2tg31bn34u865y.jpg
---

> Photo by [nikko macaspac](https://unsplash.com/@nikkotations) on [Unsplash](https://unsplash.com")

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

{% twitter 1442945072144678914 %}

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&mdash;no matter how structured&mdash;that will prevent programmers from making bad programs.

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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.

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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.

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Alan J. Perlis

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

## The starting point

He actually offers an [entire thread](https://twitter.com/danluu/status/1442945072144678914) 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."

{% twitter 1442945084975054849 %}

## 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.

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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](https://codingdojo.org/DeliberatePractice/) actually helps you grow a lot. One way to do this is with [code katas](http://codekata.com/kata/codekata-intro/). 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.

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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.

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Anonymous

It's mainly for this reason that I approach writing code from [TDD](https://en.wikipedia.org/wiki/Test-driven_development).

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.