Often times as developers we are tasked with something that we have little to no previous knowledge about. This is in large part due to the fact that software and technology move along at a clip that simply won’t allow for a developer to have knowledge about all things in the realm of software. So, in order to be a better developer we need to be able to pick up a new topic and learn it quickly. I am not making this stuff up as I go along, I am sharing my experience and will show you how I approach new subject matter in a way that helps me to pick it up quickly.
Finding Sources of Information
Do not focus on learning everything about a new topic or subject. Don’t dive right into a tutorial. This is simply the exploratory part of out about a topic. I prefer videos, as I am somewhat of an audio learner, and for general concepts of a topic, there is usually plenty out there. I also look for documentation. If it is a new API that I know I am going to be using, I look for all supporting documentation that I can find. I usually create a bookmark in my browser and will place references in there. Sometimes if it’s a broad enough topic I will start putting things into sub-categories. Also, I look at books on the subject which are a good place too, however, I am somewhat careful if I am attempting to learn something quickly. Depending on how quickly I need to learn the material, I set a half day aside in collecting information and listening and reading about a subject. This is usually enough to give me a general understanding of a subject or topic.
Remember we are not trying to become a subject matter expert. We are trying to get enough of an understanding to use a new tool. This can look different depending on the topic. For example, I am in the middle of learning about Docker and containers on Windows. I did the above and have found that there is a wide variety of information related to Docker, and I find that most of the information I find most useful comes straight from the Docker docs site. I have it bookmarked and ready to go for reference. I’ve read over how to install Docker on Windows, as well as what are system requirements for running Docker. I’ve looked at some general guidelines for getting started, what is a container, how to run an application in one, mounting volumes, using Kubernetes as a container node service, etc. I am not claiming to be an expert on the topic and there are going to be some gotcha’s along the way (this is a given). The 80/20 rule is the following, in that you can learn 20 percent of a subject to achieve an 80 percent working knowledge. Or usually enough to get stuff done. This might not apply to everything, but is a good heuristic on how to approach learning something new. The additional 20 percent of the knowledge gap will be covered with experience, or you may find that 20 percent you don’t even need to worry about.
At this point, you should turn to actually create something from your newly gained knowledge. Sometimes that can be as simple as a
hello world or more complex. For example my Docker on Windows, I wanted to spin up a simple ASP.NET site mounted as a volume in a Microsoft/nanoserver container image. I followed a couple of tutorials and achieved this. Now, I know that I have a working development environment and can focus on some of the other architectural designs and am able to have a conversation with coworkers about the subject and be on the same page. I am pretty fortunate in that my current work situation allows for this sort of learning as long as it is work related.
Continuing Knowledge Growth
Most developers are able to self-teach, I think that this is an extremely valuable skill to have and translates into just about all areas of your life if you allow. But for the sake of this topic, let’s say you are working on a project and in the swing of things. Now you run into a problem. It never ceases to amaze me the intuition that comes from having the background knowledge of a subject. There are some things that you just simply not going to find in a tutorial or on StackOverflow. Often times you have a system that your coworkers and yourself put together and when things go wrong you can usually figure it out if you are the one that put it together. Edge cases abound and you will run into them. Sometimes it’s best to take a bit of time, reflect on the problem and consult those on your team. Nine out of ten times a solution will present itself. This is not always the case, but more often than not it is.
Happy coding and always, I hope you found this helpful.