In the last few months, I have been in multiple conversations around finding the time to learn. (In case you have not noticed, creating and following a learning plan is part of your personal objectives). A common suggestion I hear is to set aside half a day or a day for learning.
Earlier this week, I heard a podcast by Swizec Teller on Becoming a Senior Engineer. At the beginning of the podcast, he touched on learning. What he said consolidated ideas in my head and motivated me to write this blog.
In my opinion, setting aside a fixed amount of time each week to learn something new is only part of the learning needed. Most likely, you will spend this time allocation watching videos, following a book or working through a framework’s quick start guide. Alongside, you might play with simple toy projects that demonstrate the technology you are learning. Most materials out there are aimed at beginners. This time allocation will only touch on the surface of the topic you want to learn. For example, I have followed tutorials on ReactJS and minikube. I have studied enough of AWS to pass the AWS Cloud Practitioner exam. However, I am nowhere close to competent on these topics.
I do not believe it is a bad thing we learn many things shallowly. A high performing engineering department should have engineers who are aware of recent software engineering practices and new technology trends. This breadth of knowledge is needed for continuous improvement. When confronted with a problem, we should be informed enough to think about better alternative approaches than simply doing what the team have always been doing. Setting aside a small amount of time each week will help us stay informed of new technologies.
In the podcast, Swizec Teller argues that learning five technologies deeply is better bang for your buck then knowing only the surface of fifty technologies. I do not believe this is to be taken at face value where you should only know a few things very well and none of anything else. In my opinion, you need shallow learning, but it needs to be complemented with deep learning in a smaller number of technologies.
For most of us to really learn a technology, we need to use it to solve actual complex problems. This means setting aside a much longer period of time than half a day per sprint to focus on a problem and solve it. One way to create this learning time is to put forward promising approaches, and create spike tickets to apply the new technology to solve value stream problems. These promising approaches could be something you have learned in your shallow learning time. For example, you heard a podcast about Ansible. You worked through the quick start guide on its website. You believe using Ansible will make your CI/CD pipeline more robust then your existing batch/shell scripts. For the deployment of a new microservices your team is working on, you propose trying out Ansible. You explain your reasoning and convince your team it is a worthwhile exercise. A timeboxed spike ticket is created and then admitted into a sprint.
The deep learning time that can be created this way extends beyond software frameworks. For example, to help capture the domain of a new application I worked on, I leaned heavily on Eric Evan’s Domain-Driven Design book. Another example can be using the microservices pattern to the development of a new feature, instead of adding it into an existing monolith.
Is learning non value stream work?
We are engineers and not code monkeys. We are hired to deliver business value, not just writing a lot of code. If as part of delivering business value, we need to learn how to solve a problem, then I believe learning is part of the job. In other words, if the learning is related to solving a problem needed by value stream work, I would argue the learning is part of value stream work.
If your product owner or product manager needs convincing, read this excellent article – The «20% Rule» of Thriving Technology Organizations | DrinkBird. Hopefully, it will help you put forward the case to justify that learning time.
However, I do not mean you should use a new technology simply because it is new and shiny. For example, you like the look of gradle and you want to use gradle instead of maven for your upcoming project. A project will not be a success unless the entire team believes in the vision. This means you need to present your reasoning for the choice and convince others about it.
What should be in your learning plan?
I believe your learning plan should include items that motivates you, which you are passionate about. It should not be something you are learning because someone tells you to.
If you are lost, a good place to start will be look at the objectives from your line manager and your team’s roadmap. These should relate to the wider department and company objectives. Are there any items in there which requires learning from you to achieve?
In this article, I shared my opinion on the why, when and what of learning. Learning new skills is crucial for continuous improvement, both for ourselves and as a team. As a team, you can aim to all set aside time regularly to keep abreast of latest best practices and new technologies trends. In addition, find time within your sprints to apply your learning on problems to make that learning useful. Lastly, I hope by focusing on possible application in your work as a reason to learn, it will keep you motivated, and justify the time spent.