Backstory

I, like many other developers, started my adventure with programming without any good reason. Some of us started early while some of us started late in our lives. At the same time nearly all started out simply because “it seemed like a fun thing to do”. Just like that - “it was fun to do so I did it”.

I was lucky enough to own a really low-budget PC as a kid. I was just 14 years old, when all of my friends were playing quake 3 and I was stuck with DOS or 2D games. Thanks to that I quickly stumbled upon my first programming language – visualbasic. And man, I have probably spent more time helping with an open-source online MUD (multiplayer user dungeon) project than I have ever spent on my engineering diploma. Kids are kids, school is school and - we became flooded with MMO games. Due to that my interest in programming died.

It wasn’t until when I was 20 that I have became interested in programming again. In the next following two years I advanced from an intern into a mid position programmer.

How comes it only took me two years? Why do other people struggle with learning how to code? I will try to answer those questions by listing the most common mistakes people do while learning how to code.

1. Lack of Just-in-time learning

What is just-in-time learning? Exactly what it says it is.

You will ever only need to learn anything when you need it to fulfill your goal.

Do you know what will people tell you when you ask them “where should I start learning how to code”? “Go read the C symfony book”. And yeah, I tried that too as a junior. In terms of books – it is one of the best manuals for a given language, syntax and usages that I have ever read. But reading books when all you want to do is learn how to code is insanely unoptimized. Do not read a 500 pages long book about best practices with database handling in your code before you even start using a database in it. First learn by using it, then read anything that will make you better with it - as long as it brings you closer to your goal.

Same goes for tutorials. I am not saying experimenting is bad but no matter how interesting going through 10 randomly picked tutorials may seem to be, the ending result is often a random source code you have copypasted from a tutorial just to see how it works. This knowledge will be, at best, temporary. When a project will make you use one of the technologies/solutions that you have once seen in a tutorial, well, you will simply google it again and then perhaps learn it by experience. Reading unrelated materials will take your time and energy which you may have spent on constructive learning.

Then why do people defend learning from books, going from page one to page six hundred, in order to learn how to write a calculator in PHP? In most cases they are motivated by getting “advanced understanding of a given subject”. Why would you need that when you are just starting out? Well, the answer you will receive from them will be similar to “would you like to use something without understanding it?”. The truth is – for a lot of them it’s just fear of not being able to answer a question. Be it at the interview or during their actual work. But why should you care? You want to be a developer, not an encyclopedia. In your everyday life you use things you do not understand and it is not expected of you to understand them fully. Mobile phones, laptops, even cars sometimes. Same thing applies to programming. No one sane will ever expect you to know everything about android development just because you are an android developer.

2. Learning without a goal

Even if it is your day 1 of programming. Set a goal: “I want to build a calculator”. Make a goal of creating an application which does a, by doing b, so you get c.

Why do you need that? It will:

• Minimize amount of clueless wandering mentioned in #1
• It will, by nature, make you learn things you need to know in order to be able to build it
• At the end of this project you will be left with something you made yourself and something you can show to someone in case of need

But how do you exactly start? Let’s say you have picked a project, you want to create a countdown clock. Here are a few steps you could take in order to accomplish this task:

1. You need to show a window when the clock will be displayed. Search how to display an empty window in your chosen language.
2. You need to have a field which will say “how many minutes should I countdown for”. Search how to add a field to input data into.
3. You need to have a button start counting down. Search how to create a button.
4. You need to make something happen when you click the button. Search how to make something happen when you click on the button.
5. You need to make a timer with set amount of minutes. Search how to create a timer.

….

99 . Finish and release your application.

I hope you get what I mean. Setting a goal and slowly breaking it down will not only keep your development flow but will keep you focused on the goal as well.

3. Mr. Perfect

This is a case very commonly seen in the junior level developers. I have already touched this subject in the #1 argument. Spending tons and tons of time just to make something perfect. Indefinitely updating, refactoring, changing the code. Finding better solutions, going through tutorials and books.

Just stop it.

A finished project is always better than a good mockup, just like done is always better than perfect.

4. Spending too much time on a single problem

No. I do not mean it in the offensive way. But when your problem is big enough for you not to be able to solve it in 2-3 hours it means that spending 5 hours on it will, most likely, not help you solve it either.

Just relax. Programming is an exhausting mental job. Every single programmer in the world has those kind of blocks sometimes.

5. Personal attitude towards criticism

There will be a time, perhaps soon, when you will have to show your code to someone. Not just the finished project. The source code.

If you haven’t worked with another programmer before then, well, there is a good chance you will misinterpret criticism towards your code as a criticism towards yourself. No one ever means that. Even if they did their argument would be invalid as every programmer in the world writes barely acceptable code once in a while. You are just learning. What matters is what you do with the feedback. No matter how irrelevant it can be – never ignore it no matter what. If someone found enough time to point it out you should take at least as much to verify and/or fix it.

Afterword

Thank you for going through this article with me. It was written based on my own experiences and will not apply to each and every situation. However my intention was to show you guidelines to keep you on tract.

Do you agree with me? Maybe disagree? Perhaps there is something I have missed? Be sure to drop a comment below. Much appreciated.

Cheers, Tomasz