What I Learnt During 6 Months of Learning to Code

Anyone who’s wanted to learn coding knows that it’s anything but straight-forward. You’ll face hardships and unexpected roadblocks along the way. You’ve faced them, I’ve faced them.

For the last 6 months, I’ve been putting a substantial amount of time into learning how to program in different languages. I learned a lot about the coding process in general and how to grow as a programmer. Perhaps some of my takeaways might be useful to your journey.

I’ve come to realize that people are not born to like certain things. It’s a myth. It very much depends on your outlook towards that subject at the current time. I didn’t find anything appealing about a computer science class I took back in high school, so that class seemed like a drag. But now that I’ve explored it on my own terms it’s different.

I started discovering what I could do with programming on my own, in my own way, and at my own pace. It completely turned my perspective around. Learning to code in whichever way I felt like, without time constraints or an instructor telling you what to go over, changed my paradigm. I could now see the potential in programming. I finally enjoyed it.

Perhaps my teacher just wasn’t engaging. Or perhaps I wasn’t in the right mindset to dive into coding. Whatever the reason was, this little monologue was devised to help you understand the first tip:

Around 4 months ago, I was going through the freecodecamp curriculum. I loved the HTML and CSS part because I could see what my code did in real time. It was interactive and very visual, perfect for me. I blasted through that section in no time.

However, when it came to the Javascript section, there wasn’t as much hype. I finished the Javascript syntax section because I knew I needed to, and eventually I hit the regular expressions exercises. I dreaded that section. It reminded me of my high school class.

Instead of losing motivation, I put freecodecamp on stand-by and went to other sources. I learned to program an unbeatable Tic-Tac-Toe and Tetris, among other simple programs. In this way, I was mastering the Javascript syntax by doing. Most tutorials used ES6 syntax and some regular expressions already, so I even got to practice those.

I changed my perspective in a big way when I started learning to program on my own. The second time it was a more minor change: just shifting from an open-source curriculum to watching online tutorials. Sometimes, all you need to keep you going is to change things up a bit.

Talking about tutorials, though…

When you’re learning to program, at first you definitely want a guiding hand. Whether it be tutorials, online courses, or freecodecamp, nobody is born all-knowing. Despite that, you eventually want to go out into the real world, so to speak, and start figuring out your own projects. Failure to do this is called the tutorial pit.

I was in the same situation. In fact, I often feel like I’m still in it. I watched several programming tutorials, but when I tried starting a project on my own I was completely lost. I always ended recurring to those tutorials in order to help me get started. I felt like I didn’t have the capacity to create something from scratch like they did.

Perhaps you’re like me, stuck in the tutorial pit from a combination of fear and self-doubt. Or perhaps you simply feel like you don’t know enough yet. Whatever the reason might be, getting out of the programming pit is very rough.

The best way to start climbing out of this “pit” is to start small. It’s hard to appreciate the work that went behind a coding tutorial. It’s presented so neatly and it’s easy-to-follow, but I guarantee you that whoever made it spent way more time than you think debugging and coming up with ways to write their program.

This is why you should start small. Instead of trying to write an entire game like the more experienced programmers do, try to make some changes to their programs. Make them better, or even add new features using what you learned. Eventually, you can start working on your own projects.

There are other tutorials that tell you to just pick a project and start making it. This isn’t very helpful, but it’s the harsh advice you need. If you’re expecting them to take you by the hand and guide you through how to get started, what you’re really expecting is another tutorial.

I learned this mostly from learning to code games in Python with Pygame. I got very good at coding 2-D games by learning from people like Tim (the guy in the video above). However, there were almost no resources about programming 3-D games with Pygame, especially not what I wanted to program.

The ones that did exist were way beyond my scope, so I had no choice other than to take a step back and start learning the basics of 3-D modeling first. There was no single tutorial for everything I wanted to do, so I had to get digging. I had to get my hands dirty.

Programming is as much a creative endeavor as it is a theoretical one. You can learn from books and other resources, but you’ll eventually need to start getting your hands dirty. There will be no one to guide you through your own projects, but you can still ask for help whenever you get stuck.

Consider doing “deep work” and focus on your project for a few hours. Or, if you’re more of a Pomodoro type of person, work in cycles and take breaks in-between. Whichever way you decide to start doing your projects, you must start eventually. The faster you get going, the faster you will get stuck and start learning from those roadblocks.

Now that I mentioned deep work, though…

Doing deep work has been widely praised as one of the best methods to be effective at whatever you do. Focusing on something for hours-on-end with minimal distraction can allow you to enter a “flow state” in which you will breeze through your work. Also known as the “zone.”

Your first instinct is probably to think that this perfectly applies to coding. After all, undertaking big projects requires a lot of time and attention to detail. One must be thorough, resilient, and able to focus on the end-goal for long periods of time.

Yet I’ve found that this is not necessarily the case. Once you have a grasp of the fundamentals, programming ceases to be so much about learning a language or the tools you’re working with, and more about problem solving. Being stuck on a problem is no fun, and going over it over and over can be counterproductive.

In my experience, I’ve found that the best way to solve programming problems is to do the opposite of deep work. When I’m coding, I finish as many tasks as I can until I hit a roadblock. Then, I take a break and go watch YouTube, or I play a match of LoL. Anything that takes my mind off the problem.

Gaming in-between coding sessions? Probably not as bad of an idea!

This allows me to relax and let my subconscious work on the problem in the meanwhile. It’s similar to when you get a great idea on the shower. Walking away from whatever you’re trying to figure out actually helps your brain come up with better ideas.

This isn’t set in stone though. Some people can work on their projects for hours-on-end and be extremely productive. It just doesn’t do it for me, and I know many people I share that with. If deep work doesn’t work for you, give a less “focused” approach a try.

To round this all up, here’s probably the most important takeaway:

This advice works for about every single field where there is competition. When it comes to the programming world, there are people doing amazing and complicated things that seem light-years beyond what you can achieve. The ease with which they seemingly do everything makes it look as if they were made for this.

However, if you’ve heard any developer give you some real talk, you’ll know otherwise. Look up some “what it’s like to be a developer” videos on YouTube, and they will tell you that they struggle with getting things to work even after years of experience. I haven’t heard a single experienced programmer say that coding has become a piece of cake for them.

Of course, with experience things might become faster, and even easier. But the fundamental difficulty that comes with problem-solving does not change. The people you look up to might be more advanced and have more impressive code, but that doesn’t mean they didn’t work hard to get there.

As one of the rules in Jordan Peterson’s 12 Rules for Life goes: “Compare yourself to who you were yesterday, not to who someone else is today.” There is a lot of truth to that statement. What matters is not how far along others are, but how far along you are.

I hope these points were as helpful to you as they were to me. After learning them through failure and hard work, I firmly believe in them.

Thanks for reading!

If you enjoyed the article make sure to leave some 👏. It means the world to writers like myself.

If you want to read more, follow me on Medium and Twitter. I’ll keep you updated on all my new content!