I remember that when I started coding, I couldn't wait to land my first programming job.
In fact, I started applying to companies quite early in my learning process. This of course means I was also rejected a lot before landing my first actual programming job.
After few years of coding for a living, I can see that I could have sped up that process and land my first job much faster.
So if you are currently learning to code and you are impatient to start coding for a living, I invite you to read this article, where I will describe a few tricks I know, that will definitely speed up your learning process.
If after finishing the article you feel that I have helped, consider following me on Twitter, where I tweet and post articles about front-end development, functional programming and travel.
Let's get started!
1. Type everything by yourself
When you are learning from books, blogs or videos it's extremely easy to choose the easy route and simply passively read/watch the materials.
After finishing a chapter or a video you might believe that you have internalized the knowledge. But after a few days you will notice that you forgot most of it, if not everything. You might also realize that, although you "understood" a concept, you are still unable to code it on your own, without peeking at StackOverflow or any other kind of help.
This jump from knowing something to actually being able to execute it, is something that I see junior developers struggling with all the time.
Typing everything yourself while learning a topic is the number one solution to that issue.
When you are learning a concept, you should always do it with an IDE, a terminal or an interpreter open. Always. Setup your environment so that you can follow along whatever material you are going through.
You will discover that - although in theory you are learning the same content - you will be able to understand everything better and to retain the knowledge for much longer.
This is actually something I am doing with mathematics as well. When I am learning some equations from a textbook, I am always rewriting them on a sheet of paper. I will never use those notes later, but it deepens my understanding. Writing down something letter by letter keeps me accountable that I actually parsed and interpreted the equation correctly.
Exactly the same thing happens with programming, where... ekhm... coding the code actually increases the chances you really understand what you are typing.
2. Develop a "what happens if...?" mentality
While the first tip encouraged you to meticulously follow the beaten path, this one asks you to get off it as often as possible.
There is nothing more paralyzing for a junior programmer than running a program and getting something that they did not anticipate. The compilation step might fail. The code might crash during execution. Or simply the computed result might not be as expected.
When this happens, you can see a fog glazing over the eyes of a junior programmer. They become terrified and literally lose a capacity for rational thought. I have seen juniors not being able to solve unexpected problems, even when compiler was straight up telling them what is wrong with the code.
If you want to learn how to deal with those situations, you need to develop a "what happens if...?" mentality.
This means that when you are following a tutorial, you should every now and then stop and experiment with the code on your own.
Try to break some stuff. Try to change around values of some variables or constants. Try to come up with an alternative way of achieving the same result. Is that type declaration really necessary here? What happens if you omit those parentheses?
You should be asking yourself as much questions as possible. Even dumb ones, especially at the beginning. And then you should be testing them, by making changes in the code that authors of the material you are following did not even intend.
This will teach you how to deal with new and unexpected. You will see how your program (or compiler) reacts to the changes. You will see what kind of error messages are displayed when you, intentionally or not, break something.
This will make you feel much more comfortable with the language you are learning and with programming in general.
During next job interview, when something unexpected happens, there will be a good chance that you've already been in a such situation. And even if not, at the very least you will not feel so uncomfortable with the notion of your programs behaving weird.
3. Find a balance between "theory" learning and creating projects
In the programming community I hear all the time - "learn by doing". And it is definitely a great advice.
But here is the catch. I have seen many junior programmers who had portfolio projects much more impressive than me. Yet when you sat them in front of a computer and asked them to write a simplest program, they couldn't even begin.
Why? They might have created incredible projects, but it still is a lot of effort from them to create programs from the scratch. They probably followed along blog posts and tutorials while creating the projects. And there is nothing wrong with that! But then, when it comes to creating something from scratch and without any external help, it simply becomes too challenging for them, because they still lack fluency in programming and in their language of choice.
Learning by doing is incredible for people who have sufficient background knowledge already. If you took a random person from the street and told them "create a website", they would be completely clueless as to where to even begin. That's because they just lack the absolute basics.
So you definitely should create projects while you learn. After all, that's what will probably land in your first resume as a showcase of your skills. But treat your projects as something that only guides your learning and don't be afraid to go deeper and further.
For example, when you use some method in your project (because you found out about it on the internet), take a while and play with it a little bit. Don't just rush to the next task in developing your project. Try to actually understand what that method does. Find some good resources that talk about it and work through them carefully.
Can you call that method differently? And if so, what does it change in it's behavior? In what other situations this method might turn out to be useful?
Is there an alternative way to write that code you just copied from Stack Overflow? Maybe it can be cleaned or shortened? Would it be readable for others?
Don't just do. Think.
This advice might be also good if you find yourself often running out of steam when learning to code.
If you're becoming tired of your projects, switch back to "theory" learning, to brush up your fundamentals. Try to understand in depth the tools that you are using. Use textbooks, tutorials and technical documentation.
And if you cannot look anymore at all the theory, go back to your side project. Build and just have fun coding!
This will keep things interesting and fresh for longer, while deepening both your experience and your theoretical knowledge.
4. Find a tutor or... go to university
Now this advice is highly specific to where you live.
If you have access to cheap or free higher education in your country, I would strongly advise you to go to university and study computer science.
And before you type an angry comment with a list of hundreds of people who found a programming job without a degree, hear me out:
Nowhere did I write that you have to finish the degree!
The thing is, I personally really learned how to code only after I went to the university. Previously I attempted to learn to code multiple times, but I simply lacked willpower, focus and somebody to guide me.
Interestingly, I feel like my skills grew incredibly during the first few months of university and then they stalled. First courses were extremely illuminating, while the deeper I went, the less novel and surprising everything seemed.
That's why I ultimately quit university very fast.
But I still do believe that enrolling to uni and even quitting right after you find your first job is a very reasonable path.
Of course this works only in countries where higher education is free or very cheap. In many European countries it's extremely affordable to study, so if you live in one of those countries, definitely take advantage of that! Once you feel ready to go to work, you can simply quit. Or perhaps you will fall in love with CS and actually finish the degree!
On the other hand, in the countries where education is more expensive, I would still advise you to find a tutor or a mentor. Having somebody guide you and push you in the right direction is invaluable. You probably think that you will be able to learn everything by yourself. And you would be absolutely right! It is 100% possible!
But having a mentor will allow you to reach your goal much, much faster. After all, you don't know exactly what is important to know and what is not. You might have problems with assessing your present knowledge and skills objectively. You might not know where to move next in your studies. And you might simply have - like I did - problems with accountability and focus.
Having a mentor will remove all of those obstacles, and more. So don't be cheap. If you have at least some cash on you, invest in yourself and hire a tutor or go to university for at least a little while!
Conclusion
I hope that those little pointers were helpful to you. Learning to code is already a challenging task, so there is no reason to make things more difficult for yourself.
That's why I wanted to share this advice. I believe it would allow me to start programming professionally much faster and do better at job interviews and in my first work.
Did you find that article helpful? Do you have some other advice that you would like to share with others? Leave a comment!
And, again, if you enjoyed the article, follow me on Twitter for more.
Thanks for reading!
Top comments (0)