Learning to Code is Non-Linear

I started programming 10 years ago this fall. I can’t quite believe how much of my life has been impacted by it, and in many ways it’s shaped who I am today. Though it’s a big part of my life, I’ll always remember how tough those early years were for me to learn how to code.

In 2005, I entered college without all that much of a clue of what I wanted to pursue. I think I was drawn to trying out computer science since I enjoyed playing with computers and helping others troubleshoot issues, but there was not much else in my motivation. My introduction to ‘real’ programming was in a large intro to engineering class of 200 undergrads at the University of Michigan. I struggled quite a lot in those early years, and for the longest time I thought I was the only one in my class who couldn’t fully get it. Because of that feeling, I was so close to concluding coding just wasn’t right for me.

I’m so very glad my 19-year-old self stuck with it, since I owe much of how I think and understand the world to programming. It’s taken me quite a long time to realize that the feeling I had in those early years is something almost everyone experiences when learning to code. I’d love to dig into why many people find it tough when first learning to program, what the true value of programming is, and what someone who is just starting out learning to code can do to push through those early struggles.

Non-linear learning model

The toughest challenge for me in those early programming classes wasn’t the actual learning of new abstract concepts. Instead, it was the feeling that I was moving much slower than my peers sitting next to me. I remember that sinking feeling of falling behind on simple early assignments — and at the lowest point, having to resort to copying off of others in order to pass the class. This was the first time in my life I wasn’t good at something, and I was ready to conclude this wasn’t for me.

What I didn’t understand at the time was that this was the first time I came across a discipline where learning is non-linear, and that there is an inflection point within that learning. Everyone hits that point at different times, some way sooner than others — but for the most part, those that stick with it will hit that point of understanding. An inflection point in a non-linear learning paradigm is when everything starts to click, and further concepts are easier to understand. You’ll know you’ve hit that point when you say: ‘Holy crap… I totally get this!’ It took me years to hit this point, while others came into the early classes already there because of past learning experiences.

This is a key challenge for teaching programming. Most schools take on the approach of how other core subjects are taught. In core subjects like Math or English, everyone typically starts at similar levels. Through learning the fundamentals over the years, everyone generally progresses in understanding at a similar rate of change. This is why generalized curriculums for core subjects work well. For example, we can say that most 1st graders should learn addition, 2nd graders should learn multiplication, 8th graders should learn algebra, and freshman college students should learn calculus, etc. In this model, you learn linearly, and you’re regularly tested and compared with your peers as you build on the various fundamentals.

Programming was taught to me in a similar way — and for students to attain true understanding, this doesn’t feel like it’s the best way to learn. There is a literal learning curve to programming, and once you hit the inflection point of that curve you become somewhat self-reliant. You know what to ask Google, you know the process of debugging, and you start to realize you’re capable of accomplishing anything by yourself. But if you haven’t hit that point yet, it can feel like you may never hit that point. Traditional methods of testing and gauging progress among students who are at different points in their capacity to learn programming don’t feel quite fair, and I believe this discourages many (particularly underrepresented minorities) from continuing to learn how to code.

Learning by Doing

I didn’t realize what I was capable of until after college, when I started building my own Android apps for fun. I had never worked with Java, or ever built an app solely by myself. Being fueled by my own project, I hit many stumbling blocks — but that motivation of building something by myself kept me going. It was the first time I wasn’t tested or judged, and so I could build for my own enjoyment. Countless tutorials and Stack Overflow questions later, I had built and released a couple of Android apps to Google Play. Perhaps more valuable than the apps themselves was the confidence and building blocks I had gained to learn for myself.

That attitude of learning through side projects has always stuck with me, and it’s the main way most programmers learn new platforms, frameworks and languages. Being in an environment that is focused on building, rather than being judged on progress, is indeed the best way to learn.

Leveling Up

Once I realized I could indeed build something from scratch by myself, this ignited a fire to build more. And the most valuable part of building something is the learning process.

Programming gave me a practical way to understand how valuable self-learning is. We live in a great time where the internet gives us a new way of learning, and self-motivated learning is so powerful. You end up creating this flywheel where the more you learn, the more you want to do. The more you want to do, the more you learn. It’s an incredible feeling, and there really are no bounds to how much someone with this mindset can accomplish. You feel like you’re continuously leveling up.

In my journey at Buffer, I’ve been so fortunate to be able to jump into so many different areas and situations I’ve never dealt with before. I’ve had to help build the engineering team to now 20 people, help architect Buffer in a way that scales to millions of people, and ensure Buffer is secure for our users. Pretty much everything that I’ve done at Buffer has been something I’ve had to learn for the first time on the job. The same is true for every engineer on the team. It’s truly a continuous learning process that’s been embraced since hitting that coding inflection point.

Systems level thinking

It was programming that exposed me to the notion that I could learn and gain a deep understanding of what initially seemed like an overly complex topic if I had the right motivation. It’s taught me to not be afraid of learning curves, which is key in trying to understand complex systems — something that’s core to running startups and organizations. For example, development is really about connecting different subsystems together to accomplish a set of tasks. Buffer, the product, is a set of different systems working together. Similarly, Buffer the company is also a set of different systems working together. How we’ve organized ourselves into smaller teams of roles is another type of system. The market Buffer is in is a system. Coding is a way to practice working logically with systems.

Programming teaches the process of thinking logically, breaking down seemingly complex problems into much smaller, solvable chunks. It helps teach how to break down abstractions, which is key to understanding how a system works. This feels like the real value in what programming provides.

Breaking down the Barriers of Coding

I often think back and wonder what I would be like if I hadn’t stuck with coding. I’m quite grateful for how many opportunities learning to code has given me, and I owe so much to the ‘skill’. Still, I wonder how many of those who don’t stick with it leave before reaching that inflection point because of that same struggling feeling I had early on.

When teaching and learning how to code, it feels quite key to optimize for reaching that inflection point of understanding. I’m quite excited to see so many different developer bootcamps and project-based programming classes and websites crop up in the past few years, as they seem to strive to do exactly that.

I often have friends ask what’s the best way to learn how to code, and I’m ashamed to say I don’t have concrete steps (yet!). What I can say is everyone feels lost early on — try to ride the motivation of building something on your own from scratch to get you through those tough moments and to that inflection point. And when things do feel super tough, reach out to me and I’d love to help!

If you’ve had a great experience on getting to the inflection point in learning to code, I’d love to hear about it! Hit me up on Twitter :)