We know from multiple studies (e.g., 1, 2, 3) that learning at work improves both job satisfaction and organizational commitment. Both of these contribute to higher productivity and lower turnover.
Many companies use personal learning budgets and some type of "5%/10%/20% time" policy to encourage learning. These are useful but highly dependent on personal motivation and learning habits. It’s often hard for software engineers to prioritize learning over their busy day-to-day work. For example, only around 10% of Googlers are using their famous "20% time" policy.
The best way for a software engineer to learn is by having a role and a project where they can learn through their day-to-day tasks. That’s why companies should build a culture where learning is part of the engineers’ job instead of an "add-on." This helps with motivation and allows people with little free time — like the parents of small children — to continue learning.
Here are six proven ways to do that.
1. (Good) code reviews
Code reviews offer a great opportunity to learn because the feedback you get in a code review is highly contextual and often very specific. When you discuss why one solution is better than another, you can develop your professional intuition in a way that’s very hard to achieve otherwise.
Learning happens in code reviews only if they’re done well. If your team suffers from rubber-stamping "LGTM" code reviews and you want to improve them, you can check this complete guide to code reviews from my colleague Kimmo Brundfeldt.
2. Pair programming
During pair programming, you watch another person write code or hear them discuss a solution. This allows you to pick up practical tips on improving your work (e.g., how to use your editor). You also learn new ways of thinking and solving problems.
Pair programming costs less than most people think. In addition to improving technical skills, it also improves design quality, reduces defects, reduces staffing risk, improves team communication, and is often considered more enjoyable than working alone.
Tuple’s excellent Pair Programming Guide covers everything from getting started with pair programming to scientific research on the subject.
3. WIP limits
Developers often prefer to work alone on tasks and issues, even when the work could be split into smaller tasks and worked on side-by-side. Engineers feel more productive when they don’t have to deal with the "overhead" of coordinating with others. However, this often leads to more siloing of knowledge and less knowledge sharing within the team.
Many people know work-in-progress (WIP) limits only as a Lean/Kanban to improve the flow of work. But having a sensible WIP limit improves learning through collaboration. As an added bonus, it also leads to much better code reviews.
You can read our blog post on decreasing issue cycle time to figure out if you’re working on too many things simultaneously and would benefit from WIP limits.
4. Design documents
Design documents, RFCs, or just "documented plans" are a great way to enable learning on the job. When done well, the document explains why the chosen solution is the best from both product and technical perspectives. It considers the tradeoffs of different approaches and highlights the most important non-functional requirements that contribute to the solution, like accessibility, performance, and user experience.
Reading a highly contextual document like this allows developers to learn how other — often more experienced — people think about technical decisions. The developers writing the design documents also learn valuable skills: system design, communicating technical decisions, and how to motivate and inspire peers to adopt a solution.
To get started, you can check out our blog post on how to plan together as a team and Gergely Orosz’s article on design documents.
5. Study groups
Organizing study groups within your engineering organization is a great tool for peer-to-peer learning. This is especially true when you have more than a handful of engineers spread across multiple teams. Trying to apply books or courses to day-to-day work is not always easy — and may lead to people "trying out stuff" on your codebase just to learn. When people who work in the same context discuss the material, it’s easier to identify valuable learnings.
Often, the best part of study group meetings is going beyond the material by having people share their own experiences and different angles on the subject. This is especially true for books/materials that cover high-level principles (e.g., books like "Domain-Driven Design" and "Working with Legacy Code.")
I’m planning on writing a full guide on running great peer study groups (let me know if you’re interested in reading it.) For now, these are the steps we used at Vincit to run study groups at scale:
- Find a topic, a book, or a course that 4-10 engineers in your organization are interested in. Optionally, find 1-2 "expert members" from your company who can participate. Choose a person responsible for organizing the study group meetings.
- Set up a 30-60 minute meeting with a weekly recurring calendar invite for the study group. The larger the group, the more time you need. The meeting can be an extended company-paid lunch.
- For every meeting, choose a section of the material that everyone can go through beforehand. E.g., for books, we used less than 50 pages. Participants are expected to go through this material at their own pace in between meetings.
- Start the meetings by having everyone go through their notes or thoughts on the material. Discuss.
When the material for the study group is highly related to the participants’ current project, they can apply the learnings almost immediately. Other materials will usually pay dividends in the long run.
6. Peer-to-peer sharing
One of the best ways to get excited about learning is through the people around you. This is why building a culture of sharing learnings with peers is so important. For example, you can watch engineering talks together, share links to interesting content on company Slack, or have sessions where team members share their knowledge on some topic.
Not everyone will read every excellent blog post on Slack or attend every session, but whenever they do, they’re likely to learn something useful. Positive learning experiences create a virtuous cycle and motivate people to learn more.
Share your own experiences
Have you tried out any of these practices? What has worked? Discuss your experiences and share your tips with us on Twitter:
