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.
Top comments (8)
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.
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.
Another related practice: rubber ducking
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!😂
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.
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
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.
Im to lazy to read the whole thing, but very interesting indeed.
~Hotdog