Learning to Code in 6 Months — A Product Manager’s Journey

Photo by Christopher Gower

After working for five years as a product manager, I wanted to learn how to build new products myself to prototype some ideas. As a PM, I was fairly comfortable wireframing and doing some designs, but I’d never needed to build it. However, this past year, a few of my peers who had come from computer science backgrounds mentioned it was really helpful knowing how to code, especially as a PM. I initially picked up a Javascript book (out of curiosity) and started teaching myself how to code for a few hours on the side with the goal of learning full stack development.

I practiced many codewars challenges and then enrolled in Hack Reactor (a bootcamp) where I spent 80 hours a week learning full stack development. It’s been a crazy journey and took six months. Here’s what I learned along the way:

1. Engineers deserve a lot of credit: I always had respect for software engineers but coding for 6 months made me respect them even more. There is no “small change” in a product and it takes a lot of work to craft beautiful products. Also, it takes a lot of work to make products at scale. One of the projects I worked on was building a microservice for a Twitter clone while dealing with more than 10 million data points (a tiny fraction of the volume Twitter faces). Optimizing for read speeds, write speeds and understanding system design and architecture even on that scale was hard and took much longer than I expected.

Anyone who teaches you “how to build twitter in 4 weeks” is oversimplifying complex problems. You can probably prototype it, but the products we use and love on a daily basis are complex.

2. Everyone can benefit from learning how to speak technically:

Think of coding not just as a skill, but a language. No matter your specialty, being able to speak technically is important if you work in technology.

Elements like understanding deeply what a server is, how the front end interacts with the backend, what an API is, and what are the building blocks of things we work with everyday gives you a better understanding of what it takes to build software.This would have definitely helped me earlier even before being a product manager when communicating with engineers. The ability to speak technically is really beneficial even if you don’t end up coding full time as everything around us is becoming more technical.

3. Don’t give up learning how to code after trying one language: I dabbled in coding several years back, and always thought it was not for me. I had done Learn Python the Hard way and didn’t enjoy it, so I had no desire to pursue programming further (although the book is really good and I recommend it). I had also taken a class in C back in high school as my first language and felt it wasn’t intuitive. But I was surprised when I began learning JavaScript and fell in love from the get-go. The overall aesthetic and the ability to try things on the console and see results was strangely addictive for me.

4. Learning to code increases affinity for learning other technical skills.: Technology is changing so fast that most new advances will become irrelevant in a few years. That means we will always have to adapt quickly along with new technology. Learning how to code made me comfortable with picking up new technical things. Before starting this journey I was always a little intimidated by it in some way. For instance, I learned web development these past six months but to pick up prototyping a mobile app is exciting for me. Now, my intimidation is gone and is replaced by a curiosity to learn new technology when I would like to.

5. Debugging is as important as logic: One of the most amazing outcomes of the last few months has been observing my improved approach to problem solving. When things aren’t functioning as expected, I’ve learned to work through the issue systematically. In my case, the logic for programming came pretty naturally. But what didn’t come naturally was debugging. When something didn’t work according to my logic, sitting through it to understand why was not easy for me. Initially, I had the tendency to give up quickly, ask a peer to quickly have a look, have a mini panic attack or just blame the programming environment. Over time, I learned calmly working through something independently that’s broken is as important as the logic piece (if not more).The ability to understand why an output is different than you expected, deconstruct the issue, and diagnose the problem is key to coding. Learning this made me a much better problem solver.

6. There is no one “right” way to learn to code: There is a ton of material online for free, and there is no one website that teaches you how to code well. If, for example, you aren’t getting one concept on Freecodecamp, you could look it up on Codeschool, Treehouse, Udemy, Udacity,Frontend masters or Youtube — the list is endless and keeps increasing. That’s why it’s hard to build a pure content company to teach skills. What’s a good explanation for one person may not be the best explanation for someone else. Also the amount of free content out there is staggering.

