Originally published at rachaelburger.com/blog/re-learning-code-without-ai-with-ai.
Having coded with AI for the past 18+ months, I'd maintain that hand coding skills have little relevance to the modern software engineer's work. Still, when I got a call from a recruiter for a dream job, and when that job required hand coding, I figured it was worth getting back up to speed. Plus, it seemed like a fun meta-challenge in itself: what would it mean to re-learn to code by hand, in only 17 days, with the help of AI?
The first time I learned to code was in 1999. I built a local reviews site (this was long before Yelp) using the LAMP stack (Linux, Apache, MySQL, and PHP), with a PHP book, a dial-up connection from AOL, and a CD ROM of National Yellow Pages data. In the early 2010s, I refreshed my coding skills, this time learning Rails and JavaScript with the tools of the time: codeacademy.com and an app called Dash from General Assembly, among others. These tools were shiny, interactive, sometimes excessively animated or gamified for my taste, and not terribly meaningful. I could repeat until I got things right but never really understood the why. In that era, I built applications for real estate: websites, home price estimators, visualizations, and a variety of Python tools. This time I knew that, with Claude as my teacher, I'd likely move a lot faster.
This learning task was different: I wasn't building something but performing a ritual (in this case, a leetcode problem) in front of someone, articulating my thinking while coding live. To progress quickly, I had to be brutally honest about what I understood and did not understand and what I needed at each point. Like an athlete, I had to push myself to the edge of my ability over and over without completely breaking down, and adapt my program as I progressed.
Drill Problems
The first systems had a series of problems in key leetcode areas, and a series of warmup problems. Each had a scratchpad, a Claude dialog area (which I eventually connected to the scratchpad and submitted solution code), a "check work" button, and optional hints + algo notes. I self-graded my confidence after each pass and low-confidence passes got scheduled for repeat a few days later.
Documentation, Canonical Solutions, Meta-Understanding
I quickly became aware that there were gaps in my knowledge of both data structures and algorithms, so I created documentation that I could study alongside drilling problems. Switching back and forth between solving and understanding at a deeper level (often iterating with Claude, preferably Sonnet 5, over exact definitions and metaphors) proved to be very helpful.
As I progressed in solving problems, I quickly realized that my solutions might not be the optimal ones, and made "canonical" solutions (from the leetcode.com site) accessible in the dashboard, flagged as such in my interface along with my "passing" solutions. For more difficult problems, I'd study the solution first, then write it.
At another point, I found it useful to think about what I was actually learning at a higher level, to ask, what is really being measured here? Pattern retrieval (the ability to recognize which algorithm is right for each problem), procedural fluency (the ability to access needed code without getting hung up on syntax), and working memory. This also helped to refine my focus.
Cheat Sheets, Practice Interview, and Syntax Drills
As interview day drew nearer, I created a one-pager on data structures and another page on algorithms to consolidate my learning. Recursive functions were a particular sore spot. I spent one evening watching hours of YouTube videos on the topic, and concluded that I'll have to make my own.
About five days pre-interview, I did a "practice" interactive interview using Wispr, talking out loud about the problem, and pasting my code from the scratchpad into the chat window. This was a method I had used previously. It's great practice and highlights gaps very quickly. Through the practice interview I learned that I have very little trouble talking out loud/narrating what I'm thinking, that I seemed to have a handle on the time and space dimensions of my solution/potential solutions, and that I needed to shore up my syntax.
For that, I had Claude create some syntax drills by data type, using the data from my cheatsheet. This cemented some concepts in my brain and fingers and helped me feel confident that I wouldn't make unnecessary syntax mistakes in front of my interviewer.
The Experience
As I gave over weekends and evenings to my task, I had to ask myself if it was really worth it. After all, I could do my best, but still fail to grab the brass ring. But deep in the process, I knew the experience itself was worth it. There was something exhilarating about going after something hard, unabashedly, not being sure of the outcome: "playing for keeps" is what our family calls it. My energy was through the roof. Plus, there's something holy about deep concentration. Entirely holy. Whether it's in a cloistered convent (that's another story) or at the Harvard Law School library while everyone else is studying for the bar exam.
This system, over about 100 hours, took me from rusty to running. Though I did indeed fail to grab the ring, I was strangely not disappointed: I had made more progress in 17 days than I had ever imagined. The experience confirmed that the part of my brain that writes code by hand is entirely different from the part of my brain that I use for coding with AI, or talking with customers, or designing production AI systems. That said, each culture has its ritual requirements: the SAT, the bar exam, and leetcode. Without doubt, I'll catch it next time.
Tags: ai, machinelearning, career, productivity
