preloader

How to approach learning a new technology

Individual differences, and a viewpoint of a group of developers

Every Friday, before we end our workweek, we organize a knowledge-sharing discussion group in Lean Coffee format, which was suggested by one of our alumni colleagues, and it turned out to be a pretty neat thing to do.

Last Friday, we tried to answer a question regarding the best way to learn something utterly unfamiliar from scratch. The idea of this blog was to give a definitive answer, a step-by-step solution. Still, we decided to show you the whole discussion because it sums up individual differences when it comes to learning and both the positive and negative sides of each approach.

Dalibor (medior software engineer): I usually start with tutorials. It gives me a broad idea of the information structure and what I need to learn. Tutorials I choose are, in most cases, a result of the research I conduct beforehand about the experts in the field, available tutorials, and their reviews. Then I proceed with creating my own test project, and I usually read the documentation, which I do until I completely understand everything it says.

Aleksandar (senior software engineer): If you have some knowledge and experience with programming, I’d argue about the term “something completely new.” If you already know how to drive a car, you don’t really learn from scratch how to drive Audi or Mercedes.
A person/group/company that made the technology also wrote extensive documentation that explains their intent and its purpose. And regarding the tutorials we mentioned, I have a bit of a problem with starting with this approach. Tutorial is the way somebody understood the technology, which might be incorrect, so I’d start with the documentation.

Bojan (SEO expert): So we have a vote for tutorial and documentation as a starting point, what about starting with analyzing a project that’s already been written?

Aleksandar: I wouldn’t do so either. Someone might have written it without a real understanding of the technology you’re trying to learn, and it can give you the wrong ideas. Or, you might have a different kind of project, and it won’t translate well.

Marko (medior software engineer): My opinion is that the most important thing is to draw a parallel between a technology you’re learning, and the one you already know. Find the similarities, and the differences, it will help you grasp the technology faster, and understand it better.

Milan (senior software engineer): But, what happens when the thing you’re trying to learn requires knowledge of something you don’t know? So you have two things you don’t know, and they depend on each other.

Aleksandar: I think you can’t get away without understanding basic programming concepts either way, and you should always strive to know why it works the way it works, what are the different approaches, and what their shortcomings. I never start with the project until I know everything. And, my opinion is that as a senior developer, you should always strive to understand WHY something works in a certain way.

Bojan: In my experience, starting a project until you “know everything” isn’t always the way to go. I think that it’s important to be as productive as soon as possible. Basic theory and documentation is a good starting point, but you’ll get a more in-depth understanding when you start with practical tasks. No amount of theory and reading could replace experience.

Milan: I agree with Bojan’s point. Start being productive in the shortest amount of time possible, and gain deeper knowledge with time.

Dalibor: My opinion exactly. When I started working, I kept realizing there are a lot of things I didn’t know as well as I should, so I kept coming back to those topics and read about them.

Dorian (junior software developer): We shouldn’t miss one more important factor in learning. A mentor.

Aleksandar: Yes, having a good mentor can significantly shorten a time to learn something. Also, it can help because a mentor will show you if you have some gaps in the knowledge.
But it’s important for a mentor to have enough patience, to let you make mistakes, and learn through them. A mentor shouldn’t solve the problem for you, but he should teach you how to solve it on your own.

It’s not surprising that different people have different approaches to learning. For some, tutorials are a good starting point for other documentation. Some prefer learning until they understand how things work; others start playing around and building their own projects at the start. No one size fits all, and maybe we shouldn’t even search for it. Continuous learning and development are essential, and perhaps the only important thing is to find an approach that’s comfortable for you.