by Gordon Zhu, October 2022
What people want (2014-2015)
What people need (2015-2020)
Better systems (2020-2022)
Design (2022-present)
In 2014, it was clear that AngularJS would become the dominant frontend framework of its time. Everyone wanted to learn it, but there were few resources available.
I knew it well from my work at Google and I wanted to teach programming. It was a golden opportunity. My first set of video tutorials quickly gained traction. Within months, I was able to make a living out of it.
The excitement quickly wore off however after seeing a recurring problem. Programmers with computer science degrees and years of experience would ask questions that showed little to no understanding of basic programming. At first, I shrugged it off, assuming they must not be applying themselves, but I slowly adjusted to reality after seeing this over and over again.
They couldn't actually program in any substantive way. Instead they were running a type of copy-paste process with lots of trial/error. This felt too serious to ignore; I had to attack it directly. I suddenly found myself facing a much more daunting problem, what would a completely reimagined computer science education look like?
I designed a new experiment. I'd find a total beginner and tutor them until they got the basics down.
After a few weeks, I found a test subject at a local meetup. I met with him every weekday for almost a year. At the end of the week, I'd take the things that worked and turn them into videos so that others could benefit. My aim was to have the videos approximate, as closely as possible, the experience of my one-on-one lessons. These videos eventually turned into a full introduction to programming course. I named it Practical JavaScript.
This course got a lot of things right and pioneered some teaching innovations that have endured to this day.
In short, I emphasized the habits of mind behind what I consider good programming.
Students wanted more. I quickly produced more lessons that went beyond the introductory course. This extended set of lessons became part of a paid subscription.
The innovation of the paid program was an unusual emphasis on reading and understanding large, existing programs. This is how I learned to program and was key to how I improved over time. I wanted to share this power with others.
I worked tirelessly on this for several years, showing students how to pick apart increasingly more complex codebases. Students loved the approach, but inside I was hurting again, in a similar way that I had before.
There is no doubt that good things did come out of my work. Students earnestly liked what I was doing. They got jobs. They enjoyed the community I had built and gained life-long friends. Behind the scenes though, I was concerned.
When I asked students questions, I did not feel that they really grasped what I was saying. In short, their performances did not meet my expectations, and I saw that as a failure on my part. Though this was progress, there was much more to be done, and a library of videos, no matter how well-made, was not going to get me where I wanted to go.
I did not know it at the time, but I would abruptly tear down everything I had built and start again.
When you go from making a comfortable living to making nothing, completely by your own doing, you learn something about yourself. For me, I finally understood how important this problem was to me. I wanted to get the best out of people and push them to their theoretical limits.
As a baseline, I had to first create a system that would only allow students to continue if they really got it. With just a handful of students now, I could do this manually. I turned almost everything into an assessment and set strict standards. Students could only pass if they met or exceeded the standards. I did everything in the most insane way, because I wanted to learn as much as I could about every little thing.
This new system was beautiful and terrifying. Some students flourished and did astounding things. For others, it was too much. It was not uncommon to see a student attempt an assessment 20-40 times, and still not pass. This was the nature of holding people to a standard. And this would create ripple effects in other areas, especially admissions. It was important that we only worked with students that had a chance of succeeding in this unusual environment.
This new system allowed me to create a completely reimagined curriculum focused on problem-solving. I wanted students to systematically develop the ability to solve increasingly difficult problems. This gradual growth is only possible if there are guarantees that the student is ready for each step. The new system provided those guarantees. I always held this to be the mother of all skills. I finally had the system I needed to pull it off.
Through experimentation, I learned about the limits of each student. Knowing these limits, I could then figure out how to extend them and by how much. I learned how to create incentives that encouraged good behavior. Starting from zero students, I slowly added more to see if my methods held up. Eventually, when I was reaching the limits of what could reasonably be managed across hundreds of Google docs, I codified what I learned into new software that was designed precisely to run this new system.
The systems I had built were extremely effective at helping students develop technical competence, but there was one final piece, design. You can think of it as taste, judgment, or something else. I still don't know exactly what I should call it.
You have two programs, they are both correct. One is pleasing and simple, but the other is ugly and gives you a headache. This is what I mean by design. It turns out, good design, at least the type I'm describing, is chiefly a symptom of clear thinking. The headaches are a symptom of muddled thinking.
Here again, I ran an absurd number of experiments. The essential steps are that I laid out my own process for designing programs, in excruciating detail. At every opportunity, I explained my thinking, to concretely model the ideal behavior. Each time a student submitted an assessment, they'd get a design grade, detailed feedback justifying that grade, and tips for improving the next time.
I stubbornly and foolishly tried for many months, to hold students to a strict standard for design, but this was utterly futile. Instead, my new strategy has been to as clearly as possible, showcase good design in my solutions. The hope is that when the student compares my solution against theirs, they feel a natural discomfort, even embarrassment, and will want to close the gap. In other words, make the gap as clear as possible, blow it up in their faces, but do not hope for miracles.
That is where we are today. Though I am still not satisfied, I am also not so unsatisfied that I want to destroy everything.