A Realistic Look At Programming
Original Title: A Response To “Programming Sucks,” By Peter Welch
Like a few posts in the past (which, admittedly, have received some amount of criticism), this will be me responding to a few articles and videos. Originally it was meant to specifically target Peter Welch, but that could be a premise for another day.
His article, Programming Sucks, certainly made waves since its publication in 2014. It was entirely reposted on Gizmodo, gained 140,000 views on YouTube (by someone else who read it; it is unclear to me if they are affiliated in any way), and received comments on r/programming, HackerNews, and…er…r/programming.
This will be my summary of Peter Welch’s article, along with some thoughts I have on changes to the industry in general.
A Changing Landscape — Will Programming Ever Become “Normal”?
I have a TikTok link. You may recognize it from Missnicoletsai, who has since changed her handle to nikki_noms — she became somewhat famous for a TikTok of her getting laid off from Google. She is not a programmer, but this 60-second video is the perfect embodiment of something I will characterize as the “tech dream.”
What is the “tech dream”? I don’t know, the term is not real because I made it up just now. In my mind, the “tech dream” is a software-centric career consisting of perks such as a high salary, unnecessary/free office amenities, and an aesthetically pleasing environment you could happily make videos about (unless they are a more secretive company like Apple).
What these videos often overlook is the reality of actually having a tech job. One of my first college experiences from the “outside looking in,” before my internship, was this video:
Is the video above a more accurate depiction of the tech industry? Well, sure…for some people. Programming is a job. Maybe you have a really nice office, or a small cubicle, and maybe you work 80-hour weeks or 40. Peter Welch’s article, as harsh as it may be, still touches on legitimate reasons why programming can be frustrating for so many people.
Incidentally, in the process of searching for it I found this blog post of the same name. Author Ben Jones, associate professor, is obviously a different person with his own perspective. He writes:
At the end of the day, the most modern developer tools are essentially lipstick on a 30+ year old pig.
The biggest issue I have with programming is that in my write/compile/test cycle, when something doesn’t work as expected, it’s really hard to understand why. As far as I know there is no language or tool that, given a large complex program can show a programmer “how it works.” …So what can be done? I don’t know. I assume smart people have been working on this problem for a long time, and nothing they’ve come up with has seemed to stick. Two thoughts: first, why can’t the debugger help point out where things are going wrong?
In the days of GPT, Ben Jones’ vision may be close to becoming a reality. So far ChatGPT is still lacking when asked to self-write code, but Fireship (a popular hybrid YouTube channel, half coding tutorial, half meme) suggested having users create their own “languages” for intermediate pseudocode. In other words, they can avoid having to write code themselves by writing specifications/configurations instead. In theory, this could be a lot better than prompting an AI to “code a calculator app for me,” which is not specific enough to get anything useful.
“Programming Sucks”
I would encourage you to read this. Without his descriptive way of wording things, a lot is lost, but here’s the hypothetical scenario he draws:
- You are asked to build a bridge
- One of your teammates only knows how to work with wood, which is useless for the major metropolitan bridge you are building
- One of your teammates is studying hemorrhaging-edge paving techniques and worked them into the design, so everyone else has to work around that
- Two of your teammates are in an ongoing argument over whether to use metric or imperial measurements, so now the implementation is inconsistent and usually people just force, hammer, and weld their way through things because they can’t figure it out
- Finally, the bridge is a suspension bridge but no one previously on the team knew how to build one. Instead they got halfway through, added support to keep it standing, then invited you (a propulsion engineer) to contribute new ideas
Some version of the dynamic above, Welch continues, is being used on every important piece of software we rely on today.
Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn’t.
Welch goes on to write:
Not a single living person knows how everything in your five-year-old MacBook actually works. Why do we tell you to turn it off and on again? Because we don’t have the slightest clue what’s wrong with it, and it’s really easy to induce coma in computers and have their built-in team of automatic doctors try to figure it out for us. The only reason coders’ computers work better than non-coders’ computers is coders know computers are schizophrenic little children with auto-immune diseases and we don’t beat them when they’re bad.
His other main points:
- As articulated in the above, code is complex. Everyone probably has their neat little “starter program” they once wrote that did a single mundane task well; now we have to make 500 of those
- The infrastructure we rely on is really insecure, and really unstable. To make matters worse, people are constantly adding to it
In a flourish, Welch writes:
Do you want to live in a world like this? No. This is a world of where you can smoke a pack a day and nobody even questions it. “Of course he smokes a pack a day, who wouldn’t?” Eventually every programmer wakes up and before they’re fully conscious they see their whole world and every relationship in it as chunks of code, and they trade stories about it as if sleepiness triggering acid trips is a normal thing that happens to people. This is a world where people eschew sex to write a programming language for orangutans. All programmers are forcing their brains to do things brains were never meant to do in a situation they can never make better, ten to fifteen hours a day, five to seven days a week, and every one of them is slowly going mad.
Some Of My Thoughts
Is Welch’s article exaggerated? Yes. Will it get some people to never pursue the field? Possibly. But the arguments he makes have some legitimacy, and they can even be blamed for some major incidents, such as what happened with Therac-25 and a more recent plane crash.
To put it succinctly, part of the failure with Therac-25 was the “software is cheap fallacy.” Yes, software is cheap relative to hardware and can be easily patched and upgraded — but in the case of Therac-25, crucial safety mechanisms were substituted with fatally poor software.
There are a lot of other points to unpack in the article. The long hours specified are not necessarily the case, and the bridge analogy applies to a point. Because of the relative cheapness of adding new code, code bases can become enormous. The sheer number of dependencies required to set up a simple web application could boggle the mind…unless Jason Knight shows up in the comments section again and proves how he could achieve it with 50 lines of markup and 20 lines of JavaScript.
Balancing The Two Extremes
We could be heading toward a better future, one in which programmers are no longer glorified in the same way and instead of coveting some impossible dream, programmers seek to work reasonable hours for reasonable pay with actual cash, not just stock options or free bananas.
Or maybe it’s a darker future. I don’t know. On a previous post a few people commented on their “boring jobs,” and how smoothly things were going during the time of tech layoffs. Steady growth. Predictable profits. Something straightforward.
