At the end of last year, I took on a huge responsibility - mentoring our new interns. One of the first sessions I had with them was about learning. The goal was to find out how they got started, how did they learn and which resources they used. After the session, I had understood that every one of them(3 total) had a different experience, a different approach to acquiring knowledge.

The aforementioned reminded me of how important it is to find a learning style that suits you but also that it's necessary to validate the resources you use.

This mini-series of articles gives advice for beginners about different ways of learning technical topics and how to validate the quality of your resources.

We begin with some general rules for beginners.

The big 3

These are the more general rules I wish I had known when younger me started programming. They may seem obvious for some, but having seen others make the same mistakes, I'd like to bring them out.

Have fun, but focus on foundations

You must make a conscious effort to learn the fundamentals of the tools you use.

Building new projects and playing around with frameworks is cool and improves your skills. Nevertheless, as a beginner, at some point, you must make a conscious effort to learn the fundamentals of the tools you use. For example, you can take React and play around with it, but in order to really understand what's going on, you must have a good understanding of Javascript - the language React is built on (Eloquent JavaScript comes to help). For example, did you know that classes in Javascript are just a syntax-sugar for the prototypal inheritance?

Knowing everything is impossible

To deeply learn something, actual experience is needed.

Another important thing to understand is that...you can't know everything.
A couple of years ago, my desire was to become a full-stack developer who'd have deep knowledge about databases, servers, FE and BE development. Today, I can say I'm a solid FE developer. That's because I've spent most of my working hours on FE. There are also numerous books, articles, Udemy courses and client projects where I've crafted my other skills, but in the end, to deeply learn something, actual experience is needed. And you can't experience everything.

Find your focus, define your goal

This brings me to the most important advice I have in this article - find your focus, define your goal.
As a beginner, it makes sense to build simple full-stack projects to see how puzzle pieces fit together. At some point though, it'd be wise to specialise. Whether it's FE or BE, Python or Go - stick with one language and one area for some time. If you specialise, you'll get to solve complex problems that force you to dive deeper. Through those experiences, you'll learn the main concepts, features and pitfalls about your tools. You'll also probably get more acquainted with the debugging because not every problem has an answer in Google. All that knowledge can be carried over to other languages, other areas as well. And who knows, maybe people will start asking for your help.

Bonus

Whenever you feel stuck, use rubber duck debugging. It simply means saying out loud what your problem is. Trust me, it works wonders!

And for now, that's it. Hopefully you got something useful out from this writing. In the next article, I'm going to explore different ways of acquiring knowledge and introduce my framework of learning.