"Upon reflection, the process of finally learning to code taught me one important thing: I was often my own biggest blocker."
My “Story”
Four years ago: Sitting in a lecture hall learning about thermodynamics and pipe sizing.
Three years ago: Sitting in an office creating Excel models for the Fortune 500.
Two years ago: Obtained by first Macbook and began diving into the world of SEO, product, and digital advertising.
One year ago: Decided it was finally time to learn to code.
Six months ago: Launched my first project.
You = Your Worst Enemy
Up until last year, I had always watched technology emerge in awe, but continuously made excuses as to why “I couldn’t do that” or justified why that world “was for other people.”
In February 2018, I started my own journey — slowly but surely — as a maker in the tech industry.
Upon reflection, the process of finally learning to code taught me one important thing: I was often my own biggest blocker.
For years, I told myself that others who had found success in tech were cut from a different cloth, and given different opportunities than I was given. While some of these may notions may hold truth in specific scenarios, I had built a habit of making these assumptions without properly vetting their accuracy.
Most of the stories I told myself were myths. Specifically, these
7 myths of learning to code prevented me from thinking coding was accessible. But it was really right there at my fingertips. Whether I was wrapped up in finding the perfect idea, or in identifying the perfect stack to learn, I was always doing those things instead of actually making process. In an age where education is cheaper and more accessible than ever, all I needed to do was start.
Thankfully, I finally wrapped my head around this last year. I didn’t do anything revolutionary: I picked up a Udemy course, picked a project to build, and started tracking whether I was making progress every single day.
8 months → 1 month → 24 hours
Before you can launch a product, you need to build a product. And before you can build a product, you’ll need to learn how to build a product.
Learning to code isn’t as difficult as many make it out to be, but I don’t want to give the false impression that it’s “easy” either. Taking on any skill or industry takes a significant amount of dedication and programming is no different. However, it is beneficial to know that similar to other skill acquisition, learning to code accelerates with continuous effort.
For example, this was a brief overview of my timeline:
On Product Hunt,
MYGA made it to #1,
Eunoia made it to #2, and
FeMake made it to #4. The point is not that applications should take 24 hours or even one week to create. Instead:
- Each time you launch, you will learn something which will better inform any other project you work subsequently on. Put simply, you will learn from your mistakes through either direct or indirect feedback. More on this later.
- Although learning to code may take a while to grasp, things will get much faster. For example, my fourth project was similar in complexity to my first, but took a lot less time. It wasn’t until my third project where I felt that I could truly ship quickly.
The idea here isn’t revolutionary, but simply that a lot of the heavy lifting will happen at the beginning in the form of learning. Learning is powerful and exactly what has enabled me to build every single one of my applications, but I realize that it can be overwhelming and difficult to stick to. There is always going to be chaos before order, and that’s why it’s essential to be aware of exactly what you’re diving into.
1, 2, 3, 4
Learning to code was a central goal for me in 2018. I can attribute my “success” in actually achieving my goal to a few things, which I’ll dive into further:
- Clearly identifying “why”
- Consistently tracking progress
- Creating while learning
- Starting small
Start with Why
Before you jump into development, you should identify why you’re making the leap. Hint: if it’s to “get rich,” you’ll never make your way through the long and continuous learning process.
There are many reasons why someone may want to learn to code. Some include:
- Becoming a paid developer
- Launching your own products
- Working more effectively with your coworkers
While there is no correct answer, I encourage you to identify a reason that will continuously motivate you and as you go through the process, ask yourself whether the actions you’re taking are leading towards that goal.
For me, it was being able to build and launch products, so I would ask myself questions like:
“Will learning this technology enable me to create my first project?”
“Am I learning valuable skills that I can build upon for years to come?”
“Am I adding to the ecosystem that I hope to be a part of moving forward?”
Make sure that your goals accompany you throughout the process and aren’t just a simple “end goal.” For example, if your singular goal is to “Hit #1 on Product Hunt,” you may find yourself disappointed if you don’t manage to hit that particular metric, regardless of how beneficial your journey may have been.
300 Hours
When I began to learn, I decided that the best way to hold myself accountable was to track my progress over time. Therefore, I tracked whether I was (or wasn’t) learning development every single day. Ultimately, I can look back on the past year and quantify my progress - specifically, I can say that I spent approximately 300 hours learning and launching applications.
Although this number will differ for each individual, it also provides a basic understanding of the level of commitment needed to get there. For example, if you’re planning on only dedicating an hour a week to this endeavour, it takes a really long time — six years! Just like anything in life, continuous yet consistent efforts will get you there quicker than you expect.
For example:
- 1 hour per day (7h/week) will get you there in <1 year!
- ~2 hours per day (15h/week) will get you there in <5 months!
- A full-time commitment (if possible) will get you there in <2 months!
I’m sure that many people think that these timelines sound unlikely or even objectively incorrect, but I would emphasize that development is not unique to other skills. Input equals output.
Create While Learning
Since the initial phase of learning can take time, I would encourage people to break it up into steps. At each major node (ex: HTML → CSS → beginner JS → intermediate JS → etc), make sure that you’re creating something, regardless of how simple it is. For example, your projects could be:
- A simple personal page
- A todo list
- A small directory
By adding small projects along the way, you’re essentially reinforcing what you are learning, while also lightening the psychological load of absorbing information prior to utilizing it.
I would also encourage people to come up with a larger project that they hope to accomplish as they start to acquire the requisite knowledge. The concept doesn’t have to be revolutionary (mine certainly was not), but it should be a project that you can continuously work towards as you’re learning. The act of creating will not only motivate you throughout, and ultimately help you learn more effectively.
Start Small: Launching is Learning
All of us are guilty for thinking our ideas are better than they actually are, so the only path to objective validation is launching.
For that reason, I would really encourage makers to launch sooner rather than later. You do not need to have been learning development for years to launch, and in many scenarios, you should launch before you feel ready. This is partially true because you will never truly feel ready, but also you should want to receive product feedback ASAP. This will inherently prohibit you from going down a path that isn’t validated (making features no one cares about, polishing a site no one will ever use, etc.).
Once you launch, get immediate feedback on what people care about. Based on both data and specific feedback (not vague comments like "this is a great app!"), you can determine whether a project is worth proceeding forward with. Try your best to look at a launch objectively and tease out flaws in your original thinking. Remember: launches are free feedback!
No One “Knows” What They’re Doing
If I haven’t convinced you to start learning to code yet, I will leave you with this bit of wisdom: no one truly “knows” what they’re doing. Those that are further ahead of you in a certain space have likely just been doing it from longer.
In a world ruled by dichotomies, people are viewed as “technical” and “non-technical,” but in reality, everyone is just somewhere along a curve of technical ability.
It’s helpful to recognize that many makers are still learning and often feel like imposters, even if they’ve been creating for years. The only thing that separates those who are successful from those who aren’t, is the few that are willing to continuously build, iterate, and learn from their mistakes. So if you’re unsure about starting, my encouragement is to just try it out.
Don’t consider yourself technical? Try development before writing it off.
Unsure of your ideas? Share them and get feedback.
Afraid to launch? Do it anyway.
Build Your Own Path
And with anything in life, remember to build your own path. Just because you see everyone on Twitter saying that X industry is “next,” that doesn’t mean that you need to go down that route.
Instead, focus on what you know now and what you can learn for the future. Don’t get overwhelmed by the concept of 300 hours or how far ahead someone else may be. Focus on continuous investment in the things that will bring you opportunity and happiness along the marathon that is life.
And most of all, remember that there is a start to any process. So just start.
Steph leads the Publications team at Toptal and creates things on the side as an indie maker. You can check out more of her work here.