My Journey: Learning to Code and Launch in Months

This was originally published on my blog, where I often write about remote work, learning to code, and women in tech. I wrote this article in particular based on questions I had received from people thinking of taking the programming plunge. Hope you enjoy!

My “Story”

4 years ago: Sitting in a lecture hall learning about thermodynamics and pipe sizing.

3 years ago: Sitting in an office creating Excel models for the Fortune 500.

2 years ago: Obtained by first Macbook and began diving into the world of SEO, product, and digital advertising.

1 year ago: Decided it was finally time to learn to code.

6 months ago: Launched my first project.

February 2018

After many years of working on the fringe of technology, February 2018 was when I finally decided that it was time to stop watching with my nose pressed up to the glass window. I wanted to be part of this world.

Up until February 2018, 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”. February of 2018 was the start of my journey to make this world less of a black box and instead start creating, slowly but surely.

Specifically, this is a story about my year finding the right inspiration to finally learn to code and eventually launch four projects over the course of 2018, leading to a nomination for Maker of the Year and a Maker’s Fest Golden Kitty.

Hopefully, if you’re in a similar place - one where you’re on the verge of taking the leap - this article will push you over the edge.

You = Your Worst Enemy

There have been and always will be blockers in my life. Upon reflection, the process of finally learning to code taught me one important thing: I was often my own biggest blocker.

For years, many of the excuses I had made were rarely based in reality, but instead justification not to start. I told myself narratives that others succeeding in ways that I had always wanted were cut from a different cloth, were given different opportunities than I, or were simply too far ahead. 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, when in reality it was 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 any process. In the age where education is cheaper and more accessible than ever, all I needed to do was start.

Thankfully, a year ago I finally wrapped my head around this. 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 is “easy”. 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:

• 8 months learning to code and launching my first project (which is objectively my least impressive)
• 1 month coding my second project
• 24 hours coding my third project
• 10 days coding my fourth project (30x quicker than my first project, yet similar in complexity)

Although Product Hunt isn’t necessarily the best indicator for success, 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 1 week to create. Instead, the reason I’m telling you this is to emphasize the following:

1. 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.
2. 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, yet was many times shorter. 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, yet 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 the hell 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 as to why someone may learn to code. Here are a few examples:

• 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.

Remember: If you define better goals, you will have better outcomes and ultimately, dissatisfaction is only based out of your expectations which are inherited from your goals.

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 - 6 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 incorrect, but I would emphasize that development is not unique to other skills. Input equals output. And regardless of the exact accuracy, we are very quick to set these KPIs in our daily lives, but strangely against implementing them in our daily lives. By simply measuring how much time you’re spending learning to do X, you have a much more objective view of your progress.

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, but also enable you to test your learning and ultimately 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 to get your product to the point of receiving valuable 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.).

As you’re learning development, focus on getting “shit out the door”, since launching is learning, Keep in mind that making a product is all about constantly learning and pivoting, and it’s extremely hard to do this objectively (ie: not just based on your own singular opinion) without launching.

Once you launch, you 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!

As you’re building, don’t get too hung up on whether your product is 100% perfect or utilizing the most scalable stack. Do you know what stack the number #1 product yesterday was made with? Yeah, me neither.

That is another reason why I encourage those who are unsure about learning development to opt for that instead of building with “no code” or hiring the work out. The ability for you as a creator to make small, yet meaningful tweaks quickly is underrated. Similarly, your ability to pivot to a new project without searching for the perfect “no-code” tool or dropping another few $k on developers, is going to allow both you and your wallet to stay lean and agile.

In other words, you'll be able to create and pivot more quickly, and in the future not need to rely so heavily on others to create your visions. Even past that, just having a technical background helps you work more effectively with developers and understand the tech industry at a deeper level.

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 than you in a certain space have likely just been doing it from longer and are not smarter or more capable than you.

In a world ruled by dichotomies, people are viewed as “technical” and “non-technical”, when 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

I hope that my story helped provide some inspiration in you potentially taking the leap in learning to code on your own. However, with anything in life, remember to build your own path. Just because you see everyone on Twitter saying that X industry is “next” or you see the media glamourizing venture capital, that doesn’t mean that you need to go down that route. Remember that we live in a world where the most clickable headlines make the most money and thus the way the world is represented by the media often isn’t the reality of how things work.

So instead of focusing on what you know now, focus on 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. :)

If you have questions at any point throughout the process, feel free to send me a message!

You can also subscribe to my blog.