This content originally appeared on DEV Community and was authored by scottshipp
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."
Dan Luu@danluuHow you should approach improvement is very different in an environment where we know how to make people good, like skiing, where we can observe that advice is often very effective, vs. in programming, where we can observe that most advice is useless or counterproductive.20:11 PM - 28 Sep 2021
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.
This content originally appeared on DEV Community and was authored by scottshipp
scottshipp | Sciencx (2021-09-30T14:39:12+00:00) We are bad at programming. Retrieved from https://www.scien.cx/2021/09/30/we-are-bad-at-programming/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.