The modern day software developer needs to learn a new technology every 3 months. To enable this, the developer needs a hands-on, breadth first, iterative approach to upskilling in the 2020s.
Back in the Day….
20 years ago, in the year 2000, the path to building a career as an App Developer was pretty standard.
There was a lot of learning in the first 6 months to a year. The individual had to learn a framework like J2EE or .NET, understand a lot of sub-components like JSF / Struts, Spring, Hibernate, each with its own verbose DSL and a cumbersome learning curve that took months to understand.
Once this learning phase was over, the developer would settle into a routine, and use the same frameworks and patterns over and over again. There was no need to upskill themselves every month.
There were times when the individual had to upgrade themselves, but these times were few, and often came on specific occasions: change of jobs, change of project, or a rare change in tech-stack.
The learning vs time graph would usually look like this:
Fast Forward to the 20s
Fast forward to 2020, and the world is different.
An app developer is expected to work with multiple micro-services, each written in a different language and using a different database.
They not only need to know how to build a web-app, but also how to deploy it and write tests, create a frontend with the latest version of the latest framework.
It is also good to have an overview of how to work with either Android, iOS, React Native, or one of the 100s of other Cross-Platform frameworks that help build native mobile apps.
This explosion of technologies has lead to TDD and Clean Code becoming even more important. The developer might work on one micro-service today, and might need to understand the code written by someone on a completely different micro-service tomorrow. This requires code that is readable, understandable, and well tested.
This has resulted in a situation where learning in 2020 is very different from what it was 20 years ago. Frameworks and technologies have become more developer friendly, and it is possible to get started in just a few hours / days. But now the developers have to learn something new every 3 months, as compared to every 3 years.
The learning vs time graph in 2020 now looks quite different for an individual working on a typical project:
Upskilling in the 20s : What is Needed?
When we look to upskill on any practice or technology now, these are the three things we want:
- Speed: Be able to ramp up on a technology within a few hours to a few days.
- Application: Ability to apply the technology in a variety of scenarios, and not just have theoretical knowledge.
- Breadth: A broad overview of multiple different features.
How do we achieve all of the above? Are their certain practices and processes we can follow that will help us upskill on any technology in a short period of time?
The Solution
Here’s the traditional approach to learning something:
- Introduction: Get a brief overview of the topic.
- Theory: Do a deep dive into the underlying theory.
- Problem: Once the theoretical learning is complete, pick up a real-life problem that helps you practice what you’ve learnt.
- Solution: Solve the problem, and figure out the pros and cons of the solution, and understand alternative solutions.
Timeline wise, it looks like this:
What we propose, and also use in our class-room workshops and online courses at interleap.co, is a tweak to the timeline:
Our approach is:
Divide the technology / process into much smaller parts. Let’s call them sections. For each tiny section, do the following:
- Introduction: Start with an introduction to the topic. It may or may not include theory.
- Problem: Pick up a reasonably simple real-life problem, that combines what you’re learning in this section, and what you’ve learnt before.
- Solution: Try to solve the problem that we picked up above. It may include reading some theory, copying code snippets, or just experimenting to reach a solution. There is no rigid structure to it. In bootcamps, it also might include giving out hints at appropriate moments.
- Theory: After understanding the solution, do a deep dive into the theory. This will help you evolve your own understanding, and many times you’ll yourself be able to theorize what you’ve learnt without referring to any material, just because you faced the problem yourself.
- Recap: A revision of the concept, and how it is applied on real life projects.
We call this iterative learning. It has two main differences from the standard approach to learning:
- The learning cycle is broken into many smaller learning cycles. This way, even if you complete one cycle, you know not only the theory, but also how to apply it to solve problems, and can start using it on a project. You don’t have to wait to finish the entire material before learning how to apply it in real life situations.
- The theory deep-dive comes after the problem and solution: Once you’ve solved a problem, and understood the solution, the theoretical deep-dive becomes more concrete, because you have something that you’ve already done to compare it with. Otherwise it is just an abstract conversation, without something concrete to relate it to.
This model of learning is inspired from the Socratic method, and the Iterative Cycle of Agile Development. It is also inspired from the various training programs I attended, conducted, and designed at ThoughtWorks.
We feel it is very well suited to learning any kind of engineering. A little bit of research tells us that it is well suited for learning other subjects as well.
At any stage, it helps an individual understand how to apply the concept / technology in real life situations. So an individual can start applying the learnings just after doing a couple of sections, and not wait to finish the entire material.
We use this process not only in trainings that we conduct, but also to learn anything new ourselves.
