Finding Programming Inspiration: Learning to Code and Launch in Months

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

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 act as a form of coding inspiration and 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. 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 (one that I would now definitely recommend!), 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 from scratch 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:

• Eight months learning to code and launching my first project
• One month coding my second project
• 24 hours coding my third project
• 10 days coding my fourth project

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 incorrect, but I would emphasize that development is not unique to other skills. Input equals output. I see people googling "fastest way to learn coding" (volume = 140) or "how to learn coding fast" (volume = 880) or "easy way to learn coding" (volume = 70), when in reality it will always take a non-trivial amount of time and investment.

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 are essentially reinforcing what you are learning, while also lightening the psychological load of absorbing information prior to utilizing it. Programming by doing is the most effective way to truly crystallize what you're learning – it's the equivalent of exercising the language you're learning in its native environment.

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 of 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.).

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, 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 to code 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 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

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!

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

Related posts about Making:

• You Don't Need to Quit Your Job to Make
• The 7 Myths of Learning to Code
• How to Be Great? Just Be Good, Repeatably

Some of the links on this page are affiliate links, but I only promote products that I have used.