Let’s imagine a situation, where you have just joined a new software company that has been working on a product for the past couple of years. The codebase is large and complicated, but nonetheless you are expected to contribute to it almost from day one. You clone the repo and spend hours, days or even weeks perusing the code, trying to build ever more complicated models in your head to get gradually closer to understanding what the heck is going on. That’s probably not the most beneficial way of spending your time and also a sign, that mentoring and knowledge sharing is not at the top of the agenda at your new workplace.
Why should we care?
There are usually three parties, that are involved and/or interested in the process of knowledge sharing: the new employee that has just joined the company, that person’s experienced coworkers and the company they work for. They all might have a different perspective on why knowledge sharing is good.
As a company (or maybe rather it’s founder), I would be very much interested in making new employees productive in the shortest amount of time possible. After all, this is something that has a direct impact on the company’s performance and revenue. I would also want to ensure, that there is a sufficient redundancy of knowledge. When one employee leaves or is unable to work for an extended period of time, there should be someone else able to take on all the remaining responsibilities.
As a new employee, on the other hand, I would like to avoid the frustration of having to gather all the information on my own, which can be an unnecessarily long process. I want also to feel like I’m growing and learning new things that I will be able to use in my day-to-day work. In this respect, knowledge sharing and mentoring are also about keeping the employees happy and satisfied with the work they are engaged in.
The third piece of the puzzle, the experienced coworker, also has a stake in this game. If they are willing to pass their knowledge and expertise on to others, they will gain a loyal partner, who will help them make yet more impressive ideas become reality. Another side of the same coin is, that in general, developers do not like to be left alone with a project. They want to collaborate and bounce ideas off of each other. You can do that most efficiently with a person, who has similar knowledge and experience to yours.
Room for improvement
My experience with regard to knowledge sharing at IT companies has not been very positive. Lack of focus on this area seems to be the norm rather then the exception. When you become an employee, you are given tasks and expected to deliver on them, even though you are almost completely unfamiliar with the implementation details of the project at hand. This situation is more of an issue at companies, which have been developing a product for a long period of time. Their codebases have grown to hundreds of thousand or even millions lines of code, which can be very overwhelming and intimidating in the beginning.
Things are different at consultancy companies. The projects, that such companies deal with, are often much smaller and do not run for years. As a result, codebases are more manageable in terms of size (but not necessarily quality). When joining a consultancy, you are also more likely to be handed the task of starting a new project, which very fortunately eliminates the need to understand existing code.
Variation with regard to knowledge sharing and mentoring comes from organization size as well. Larger companies are probably more likely to have some kind of a program or framework in place. They need to deal with scale, people coming and going, and more voices being vocal about their needs.
How to make a change
Let’s now talk about a few different forms of knowledge sharing, which I think are efficient and I have good experiences with. These are not revolutionary ideas that are hard to come up with, but applying them can nonetheless make a big change in your and your team’s performance.
First of all, we have to keep in mind that our goal is to transfer deep, detailed knowledge and skills, which will allow other people to perform well in a new area of software development or other fields. Because of that, our effort can’t just be a on-off act. We need to work on knowledge sharing on a regular basis until we form a habit and consider it a part of our day-to-day work.
Another goal that we want to achieve, is transferring knowledge quickly, while making the process understandable and easy to follow. Therefore, it is of uttermost importance that we structure information appropriately. What I mean is, that it is a good idea to start with a general overview, move on to the basics and make a natural, linear progression towards more complex ideas. It may prove quite challenging to arrange all the concepts in a domain, starting from the most fundamental ones and moving on to those that build on top of their predecessors, but it is an essential part of creating an efficient learning process.
As software developers, we are very likely to be familiar with pair programming. It’s a form of programming, where two people use one computer to write code, while discussing what the best solution to the task at hand might be. Pair programming is, in my opinion, a very efficient tool for knowledge sharing. It combines theory and practice in a personal, informal setting. It encourages questions and includes on of the most fundamental forms of learning: observing another, more experienced person. The concept of pair programming can be extended to “mob programming”, where a group of more than two people works together to write software. While I’m not sure whether mob programming is appropriate for day-to-day work, it certainly passes the bar to serve as a good tool for knowledge sharing.
To make our knowledge sharing process even more efficient, we can take a hint from the schooling system, where homework or self-study is an essential concept. If you want to get up to speed with a new codebase or technology, it is very important that you explore on your own. This is partially due to the fact that you can’t demand another person to use 100% of their time to be your teacher, and partially because deep learning occurs when you can stay focused on a task and engage in deliberate practice. Home environment often lends itself best to this kind of activity.
Mentoring and knowledge sharing should be an integral part of our daily work, no matter what organization we work at. It benefits all the parties involved, no matter whether you are a new unexperienced employee, or a master in your domain. If you agree, take a moment to think about your own company. Does it focus to any extent on mentoring new employees? Or maybe it just throws you in at the deep end without any consideration? Perhaps it’s time to make a change.
PS. If you made it all the way to the end of this post, here is a great track I recently discovered: