Imagine moving to another city in another country across the world: first, you have to register yourself for a passport, permits, and licenses. Near your new house, you do not know the neighborhoods, nor the names of surrounding streets. You do not know your neighbors or where to get your groceries and all that while having to learn the language and culture of this new country.
Although less extreme, starting a new developer role at a new company can be a very similar experience. You do not know your colleagues, the codebase, or the company culture and guidelines.
Of course, you try your best to remember all the new information about every facet of your new job but it is challenging. Especially, when starting your first job. To help you in your onboarding journey or another learning journey, here are my tips for learning at light speed.
Remember the basics
Although I want to focus this article specifically on learning at developer jobs, a lot of general research on learning effectively has been conducted as well. Without going over this in too much detail, remember these basic tips to help you learn:
- Avoid getting distracted while learning (phone, social media, etc.)
- Get enough sleep
- Exercise regularly
Aim for understanding: ask questions
Learning is more than being able to recall something: it is about understanding. There are different levels of understanding a concept. These levels are nicely captured in Bloom's taxonomy.
The key to learning fast is not remembering as much as you can but rather quickly ascending to higher levels of understanding
I believe the best way of achieving this is to ask questions whenever something is not perfectly clear to you. Sure, when someone explains something to you, you often feel you grasp it well enough. But ask yourself: do you really understand it? Do you understand the reasoning behind a certain implementation? If not, ask questions until you do.
Once you understand something, remembering it becomes much easier
Learn by doing, not by watching
Imagine signing up for a tennis course and then finding out it solely consists of lectures. Sure, you need to hear the rules of the game, but you can never learn to play a sport without actually playing it, right?
The same goes for being onboarded as a developer. It makes sense you are first told the system's architecture and best practices but after that you will want to get your hands dirty as soon as possible.
Of course, at this point, there are many many details and business rules you will not yet know. Starting to code at that early stage makes it easy to make mistakes and will raise many questions along the way.
That is why I recommend to pair program with an experienced member of your team, making sure you are the one typing. Writing the code will make you remember it better but also requires you to understand its context. Typically, figuring out the context of code slows new employees down but that is where your experienced colleague comes in. He can give you the context and can explain the reasoning behind it as well.
This way of working will reduce team productivity slightly in the short-term, but pay off immensely in the future, as you become productive very quickly. Furthermore, the senior colleague will be forced to revisit earlier made decisions and explain them to you. This might even bring technical debt to light opening doors for code improvements.
Imagine becoming the teacher
One thing I noticed over the years is that I learn faster when I imagine having to teach the topics I am learning.
Whenever someone explains a new concept to me, I imagine having to teach it to a full classroom right after. This forces me to focus and prohibits lazy listening, where I convince myself I understand something "well enough", even though I do not. If I will have to teach or present something, I want to be in control of it. And to be in control I have to really grasp the matter at hand, which motivates me to ask questions while listening.
This might sound like a mental trick to play on yourself, but more often than not, I actually find myself explaining concepts to others shortly after learning them myself. It can occur when the original code owner leaves (for a holiday) and you become the next in line, or when demoing a new feature/technology to the rest of your team, for example.
Learn something not to stay a student, but rather to become a teacher in it
Write things down
Maybe the most simple trick in the book, but it is still underrated: write down things you want to remember. Especially when you just joined a new company an enormous wave of information will come your way. This wave not only contains code concepts and domain knowledge but also business processes, development processes, and software you have never worked with before. Even the names of your colleagues require space in your head to remember.
Therefore, cut yourself some slack and write new knowledge down. It allows you to truly focus on a single topic at a time, without forgetting the other ones. We are all human and forgetful sometimes. There is no need to force yourself to remember everything the first time you hear it.
Make models
When it comes to technical knowledge and processes, remember that a picture can be worth a thousand words. Instead of writing many paragraphs explaining a business process, create a diagram of it. Whenever a complex process or use-case is explained to me, I open diagrams.net and start modeling along. Show the model to your colleague to check if your understanding is correct and use it as documentation afterward.
Find the right teacher
Learning, of course, is not only about the person listening but also about the one speaking. Finding the right teacher will help you to save time and get a solid understanding from the start.
Especially in large organizations, I find there are many semi-experts and just a few true experts on a certain topic. The semi-experts will give you sufficient information on your questions, but the true experts can really kick-start your knowledge on a new topic. They might have worked with certain technologies for decades, or they are the original writers of a legacy service you are trying to understand (check the git history). In my experience, having true experts as teachers can boost your understanding multiple levels.
Leave your comfort zone
Having learned something new feels great, but studying is not always as enjoyable. It can therefore be tempting to pick up stories/issues you are comfortable with; that you know how to solve.
To learn fast, however, you will have to be outside of your comfort zone. Do not be afraid to pick up a story for a (sub)system you have never worked in. Instead, ask an expert to do the story together.
Be sure to pick your battles with this strategy though. As the image above shows, there is also a zone passed the learning zone where matters are so complex they are too hard to learn. Therefore, try to recognize stories that are new to you, but compact in scope: starter stories. Once you have a foot in the door you can start picking up more complex stories in a certain (sub)system.
Conclusion
Learning can be challenging, especially when you join a new company. You are flooded with information trying to remember what you can. Use these tips to travel the learning curve faster:
- Aim to truly understand new topics, not just remember them
- Ask questions whenever a detail or reasoning is unclear
- Leave the back seat and start driving. You learn by doing, not by watching
- While listening to explanations, imagine having to teach them later on
- You are a programmer, not a juggler. Write things down and focus on learning one thing at a time.
- Visual models can be powerful tools for gaining understanding
- Finding the right teacher goes a long way
- The biggest learning opportunities can be found outside of your comfort zone
Good luck learning and if you have your own tips for learning: leave them in the comments.