I recently gave a talk about learning to code products in less than a year.

The talk was well-received and was even labelled the best talk of 2018 at the location it was given. 🙂 Since it seemed to spark some inspiration in those who attended, I decided to write up a more accessible summary of the key points.

Background

To preface the piece, I think it’s important to quickly go over my story. I’m Steph and I’m 25 years old. Across the 25 years, I’ve had a varied past ranging from:

  • A degree in chemical engineering
  • Commuting my life away in management consulting
  • More recently working in growth/marketing for a technology company - Toptal

I should clarify that these views are my own and don’t necessarily represent the views of Toptal. 🙂

Different decisions led me down different paths but ultimately something about tech stuck. Throughout the past 2.5 years at Toptal I learned more about the industry and had the opportunity to go to conferences like TechCrunch Disrupt, where I could see the extent of opportunity and innovation.

More recently, the missing piece was being able to contribute to technology myself. I was working with developers; I was seeing the products others were creating....and ultimately, I wanted to be a part of that world. So, starting in February, I went on a year of learning that was focused on learning programming from scratch, with a focus on learning to make web apps.

Long story short, it worked. I launched 4 times this year, one of which went to number 1 on Product Hunt, another which recently won an award for Inclusion and was nominated for 2 Golden Kitty awards, and others which had their own quirks - like this one which came 5th in the 24h startup challenge.

I was even nominated for Maker of the Year in Product Hunt's annual Golden Kitty awards less than one year after learning my first lines of code.
The four products that I built in 2 months after investing 8 months learning to code web apps.

Learning to code has been one of the most rewarding periods of my life and is totally accessible to anyone reading this article. Before starting, let’s take a quick step back and question why this even matters.

It’s hard to dispute that the tech industry is going to be the most influential industry on our future and in many ways already is. The decisions going into making the products that are going to be ubiquitous in our future need to be made by a representative population. As we understand development, we are removing that barrier so that we can be a part of that future.

Many people look for shortcuts. For example, some common search queries include:

  • easy way to learn coding
  • easiest way to learn programming
  • fastest way to learn coding

There is nothing wrong with agility or simplification, but learning programming (especially on your own) takes dedication and time. For that reason, you won’t find any shortcuts in this article since I don’t think there are any. This article focuses on what I believe to be the 7 myths of learning to code, as I believe those are truly to the biggest barriers in people participating - not the technology itself.

I’ll start with a story:

There is a terrible car accident in which the father is killed, and his son is injured and taken to the hospital. When the boy is brought into surgery, the surgeon looks at the boy and says “I can’t operate on this patient. This is my son.”

How is this possible?

Perception Bias

If you didn’t get the answer yet, the surgeon is the mother. Many people, including myself, don’t find that response immediately.

This is due to something called perception bias: people tending to “see things” based on their particular frame of reference. While seemingly straightforward, perception bias is essentially a filter over every decision that you make; who you hire, what you learn, how you negotiate, etc.

I believe that if you haven’t started learning to code yet, you’ve labelled yourself as someone who “isn’t a developer”. With that knowledge in tow, I’d like to introduce you to 3 developers who may not look like typical developers, but certainly are.

3 developers that I have come into contact with over the last year.

So, it begs the question: Why does that perception even exist?

To answer this question, it’s important learn about the history of development. Back in the 40s and 50s when development was first taking off, a lot of the key software engineers were actually women, like Grace Hopper.

Come 1966, enter the Cannon-Perry test. This was a test done on a select group of individuals which tried to identify who the best software engineers were and there were two key conclusions:

  1. They were good problem solvers
  2. They apparently didn’t like people
1966 Cannon Perry test influenced how technical recruiters found the "best developers"

This “conclusion” forever changed the way that technical recruiters found the “best developers” and this self-reinforced for decades to come. This psychological perception permeates into the myths we tell ourselves or others tell us in learning to code.

If one study can so drastically change the trajectory of development, we can actively turn it around by addressing the barriers and myths head on.

So here they are; the myths that once prevented me and hopefully will not prevent you from learning this valuable and rewarding skill.

Myth 1: There are two types of people in this world

There’s a common misconception that there are two types of people: those that know how to code and those that can’t. In some cases, the image is so pervasive that there seems to almost be a different species associated with the two, with a big, impermeable barrier between them.

The reality is simply a learning curve. Just like any other language or industry, someone who has spent 10 years learning to code is simply further along that learning curve.

For some reason, people who are first starting compare themselves with others years further on the curve, yet this doesn’t happen with other skill acquisition. You would never compare yourself to a native Spanish speaker a few weeks into learning the language, nor would you consider yourself less capable than them.

Myth 1: There are two types of people in this world

Myth 2: Stack matters

Many people get hung up on stack. They end up on blog posts that tells them the performance of one stack is better or a specific language is “dying”. This noise prevents them from starting, which is what truly matters.

In reality, stack does not matter. Below are three successful companies that most people are familiar with. All three use completely different technologies and some even utilize languages that some code snobs would deem “outdated”.

  • FB: PHP and React
  • Spotify: Python and Java
  • Medium: Node and Go

Please don’t end up on a blog post that compares the performance of React vs Angular vs Vue. While you’re learning, this does not matter. Find a stack that you like and stick with it.

Myth 2: Stack matters. It doesn't.

Myth 3: You need to learn 3820 languages/frameworks to be a real developer

