The amount of languages, frameworks, 3rd party libraries and tools is staggering. And every place of work uses a unique permutation of those.
As developers, we have to stay on top of things, no two ways about it.
Once we’ve decided we want to learn a new technology, we have a lot of ways to approach that. Especially with the burst of information nowadays. There’s no clear answer as to how we learn something. It depends on the technology itself, how deep you need to learn it, how much time and money you have to spend on this and personal taste.
We got a lot of different options to learn something. Here are some of those:
Official Documentation: Great as a reference guide. Usually all the features are documented and act as use case reminders. Not the best place to learn a technology from scratch (mostly). If learning a small 3rd party library, the documentation alone might be enough though.
YouTube Videos: YouTube I think redefined the way we study things. There’s something about watching a video that just brings all the pieces together for me. Especially that first “Hello World” program that requires some sort of setup.
The problem with YouTube is that the videos are usually made for popularity rather than for a complete study experience. It shows the main use case in a short time span and doesn’t explain what happens under the hood. So it’s more like a sneak peek into the technology.
Blog posts & Tutorials: Blog posts can give priceless information that you can’t get anywhere else. Great when having a specific problem. To learn a new technology completely, there are tutorials out there. Some are great, some not so much. Like in YouTube, the quality here really varies.
I prefer to avoid those tutorials when learning a new major technology since I can’t rely on the quality. For comparison, a published book is a much better use of my time. For one thing, the author is probably a known authority in the field. There was much more effort involved on the author’s part. Everything written was double checked and repeatedly edited.
Meetups: Meetups are great for many things, but not for learning a new technology. They are excellent to get exposed to new technologies. But to learn and use that technology, you’ll need to get your hands dirty:)
Books: Books are a great way to study. There’s a lot of effort going into writing a book. You know the best research was done, and the information is 100% correct. Books are usually comprehensive, so you’ll learn everything there is to learn.
There are usually several must-read books in any field, and they are so highly rated for a good reason.
Video courses in PluralSight, Lynda and udemy: I love Pluralsight. I think it’s one of the best ways to learn. For me, I understand much better when learning from a video than from a book. I’m still a proponent of books, but in the recent years I’m studying mostly from Pluralsight. The quality of those classes is excellent.
These courses give you both high quality planned content and comprehensive information. The only downside is that they are paid and lengthy. Sometimes, it’s better just to skim through a book or read a tutorial.
Workshops with instructor: Organized courses are different from all the rest in a way. For one thing, they give a structure. Like school. They’re usually organized by the company, so it’s both free and you’re getting paid to learn, so that’s great!
The instructors are usually excellent, and will guide you gently through the difficulties of learning a new technology.
Time is given to practice, which really nails in the knowledge.
In some ways, workshops are irreplaceable. If you’re like me, there’s no way you’ll invest as much time an effort into learning on your own as you would in an organized class.
Whatever way of learning we choose, we have to get our hands dirty and code. It’s the difference between sort of getting what the technology is about and really understanding. I’ll go as far as saying this is the one most important thing we have to do when learning.
My way of learning
I developed my own way of learning. I call it – The snail cycle of study.
The cycle starts when I need to get something done using a new technology. It can be a small or big something, doesn’t matter. I start with spending as little time as possible studying the technology to get started. This is usually up to 30 minutes going over the “Get Started” part in the official documentation, or reading some tutorial.
Then, I try to get things to work.
If I can’t get everything to work with my current knowledge, I move on to a bigger tool that takes as little time as possible, but exponentially more time than before. For example, some YouTube videos.
Then, I try to get things to work again.
If I still can’t get everything to work well with my current knowledge, then it means I need a much deeper understanding of the technology. Only then I move to the big time wasting tools like a Pluralsight course or a book.
My method is more instinctive than intentional. I simply hate wasting time learning something that won’t help me in my immediate task. You might say I’m missing out, not learning anything in depth. But that’s not true. I do learn a lot of technologies in depth. But only those I work with every day and need to know in depth. On the other hand, this method allows me to get things done at near optimal speed.
I guess this is a terrible approach for a researcher. But a programmer simply needs to get the program to work.
There are a lot learning options in our disposal, both paid and free. I’m more work oriented, so I chose a way of learning where my learning time is as little as possible. I guess it’s individual and other developers might want to really understand something thoroughly before using it.
One thing I noticed is that whatever I learn will be forgotten without repeated practice. However, I always remember the general idea. So I’ll remember what’s possible and what isn’t, generally how it should be done, and what I should be googling for when I need to remember.
So which is your favorite way to learn?
Share in the comments!
Want to become an expert problem fixer? Check out a chapter from my book Practical Debugging for .NET Developers