The end of code as we know it
I started learning how to code and play piano the same week. It looked a lot like this:
After a few months of practice, I got pretty good at playing “Let it Be”. I also got pretty good at swearing at a code editor. Why did my piano practice start taking off while my software dreams died in a fire?
A New Syntax
Music theory and Javascript scare away beginners for a similar reason. Both are new languages that need to be understood, processed, and then translated by an instrument/browser into something that others recognize. When you sit down at a keyboard and press any few keys, what happens? In both situations, something pretty terrible because you don’t know what you’re doing. To feel your way around, you need to read the languages.
I felt pretty discouraged as I looked at sight-reading music, with two separate note schemes for treble and bass clef. “You mean the catchy song from Hamilton looks like that on paper? WTF.” After my teacher, Chris, talked me off the ledge and showed me some basic terminology, I was relegated to a basic version of When the Saints Go Marching In. So sad.
Meanwhile, my code was uninspired. Every app I built was as sturdy as Trump’s foreign policy plan. I ended up spending an uncomfortable amount of time on StackOverflow asking for help. After learning Javascript, PHP surprised me as yet another new language and held me back even after I’d learned the basics of databases. There is nothing worse than sitting in front of a code editor with a vision for a website in your head and no way to “make it”.
I was ready to give up on both when my piano teacher tried a new strategy.
Playing by Ear
“Don’t worry about the notes, just play the right ones.” Game changer. I installed an app called Flowkey that teaches how to memorize songs by hand and finger position. After a few hours, I could play the opening chords to “Claire De Lune”. I had no idea what the notes were, but my practice was reinvigorated. Instead of abandoning piano the same way I abandoned drawing after my stick figures started looking angry, I was improving.
The key was immediate feedback. If you press a wrong note, you hear it. If you press the right notes in the order of a song, it feels awesome. Immediate feedback is so crucial to the learning process. In a talk called “Inventing on Principle”, software designer Bret Victor argues that any creative process without immediate feedback is bound to lead to failure and frustration.
“Creators need an immediate connection to what they create. And what I mean by that is when you’re making something, if you make a change, or you make a decision, you need to see the effect of that immediately. There can’t be a delay, and there can’t be anything hidden. Creators have to be able to see what they’re doing.” — Bret Victor (full talk here)
Victor demonstrates how today’s coding environments violate those rules. On sites like CodeAcademy, we’re walked through a mocked up experience where our text changes immediately create something. It’s cool for a minute, but as soon as we graduate to a text editor, we’re left typing nervously and crossing our fingers that what we wrote won’t crash. Instead of enjoying our creation, we spend most of our time Googling ‘uncaught Reference errors’ and trying to figure out where we screwed up. This process is not fun. Although the challenge propels us forward for a while, it becomes tedious, and we give up. When forming new habits, the most important thing is how enjoyable that activity is.
I once went to a health conference, where a professor presented his research into the relative efficacy of different forms of exercise. Interrupting the mind-numbing charts and graphs, a bewildered soul raised his hand and asked, “But how do I know which type of exercise is right for me?” “That’s easy,” the professor said. “The one you like.” Apparently the average exercise regimen lasts about six weeks, so sticking to it in any form is far more important than how you go about it, for everyone but elite athletes. Other studies have found that the most important factor in selecting athletic footwear is comfort, and a major reason interval training is more effective is that it is simply more enjoyable. — Tiago Forte
So how do you make programming more enjoyable? You bring the programmer closer to the software. The people working on this problem are working on the future of programming.
Tools like Webflow and Bubble, while still limited, allow us to get closer to our software creations. Ten days after learning Bubble, I built an app that actually worked. The interface was drag and drop instead of code and pray.
After ten more hours with the software, I had a functional version of Airbnb built (I recorded the process, and you can see it here: https://www.youtube.com/watch?v=tCgD6-FOjtA).
The interface editor was great, but what allowed me to go from zero to hero? It turns out there’s an added benefit to getting closer to your creations: you can tap into past experiences. A great example in music is the how all humans somehow agree what chord progressions sound good and what don’t (if you haven’t seen the power that four chords have on our music tastes, this video will convince you).
“Take the third and fourth chord progression of any major scale. If you play them together, nobody will like it. The sounds aren’t pleasing, it almost feels as if you’re taking a wobbly step backward. We feel this regardless of any music training, and I’ve never met anyone who didn’t share this same principle” — Chris, my piano teacher
The same goes with software. 1.65 billion people use Facebook and internalize how it works every time they login. “When I type in this box and hit submit, my status will get saved and displayed on my timeline” is something we all think is obvious. But it’s crucial to understanding how web apps work. We have an army of potential software creators, all armed with this knowledge, and yet they can’t materialize ideas. Yet.
As these tools evolve, we’re going to see a democratizing effect that brings these unique experiences into play. Right now we largely copy user interfaces from Bootstrap and Foundation. Most websites you go to have some large header element at the top and three smaller feature boxes underneath. Once more of the world gets involved in making these interfaces, there’s a good chance we will see some more originality seep in.
A Programmed Workforce
It is critical to be aware of this shift as our economy moves into one that rewards the ability to think like (and talk to) computers. The rise of coding boot camps shows the pressure on today’s workers to be able to do more with computers than find something in Dropbox and move it to Google Drive (still hard for me).
But we miss the larger point in only focusing on coding. Learning to code is one way to problem solve and master programming thinking. But it’s not always the best way. Many authors have pointed this out in articles usually titled “Don’t learn how to code”:
“Focusing on coding inflates the importance of finding the “right” method to solve a problem rather than the importance of understanding the problem. Before we start working on a solution to a coding problem we must decide what the problem is — and if it’s truly a problem. If we let ourselves become fixated on how to solve a problem via code, regardless of if it is a programming problem or not, and lose sight of why, we gain nothing. — Basel Farag in TechCrunch
Instead of focusing on single skills like learning Javascript or PHP, we need to shift toward the meta-skills needed to thrive in the ‘gig economy’ and beyond. Let’s take the scenario below, and see how a coding boot camp would equip someone versus a course called “Programming concepts: mental models for problem-solving”:
Sarah, a recent marketing hire at a startup, has a common problem: to sell their product, she needs to find out where the competitors are falling short. There’s a treasure trove of data in Amazon reviews.
If Sarah recently completed a coding boot camp, her first instinct might be to build a web scraping tool to pull the reviews from competitive products on Amazon, and then code a front-end interface to navigate and filter through those reviews. She would eventually get the right data, but it could take a while.
If she instead went to a ‘problem-solving in the 21st-century boot camp’, her training would lead to a search for a broader toolkit: searching Product Hunt’s database of products, checking the boundaries of Google Sheets, and exploring existing Amazon integrations. It takes significantly less time to realize that by plugging a tool like Blockspring into Google Sheets, she could pull all reviews directly into a spreadsheet and filter + sort by the keywords needed.
While a focus on learning to code will give you a deep toolkit to reach into, it’s degree of difficulty and time to competency will limit you from looking at other toolkits. This is explained best in humans by two cognitive biases: anchoring bias and sunk cost fallacy. Ex: if you spend $12k on a toolkit (average cost of a bootcamp), you will want to justify using it as often as possible.
Naval Ravikant, the successful investor and founder of Angelist, is a shining example of the mental models approach. Naval is a proponent of “guiding principles” to learn faster and make better decisions. In a recent podcast, he was asked what part of his education was most impactful:
“The part of computer science that was very theoretical, like mathematics and algorithms, was actually the most useful because that stuff doesn’t change over time. The part that was learning to program in Java or Fortran was useless or less useful because it fades over time. I would probably do more math, more physics, stick to micro-everything. I would probably have studied some psychology and some evolution because I think those are really important to understanding how humans work. At the end of the day, you’re interacting with humans everywhere you go. I would have focused on theory and principles over facts. Facts fade or facts can be looked up. Your most important skill isn’t even what you majored in or even what you studied, it’s just knowing how to learn. If you have a good grasp of mathematics and if you like to read, there’s nothing you can’t learn on your own.”
Meta-skills don’t fade. Instead, they allow you to learn new skills faster. So why don’t we have programming meta-skill boot camps popping up everywhere?
The issue is one that shouldn’t surprise us: our world is increasingly programmed for short-term thinking. Are 6-second snapchats to blame? I won’t get into that here, but startup founder Tim Romero had to shut his company down because of this trend, and brought up some good points:
I was fighting human nature and losing. Everyone swears they will eat right and exercise, but most don’t. Everyone agrees they need to spend less to be financially secure later, but most won’t. Our users were telling us they would use ContractBeast to achieve those long-term benefits, but most weren’t.
The immediate appeal of a coding boot-camp is short-term ROI. “Pay us $12k now, get an $80k job as a developer later.” It’s hard to compete with that. “Learn mathematical models that you can use for the rest of your life” just isn’t that sexy unless you’re posting that flyer in an MIT cafeteria.
One possible solution? Disguise mental models in project-based learning. I’ve been experimenting with this teaching method at the Code-Free Startup and it’s been successful so far. Yes, the ROI is short-term: “Build app X without code.” But free of the syntax of code, it allows students to explore broader concepts around user experience and thinking like a computer.
Moving Forward
Something that has been harming the progression of these ideas is the battle over the idea of the “end of code”. I’ve seen it many times before.
Most recent example:
- TechCrunch runs piece called “Don’t Learn to Code”
- Quincy Larson responds with “Please Do Learn to Code”
- Twitter battles, long-winded comments on HackerNews, etc.
- Both sides retreat, lick wounds until next battle
It needs to be possible to strike a balance. There will always be great reasons to learn how to code. One irony is that the code-free movement is trying to free up engineers time to work on the unique things that actually make a company stand out.
Engineers around the world are re-writing things like authentication, shopping carts, messaging, and countless other ubiquitous features. And a lot of them are probably feeling pretty cool about it. These are just a few examples of how engineers waste time duplicating the same basic features over and over. — Lauren Mendoza in “Coding is Over” (also see response after by Quincy)
If this tension between camps seems new, it isn’t. Technology is moving so quickly that we fail to learn from the past. In the 1960s, binary programmers at IBM were practically pulling at their black ties over the heresy that was assembly language.
Finally, a more complete, and more useful, Symbolic Assembly Program (SAP) was devised — after more years than you are apt to believe during which most programmers continued their heroic absolute binary HISTORY OF COMPUTERS — SOFTWARE 25 programming. At the time SAP first appeared I would guess about 1% of the older programmers were interested in it — using SAP was “sissy stuff”, and a real programmer would not stoop to wasting machine capacity to do the assembly. — Richard Hamming (link to PDF)
Is the “end of code” the same as “the end of binary?” No, and there’s a long way to go until most of the apps we use daily are made by drag and drop interfaces. But if both sides can learn from the past and collaborate, I think we’d make the next transition much smoother:
- Coder: I really hate building login screens. I just want to build cool things with TensorFlow.
- Non-programmer: What if I could drag + drop the login screens with the help of a designer, and you could focus on the cool stuff that will make our app unique?
- Coder: Cool. Let’s be friends.
Whatever happens, it’s an exciting time to work at the cutting edge of programming. Whether it’s the code-free revolution or even Wired’s prediction that “we will train computers like dogs,” the only way to find out is to keep building.
Thanks for reading. If you liked this piece, please help me out by clicking the 💙 below. You can follow me on Twitter and check out my newest project, The Code-Free Startup.
