6 Ways Software Engineers Can Learn At Work

We know from multiple studies (eg, 1, 2, 3) that learning on the job improves job satisfaction and organizational commitment. Both contribute to increased productivity and reduced turnover.

Many companies use personal learning budgets and some sort of “5/10/20 percent time” policy to encourage learning. These are useful but highly dependent on personal motivation and learning habits. It is often difficult for software engineers to prioritize learning over their busy daily work. For example, only about 10 percent of Google employees use their famous “20 percent of the time” policy.

The best way for a software engineer to learn is to have a role and project where they can learn through their daily tasks. That’s why companies must build a culture where learning is part of the engineers’ job rather than an ‘add-on’. This helps with motivation and allows people who have little free time – such as parents of young children – to continue learning.

Here are six proven ways to do just that.

1. (Good) Code Reviews

Code reviews provide a great opportunity to learn because the feedback you get in a code review is very 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 would be difficult to achieve otherwise.

2. Pair programming

During pair programming, you either watch someone else write code or hear them discuss a solution. This allows you to choose practical advice on improving your work (for example, how to use your editor). You also learn new ways of thinking and solving problems.

The cost of pair programming is less than most people think. In addition to improving technical skills, it also improves design quality, reduces defects, reduces recruitment risks, improves team communication, and is often considered more enjoyable than working alone.

Tuple’s excellent guide to pair programming covers everything from getting started with pair programming to researching the topic.

3. Work in Progress Limits

Developers often prefer working alone over tasks and problems, even when the work can be broken down into smaller tasks and work side by side. Engineers feel more productive when they don’t have to deal with the “burdens” of coordinating with others. However, this often results in more knowledge silos and less knowledge sharing within the team.

Many people know WIP only as Lean/Kanban to improve work flow. But having a reasonable limit on the work in progress improves learning through collaboration. As an added bonus, it also leads to much better code reviews.

4. Design documents

Design documents, RFCs, or just ‘documented plans’ are a great way to enable on-the-job learning. When done well, the document explains why the solution chosen is the best from both a product and a technical perspective. It takes into account the trade-offs of different approaches and highlights the most important non-functional requirements that contribute to the solution, such as accessibility, performance, and user experience.

Reading a context document like this allows developers to see how others—often more experienced—think about technical decisions. Developers who write design documents also learn valuable skills: system design, communicating technical decisions, and how to motivate and inspire peers to adopt a solution.

5. Study groups

Organizing study groups within your engineering institution 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 everyday work isn’t always easy – and it can lead to people “trying things” in your codebase just to learn. When people working in the same context discuss the material, it is easier to identify valuable lessons.

Often the best part of study group meetings is to go over the material by sharing with people their own experiences and different angles on the topic. This is especially true for books/materials that cover high-level principles (eg, books like Domain-Based Design and Working with Legacy Code).

I plan to write a complete guide on managing great peer study groups (tell me if you’re interested in reading it.) For now, these are the steps we’ve used at Vincit to manage large scale study groups:

  1. Find a topic, book, or course that engineers in your organization are interested in. Optionally, find a few “Expert Members” from your company who can participate. Choose a person responsible for organizing study group meetings.
  2. Set up a 30-60 minute meeting with weekly recurring calendar invitation for the study group. The bigger the group, the more time you need. The meeting can be an extended lunch paid by the company.
  3. For each meeting, choose a section of the material that everyone can see in advance. For example, for books, we used less than 50 pages. Participants are expected to review these materials at their own pace in between meetings.
  4. Begin the meetings by having everyone go through their notes or ideas about the material. discussion.

When the materials for the study group are closely related to the participants’ current project, they can apply what has been learned almost immediately. Other materials 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 learning with peers is so important. For example, you can watch engineering conversations together, share links to interesting content on Slack, or have sessions where team members share their knowledge on certain topics.

Not everyone will read every excellent blog post on Slack or attend every session, but once they do, they will likely learn something useful. Positive learning experiences create a virtuous cycle and motivate people to learn more.

Share your own experiences

Have you tried any of these practices? What worked? Discuss your experiences and share your tips with us in the comments.


Leave a Comment