How to learn to code

Learning to code is a different experience for everyone. I found some patterns in my attempts in learning that worked for me. I want to share those with you in hopes that you might benefit from your journey.

Submerse yourself

When I first approach learning a new framework or language I usually suffer from imposter syndrome. Learning new syntax, conventions, reading new documentation, new tutorials, and more is a lot to take in all at once. You start to question careers and suddenly crave something more simple like farming.

With enough dedication, I found it best to remain persistent by submersing myself in that area of focus even if the world seems turned upside down.

I identify as a designer who can code. I started with basic HTML & CSS which took years to master. When the need came to build something more dynamic I reached for what many do, WordPress. WordPress enabled me to dynamically render all types of content even though its initial use case was for blogging.

Through custom fields, a dash of custom PHP functions, and a lot of trial and error I was able to finally identify patterns that worked in my work to create successful websites for both myself and my clients. I even went as far as writing my own plugins where it made sense.

After a while, WordPress became a constraint. The more media you added to a WordPress site the slower it felt. It always seemed pretty hacky to make a custom theme with endless amounts of custom fields as well.

With new ideas in mind and some true determination, I sought to learn more which is where my journey with Ruby on Rails began. It came down to either Laravel or Ruby on Rails. Coming from WordPress I had had just about enough of PHP and Ruby looked ever so appealing so I leaped into it.

I did things backward and learn the framework first. You learn a bit of Ruby when using Rails but in general, you could know enough to be deadly. I had goals of building software businesses with fewer goals of understanding absolutely every detail of the code I was writing. I find with a purpose (business idea, app idea) you can accelerate your learning. This began about a year-long journey of absolutely submerging myself in all things Ruby and Rails.

I joined Reddit communities, read books, watched a ton of gorails.com and railscasts.com content, and started tinkering more with very rough app builds on my YouTube channel.

Building apps in public seemed to take the interest of others which lead me down my path of creating a course and helping create Jumpstart Rails with a couple of friends in the community.

I mention all of this to say, you have to start somewhere. Often at the bottom is the most stressful but as you continue to wade through the water of whatever it is you are trying to learn you start to finally become more confident in yourself. Over time this confidence compounds and it's what separates the experienced from the inexperienced.

Accept failure and continue

To learn you must fail. It's okay to not know how to do something. Googling, asking for help, or reading literature about your question in need is the most modern way to approach defeat.

My main advice here is to not give up. Take a break and step away from the problem if you have to. Grinding yourself into pure exhaustion isn't the ideal solution here.

Practice

No amount of tutorials, courses, reading, or conversing will make you a skilled professional without the principle of doing. To learn you must practice. Without practice, you will not retain. Use tutorials, courses, and books to guide you down the correct path but only as supplements.

What worked for me is building real projects. I had software ideas that allowed me to take new technologies and put them to direct use. I hit so many challenges along the way but with each experience (all failures at this point) I learned so much along the way.

Getting good at coding doesn't come from how much you know but rather how much you've experienced before. The more you've seen put to practice the more you can identify good patterns to use when trying to accomplish a goal.

A good example of this might be the D.R.Y. principle (don't repeat yourself). Experienced developers will know better ways to make code more reusable that will pay dividends in the future where a novice will write just enough code to make things function. Both solutions work but one might outperform the other over time and cause fewer headaches for other colleagues.

There's something to be said about over-engineering these patterns where you spend too much time trying to perfect your code only to throw it away later. I tend to be scrappy at first and come back through later to refactor. Wasting valuable time on an untested business idea is an indie hacker's worst pitfall.

Key takeaways

Learning to code does not happen overnight. I think I've put over a decade into learning all about front-end and have only since entered more of the back-end stack in the past three years or so.

If you are an indie hacker I recommend taking the stair step approach coined by Rob Walling. This means start with small products and let those blossom into larger products. I'm about midway on my journey of this process which started with this blog, some e-books, a course, and now I'm working on more courses that might lead me to a successful SaaS business one day. All of these things have been possible because the one day I made a deal with my designer self to finally learn how to code.

Learn to code by Submersing yourself, not giving up, and continuously practicing.