Things I learned while teaching a complete beginner how to code

One of the best things going on in my life is a deal I have with my close friend and post-college roommate, Eujin. He's a Michelin-star-chef-turned-chemist who wants to learn programming to really stand out in his field (as if he needs to more than he already does). So, we have an agreement where I regularly give him coding lessons, and in return he cooks incredible food for me and even teaches me some of his cooking techniques. It's not rare that I get a text at 11:30pm that he's on his way to deliver some sushi he made from fish he caught that same morning.

Eujin started his lessons at zero - we started with what it means to code, what a variable is, etc. He's already made a load of progress though; he can confidently write programs with good OOP techniques, clean code, and fairly advanced patterns. He recently started solving some LeetCodes as well.

As someone with absolutely no background in teaching or education, I learned a lot about what it's like to learn how to code, and how to teach it. In this post I'll go over some of them. It details some of the hard parts of the learning process where he struggled, so I want to highlight that Eujin is an incredible learner, terribly smart, and is easily the most driven person I know.

Nothing is obvious

This one seems like common sense, but as someone who's been coding for about a decade, it's easy to forget. The concepts software engineers utilze without even thinking take a while to understand when you encounter them for the first time. And there's a lot of them!

For example, he had a lesson on calling APIs. In it, we tried to discover attributes about Pokemon by sifting through a public "Pokedex" API. It returned big objects with nested objects, arrays, etc. I told him "okay, follow the keys and the list indices to get this Pokemon's first attack name". He understood dictionaries (Python) and lists very well, but it hadn't dawned upon me that combining all these things in a complex way is not easy. I was a little frustrated because he was struggling to get the concept until I realized: he was never explicitly told you can chain expressions together. He knew what moves[0] meant, and he knew what pokemon["farfetch'd"] meant, but he didn't know he could write pokemon["farfetch'd"]["moves"][0]!

There are so many little concepts in programming that no matter how thorough your teaching is (and mine was far from thorough), you will miss some. Lesson learned: break down everything, and when in doubt, lead with an example.

It's okay to spoonfeed, sometimes

I learned how to code by trying things on my own, breaking them, then eventually posting on forums. People on small community developer forums in 2013 were not the friendliest. Almost every answer I got to my questions had some level of condescension to it. In addition, the rule of the forum was "don't spoonfeed". It was against the policy to answer a question with a snippet of code showing how something worked.

Because of that, I always taught in a way that avoided spoonfeeding. I would explain a concept with an example, then task Eujin with a relevant problem to solve. I would give only minimal hints. My approach was to ask leading questions and have him arrive at the answer himself, so that he could understand why the answer is what it is.

This approach takes a lot of time, and a lot of mental energy. It worked sometimes, but some lessons we spent a whole hour on one topic because I would quiz him, and when the answer was wrong I would guide him step-by-step to the right answer. It was frustrating for both of us (and he took it out on me during his cooking lesson), and it didn't really pay off.

One day, I decided to let that go. Instead of guiding him to arrive at the answers mostly by himself, I handed him the answers. He would ask questions about things he learned a while ago and forgot (like how to define a string), and instead of having him think about how to define a variable, what a string is, and how the code knows you want a string, I told him "you put quotation marks around it".

He understood, and since then he's never forgotten how that worked again. More notably, that lesson (which was about using external libraries) was the lesson where he had his "click".

The "click"

I've always kind of believed that at some point in the process of learning to code, it all "clicks". I'm not talking about understanding specific concepts thoroughly - I mean coding in general.

We all know learning how to code is hard, especially when you're first starting. The concepts are all foreign. You're thinking in a way you've never thought before - through a computer. But every single learner, whether or not they have a "natural inclination" for logical thinking, will eventually "click".

When they click, what they're really understanding is how to think like the computer. When Eujin clicked, he started understanding, effortlessly, how functions were invoked, how code should be organized, why the best practices he'd learned exist, and, most of all, how to think through a programming problem.

Getting to see that happen, literally in an instant, was the coolest thing in the world and it all paid off for me in that instant. I think he realized it then, too. He asked a bunch of questions about "so X works like this?" and his notions were all correct. This was a big change from before, where he would struggle to even find the right question to ask. It was a complete transformation in a very brief moment - triggered by having an answer spoonfed to him.

Takeaways

• Anyone can learn how to code, as long as they want to. So many people say "I just don't have the mind for it" or "I just don't think that way" - but those are just frustrations stemming from learning "pre-click". Anyone can develop the mind for it. Just keep trying.
• Throw away old gatekeepy forum culture of never spoonfeeding answers or nitpicking everything. There is no merit to it. Sure, some people learn better by deducing the concepts with little guidance, but most people don't. God forbid someone copy/pastes your answer for their educational project.
  • When you learn a spoken language and you make a mistake or don't know how to say something, you will be told the answer directly. And, through repetition and familiarity, you will eventually learn. You don't need to understand every single inner working of the language to speak it.
• Be aware of your assumptions. That's a skill software engineers as a whole use quite a bit - a huge portion of production bugs can be attributed to poor assumptions. But it applies in teaching as well. Don't assume your student knows a concept that seems trivial to you. If it's a pattern of code they haven't written before, teach it explicitly. Every time.

I hope the things I've learned alongside Eujin can help you teach others, from total beginners to your smartest coworker. There's a trend of programmers becoming less mean to each other and more supportive, and I really hope it continues that way, because it facilitates a much more inclusive and effective learning environment. And, I hope you walk away from this blog post with as much appreciation for Eujin as I have.