Learning is personal, so it’s important to find what you like and which resources work best for you.

There is no one right website subscription — try a bunch and most come with 30 day free trials. I went through a bootcamp because I felt I would benefit from the structure and it was an amazing experience — again not necessary for everyone. One thing I also experienced is that learning to code us a nonlinear process. It’s not like you only follow a curriculum from a single website — you are constantly reinforcing concepts from different places. There’s never been a better time to learn things yourself because the material is so easily accessible.

7. Like anything else, there is no shortcut to being good at programming: After programming for six months, I’m still a beginner. Even if you coded for 30 days straight, it’s unlikely that you’ll become a master in only a month.That amount of time would probably just give you a cursory introduction. Over the past several months, I’ve come to realize there is a lot more I don’t know than I’d thought when I started. Learning to code itself isn’t hard, but lot of people tend to oversimplify what it takes to being a really good programmer, when it actually takes a lot of work.

It’s easier than ever to build an “app” without really learning the fundamentals of what you are doing and why. Do the work to really understand concepts, invest in data structures and algorithms and it will make programming so much better. A couple of years ago, I had followed one such program and built a rails app in 30 days and learned nothing — It was really just telling what code to put where. Don’t go down that route.

8. Learning to code doesn’t mean you have to become a software engineer: I don’t think I will ever solely be a software engineer. I have other strengths which I love and want to apply. I still love being a product manager; I still love company operations; I love working with designers and talking to users; and now I enjoy coding as well. Learning coding is an asset in whatever I choose to do next.

9. There are abundant resources for learning the basics, but few for improving: There are a ton of resources for basic coding, but few that can take you to the next level.

As I was writing code, I had questions like, does everyone else use as many for loops? Am I writing good code? How can I improve? How would someone at Google approach this problem? How do you design system architecture? How do you get better at system design?

One of the benefits of going to bootcamp was the ability to learn from and relate to peers going through the same journey. My assumption is that the best way to improve is by learning from colleagues within your company. Outside the workplace, there just aren’t enough clear resources out there for knowing that. The problem I found is not how to get started learning to code, but understanding where you are at and how to get better.

Personally, I found it very helpful to actively seek feedback from people who are better than you. Another one helpful tip is to read code of open source projects to pick up good practices and try to contribute to them. Also resources like Thinkster are great too for getting past the beginner stage.

10. Community helps, but it can’t be the only resource: Finding a community, even if it’s just one person, is extremely helpful if you are coding. One of the best things about Hack Reactor was the community. Learning how to articulate thoughts and technical ideas to other people through pair programming was amazing. Seeing how others solve problems makes you a better programmer. It can be as small as seeing some really helpful keyboard shortcuts to learning how people approach the same thing differently. I could not find an online community that replicates the same experience. There are many reasons why, but that’s for another post. At the same time, you can’t just learn through pair programing. Being part of a community adds to your individual experience and your work.

11. Hiring is still fundamentally broken: It’s still all about winning the same game: resumes, interviews, whiteboarding, and breaking through the algorithm and data structure challenges. To get hired as a software engineer, you often have to play a different game than what it really takes to work as one. If I was trying to get a job as a software engineer, I can imagine how mundane the process would be. The hiring process is one dimensional in most cases, and doesn’t take into account many of the things it should be testing for. How is it to work with that person? For example, do they bring out the best in people around them which is actually independent of how good a person is at data structures)? b) Are they persistent at problem solving? Can they learn quickly? Can they communicate? These are a few of the many factors often overlooked by hiring managers. Even though self learning is on the rise, hiring is still looking at a traditional set of indicators. For most jobs, a CS degree is preferred or required because they just haven’t figured out a more accurate set of attributes to look for.

In each entry in this “conversation” series I talk to a designer/product manager/engineer on a topic.

At Aspirible, we are building an amazing netowork of folks not from Silicon Valley who are looking to join a startup. Please join today!