Is hand coding becoming obsolete?
Is hand coding becoming obsolete?
Preparing to be a 10x engineer
By now many people have seen John Carmack’s response to a young individual concerned about pursuing a career in Software Engineering.
Software is just a tool to help accomplish something for people — many programmers never understood that. Keep your eyes on the delivered value, and don’t over focus on the specifics of the tools.
There is truth in the above statement. Maybe more than any other field, programming was created to make up for our deficiencies as human beings when it comes to computation, memory, and problem solving. So maybe John’s right. Instead of making a game from scratch using Raylib we should deliver the game using a Game Engine, if our primary objective is making a game. Or make our GUI using electron because that will allow us to deliver our value the fastest to the end user. This is a very pragmatic view of programming.
Those that share this view are able to completely divorce the act of programming, of “hand coding” as John calls it, from the act of solving the problem itself. When I worked in academia, many academics were like this. They weren’t interested in programming on a technical level, didn’t enjoy typing code, and would much prefer to solve problems in other ways if they could. Coding was simply a means to solve the task at hand. If they could solve the problem without coding, they would. And in a roundabout way they did. By hiring grad students, and software engineers to put their ideas into code.
For those people, something like Co-Pilot or ChatGPT are a no brainer. It can automate a lot of the tedium that comes with programming. And if we assume that it will continue to get better, than it is entirely feasible to see a future where workflows don’t include hand coding, even in higher level languages, and to do so would be as anachronistic as writing in pure assembly. But as I demonstrated in my article Geek Mythology: The Religious, and Spiritual Folklore surrounding Programming, lots of programmers like coding, and treat it and the tools they use with reverence.
We form tribes, we tie our identity to being programmers or engineers, we profess our love for our chosen text editor, we meme, we twitch stream programming to entertain people, and we cheer at the top of our lungs when we see instances of Rust’s asynchronous library TOKIOOOO!!!!
It is the act of programming that we enjoy, and anything that takes that away from us robs us of a great pleasure in our lives.
But do we just need to get with the times? I’m not sure. It feels like we are in the phase with programming that woodworking was when we transitioned from Bit brace to Power drill, Hand saw to Table saw, and Chisel to CNC. But while hand tools lost out to power tools at the industry level, there still exists a handmade market for items made the “old fashioned way”.
Coding is different though. While even a lay person would be able to pick up on details that only exist when making furniture with handmade tools, most wouldn’t be able to tell the difference between an AI generated app and a hand coded one. And if the app is proprietary, you couldn’t even verify by looking at the source code anyway. So, if people can’t tell the difference why not use it?
I’ve long been an advocate of coding for fun, making things in niche programming languages, and doing silly things just because, and I’d like to continue to highlight stuff like that on this blog1 But if the suckless2 and handmade network3 are any indicators of the future, then what most people value is not the performant, simple programs, or soon to be anachronistic handmade programs, but the cheapest tools that fit into their existing workflow. They won't care whether an AI wrote most of the code or not. And even if they did value those things, it's certainly not enough demand to support all the current programmers who want to continue coding that way.
“One week, one week, one week, and we had Unix”
- Ken Thompson
But maybe I’m being too harsh on AI tools. You only have to type the word “Epoxy Table” into YouTube to see a myriad of videos from solo woodworking shops and small outfits making a decent living using every power tool imaginable. They are able to churn out beautiful pieces of art that would take months and or many hands to complete with hands tools, in just a matter of days or hours with electronic assistance. So, it’s possible we could see a renaissance of solo programmers finally making their dream program become a reality, and making a living, without needing to start large companies or have access to capital. This was possible before when programs were simpler, with a particularly brilliant mind or dedicated programmer, as shown in Ken Thompson’s (who was both) famous quote “One week, one week, one week, and we had Unix” (23:32 minutes into the video)
By now we’ve seen that there is lots of nuance around this topic and multiple often times competing sides. There is nothing to stop anyone from hand coding programs as a hobby, or in their spare time. There will be people that don’t use the tools out of principle, and those that try to get it banned. There will be programming fields that will fully embrace the technology, and those whose adoption will be slower (like in the medical industry). Many industries have survived similar shake ups, woodworking with power tools, math with calculators, accountants with spread sheets, horse drawn carriages with cars. You’ll hear the phrases “You’ll survive if your good” or “You’ll survive if you can adapt and incorporate the new tools”.
That is definitely true, but there is an underlying thread to all of those statements. “What happens to the thousands of individuals and their families who don’t make it?” The reality is that we will need less programmers if programmers can get more work done in less time. A job that may have previously taken 100 programmers may only now take 10. Sure, the 10 that survive might be the best, but are the 90 that get let go that much worse? Just like programmers like to fiddle and optimize for efficiencies, so do companies, and that includes head counts. With top tech companies already looking for ways to slim down, will tools like Co-Pilot give them another reason to?
These are questions we will have to grapple with in the coming future. And this is all without getting into the weeds around whether AI tools like Co-Pilot or ChatGPT should even be allowed to operate, given the fact that people have found it can spit out chunks of their copyrighted works, indicating they were trained on them, but without their permission4.
The FAQ section of the Co-Pilot5 page titled “Does GitHub Copilot copy code from the training set?” says…
Our latest internal research shows that about 1% of the time, a suggestion may contain some code snippets longer than ~150 characters that matches the training set.
For context, here is what 158 characters of code for my BrainFuck Interpreter written in Pharo (a Smalltalk derivative) looks like, vs the whole function. Make of that what you will.
"158 Characters"
BrainFuck >> iterate [
| code len char|
code := self codeStream.
len := code size.
[self codePointer < (len + 1)] whileTrue: [
char := code at: codePointer.
]
"vs 684 characters"
BrainFuck >> iterate [
| code len char|
code := self codeStream.
len := code size.
[self codePointer < (len + 1)] whileTrue: [
char := code at: codePointer.
char = $+ ifTrue: [ self increment ].
char = $- ifTrue: [ self decrement ].
char = $> ifTrue: [ self incrementPointer ].
char = $< ifTrue: [ self decrementPointer ].
char = $[ ifTrue: [
(memory at: stackPointer) = 0 ifTrue: [
codePointer := loop at: codePointer ] ].
char = $] ifTrue: [
(memory at: stackPointer) ~= 0 ifTrue: [
codePointer := loop at: codePointer ] ].
char = $. ifTrue: [
Transcript show: (Character value: (memory at: stackPointer)) ].
char = $, .
codePointer := codePointer + 1].
]If Microsoft is to be believed, GitHub Co-Pilot already accounts for 46% of code written and contributes to a 55% increase in developer productivity6 This reminds me of a talk Jon Blow gave about a new programming language which would eventually become the basis for his work on Jai7. In it he mentions the friction that current programming languages like C++ cause. He believed that over the course of a large project this contributes to enough wasted effort that a new programming language was worth considering. Maybe Co-Pilot is the silver bullet we were looking for, not a new language. Or maybe in the future, a programming language that is optimized for reading, if we assume that the 46% of code written with Co-Pilot will continue to get larger.
As I’ve mentioned in my previous articles, it’s still too early to tell what will happen to the programming field, and our future with such large-scale frictionless access to large language models. But I think its impacts become clearer with every passing day. I’d like to continue having these conversations until then though. So, when the day does finally come where we might have to make hard decisions about AI, we aren’t starting the conversation from scratch.
P.S
It seems like the concern over the unchecked growth of AI is growing faster than expected. Since I started this article, the future of life organization has released another petition called Pause Giant AI Experiments: An Open Letter, declaring a pause for at least 6 months on the training of AI systems more powerful than GPT-4. If the organization sounds familiar it might be because you read my article titled Treating AI Like Nuclear Bombs where I mention there 2016 petition to ban autonomous weapons powered by AI.
Call To Action 📣
If you made it this far thanks for reading! If you are new welcome! I like to talk about technology, niche programming languages, AI, and low-level coding. I’ve recently started a Twitter and would love for you to check it out. If you liked the article, consider liking and subscribing. And if you haven’t why not check out another article of mine! Thank you for your valuable time.