Below is a representation of the ecosystem of development. The image doesn't even capture everything that exists, but even what is displayed overwhelms people and certainly overwhelms me. No developer will ever know all of this, yet this is what scares people away.

“The tech industry is moving so quickly.”
“There’s so many new things popping up. Which programming language do I learn?”
“There’s a new Javascript framework everyday. Where do I start?”
“I don’t know what any of this means.”
“I can never be a developer because I’m so far behind.”

The development ecosystem

The below image is my reality within that ecosystem and I have launched every single app or project with this stack. These are the same projects that have been successful, won awards, and are actually generating some income. Ignore the above image and remember, you only need to learn something similar to what you see below.

Important note: you don’t need to learn my stack because: stack doesn’t matter! :)

My stack and the stack that allowed me to build all of my applications.

Below is a simple structure to think about what you need to learn if you’re tackling your own projects. It’s important to note that this obviously differs if you’re a paid developer, but everyone needs to start somewhere.

If you’re creating a simple static site, all you need is HTML and CSS. As you start to add functionality, you’ll naturally venture into Javascript. Learn vanilla Javascript and jQuery at the beginning and ignore the frameworks! These can be great later on, but are distractions at the beginning.

As you need things like authentication or a database, you’ll need a backend. But again, don’t get overwhelmed with choice as you truly only need 1 database (for me, Mongo) and 1 backend language (for me, Node).

Myth 4: “I just don’t get programming and never will”

I want to differentiate something that I think is very important. Logic != (does not equal) syntax. Logic is what you’re trying to achieve, while syntax is the specific set of rules that get you there; the specific characters that the computer can parse.

For most people, logic clicks immediately, but they get hung up on the fact that they don’t understand syntax right away. That’s natural! Not understanding syntax does not mean that you’re not capable of thinking like a developer or comprehending that logic. Syntax takes time, and the best part of learning to code is that there is a constant online dictionary available to you, which is Google.

Myth 5: “I don’t have anything to build”

If you truly believe that you have nothing to build, you’re almost certainly looking too hard for the perfect idea. If we take a look at some of the biggest tech companies and distill them down to their simplest form: Evernote is a note-taking app, Reddit is a public forum, and Medium is a blogging platform.

I can almost promise you that you won’t wake up one day and find the perfect idea. Ideas and execution are functions of one another, but ultimately execution is worth much more than ideas. Accepting this is an important precursor to actual creation and launching, which is what truly matters.

Credit to Derek Sivers for this idea and executing on it so that the world knew about it. Multiply the two integers together to generate a proxy for value.

20 (amazing idea) x 10000 (average execution) = $200,000
1 (weak idea) x 1000000 (great execution) = $1,000,000

Execution >>> Ideas

Myth 6: “I started too late”

"Starting late" makes sense for fads. For example: if you didn’t get on the fidget spinner train, sorry, you missed the boat. However, tech is not a fad. It’s becoming more and more ubiquitous in our lives and not showing any signs of slowing down.

My best explanation of this concept is:

“Everyday, there’s a bus leaving to tech world and you can get on that bus. If you miss it today, there’s another one leaving tomorrow and this will continue to be true for years and years to come. So, do yourself a favour and hop on one of those busses.”

There’s also a misconception that so many people know how to code and it’s already competitive. Well, actually only ~0.5% of the world knows how to code. If we approach this with the Diffusion of Innovation curve, we’re still very much in the innovator phase. You can and should be a part of this, and you didn’t start too late.

The diffusion of innovation curve with respect to tech. We're still in the early stages!

Myth 7: “I don’t have enough time”

It doesn’t take as much time to learn to code as you think. It can take a matter of months or even weeks if you’re truly dedicated.

I would also invite you to try one of my applications Make Yourself Great Again, which helps you think critically about how you’re spending your time and how re-allocation of distraction time can result in meaningful growth and learning.

Make Yourself Great Again allows you to think critically about how you're spending your time. 

Since I tracked my effort for the greater part of the year, I was able to determine that I probably spent ~300 hours learning to code over the last 10 months. Although it’ll differ for each individual, this 300 number gives us a much better sense of how long this truly takes.

If you spend 1 hour per week learning to code, yes, it takes forever (6 years). As we scale that up to 1 hour per day, you’re already looking at less than a year. If you scale up your commitment further to more of a part-time or full-time focus, we’re looking at mere months before you’re capable of creating fully-fledged applications.

To recap, most of the barriers that once blocked me and may be blocking you from learning are psychological. The world of development in theory is approachable, if we can remove these mental and societal barriers. The best advice that I can give you is to start as it is truly the only way to put development in a place that you perceive as accessible.

Many people end up getting stuck in what language they should learn or how to most effectively learn by searching things like:

  • best way to learn coding (SV: 2400)
  • best websites to learn coding (SV: 1600)
  • best sites to learn coding (SV: 1000)
  • best code to learn (SV: 480)

Here's a secret: there's no "best" way to learn coding. Everyone learns slightly differently but the commonality between people that actually end up learning is consistency and persistence. All of the major tools (Code Academy, Free Code Camp, Udacity, Udemy, etc) teach you effectively so it's a matter of starting.

So I encourage you to start, today. You could be building apps in weeks.

If you’d like to learn more about how I specifically approached learning this year, you can read about My Year of Sponge and watch my talk. And if you're curious, this is the course I started with.

PS: If you liked this article, you might enjoy my podcast or my latest project.

Related posts about Tech: