Skip to main content

Knowledge Sharing, the Missing Part

· 30 min read
André Roussakoff

TL;DR Knowledge is the meat of IT companies. Know-how, architecture, software and DevOps technologies, data, etc. When experienced employees leave, they take their knowledge and experience with them. New employees are hard to find and need time before they learn the skills enough to fill that gap. This poses considerable risks for the continuity and efficiency of any high-tech company and its ability to stay relevant and competitive on the modern market of IT-services. So, knowledge sharing should be very important for IT companies, right? Right.

And what about us, developers? Is our primary motivation in life keeping afloat the company that employs us? You bet it's not! For most of us, especially young and ambitious, it is much much more personal. Apart from a good salary, it could be fun at work, exciting and challenging tasks, problem solving, professional growth by learning new technologies, being part of a great team, and of course keeping our families happy. If we fail to satisfy our personal needs as developers with the present company, how long will it take before we start looking for new opportunities? 😉

So, while knowledge sharing has become a crucial survival factor for each IT company, the question is: are we doing it right or is there anything important we are missing? My view is that while the formal knowledge sharing process within a company may be well organized, we often overlook something very important: the personal and social side of it and its impact on the efficiency of the development process.

This article applies to developers of any kind, frontend and backend, as all of them can profit from knowledge sharing. However, the Missing Part is probably more applicable to big enterprise level organizations than to small startup companies, which use those types of knowledge sharing techniques anyway.

IMPORTANT

In this blog post, when I talk about knowledge sharing I am primarily considering ways of doing it face to face. So, it is about meetings, meetups, training sessions, one on one sessions when people have live contact. It is not about individually reading articles and watching training videos to learn about some technical topic.

Why Knowledge Sharing is Important​

How do modern devs come about their knowledge? For trainees and junior devs the company can arrange courses related to their job where they can learn some fundamentals like React, TypeScript, C#, .NET framework, Java, and other such big subjects. The experienced senior devs are often able to find solutions even to very tricky issues just by googling. Because they know which search words to choose and they can quickly filter the search results using their vast experience.

The real issue arises in between those two categories, no beginners but also no experts:

  • the devs have insufficient knowledge of what is necessary or even possible
  • they lack full understanding of the issue at hand
  • there is no one to go to for immediate help

The answer to that issue is the knowledge sharing. This blog post is exactly about that.

Conventional Ways of Knowledge Sharing​

Before we talk about the Missing Part, let us summarize more conventional ways of knowledge sharing that many companies use. All of them have one thing in common. They share the same mental model: GURU to ANYONE. This model means that one person, a GURU, who "knows it all" shares their knowledge with ANYONE, i.e. normal people who are usually much less experienced and/or lack that knowledge being shared with them.

Course Required by the Company (GURU to ANYONE)​

This can be seen as an official technical course that every dev employed by the company should follow who does not have that knowledge yet but it is necessary for their daily work. The trainer is usually an external trainer hired by the company. It can be characterized by:

  • may be very expensive but the fees are paid by the company as a loan to the employee;
  • duration is from 1 day to 1 week;
  • usually instead of normal work, so participation should be confirmed by management;
  • certificate of participation at the end;
  • sometimes an exam and a professional certificate.

Internal Meeting (GURU to ANYONE)​

This kind of meeting looks more like a normal meeting (on premise or online) of colleagues involved in the same project(s) or doing similar work. It can be characterized by:

  • regular 1 or 2 hours long team meeting;
  • meetup type online meeting for everyone interested in the topic(s) shared;
  • can have a form of a presentation or a workshop;
  • sessions can be recorded and saved somewhere for later access, also by other team members.

Help request (GURU to ANYONE)​

This is usually a one on one session between a senior dev and a less experienced junior dev. It can be characterized by:

  • occurs strictly upon request of one of the team members;
  • knowledge sharing is strictly on the "need to know" basis and only for that particular team member who made the request;
  • the session can be recorded and saved somewhere for later access, also by other team members;
  • consequently: no request, no knowledge sharing.

Questions We Ask​

In this conventional model, the need for knowledge sharing or decision to participate in a knowledge sharing session may arise from one of the following questions we ask ourselves:

  • Will I learn anything useful I don't know yet? Is it worth my time?
  • Is it relevant for my work? Will I be able to use it in my project(s)?
  • If I participate in that session, will I still make the deadline with my current task?
  • I got stuck in my current task, should I keep trying to find the solution myself or should I make a help request?

All these questions have something in common. They are focussed exclusively on our own gain only: "what's in it for me?" And that is exactly the borderline where the Missing Part comes in.

The Missing Part​

Where the conventional model of knowledge sharing falls short is the personal growth of devs and the social implications of knowledge sharing. As we will see, these factors have huge impact on the productivity of devs, the quality of their code, their work satisfaction, creativity, which in fact give a company its competitive edge.

Questions We Ask​

The questions we ask in the Missing Part are quite different from those above. They are much less about WHAT I CAN GET and much more about WHAT I CAN SHARE and HOW CAN I CHALLENGE THE STATUS QUO.

  • I am proud of this piece of my work, can I share it?
  • this piece of code is fun, can I share it?
  • this is a very tricky new technique I have used, it is important that my team members know about it. Should I arrange for a 15 minutes knowledge sharing session?
  • I don't feel comfortable about this piece of code but it is not located in the component I am working on, so formally I should not touch it. Can we at least talk about it?
  • why is our project structured as it is? I have read about other alternatives. Should I challenge the current solution?

Of course, this list of questions is not complete by far but it gives a good idea of the sort of considerations not touched by the conventional guru driven knowledge sharing model.

What we are missing​

Different teams, different organizations, different ways of working. Here are some personal and social aspects of knowledge sharing. See for yourself, which of them are applicable in your specific team or company.

  • feeling of equality instead of inferiority, especially by junior devs or team members that previously had another specialty;
  • sense of growth and trust both personally by each team member and the team as a whole;
  • I have come across something new for myself or something strange, is it safe to ask a question and show my weakness?
  • what was my/your biggest challenge last week? how have I/you overcome it? if not, can I/you share it with the them/us?
  • as a (more experienced) dev, I know one of my team members is struggling with a difficult coding task. Should I check on how they are doing?

As you can see, these aspects have a lot to do with the safety feeling, caring about other team members and being taken care of if in trouble.

But wait, what does it have to do with the "continuity and efficiency of any high-tech company and its ability to stay relevant and competitive on the modern market of IT-services" we have mentioned above.

Impact of Missing the Missing Part​

SKIP IF YOU LIKE

In this section, I will describe the potential negative impact of missing the Missing Part on the company. It is safe to skip the current section if you are only interested in my advice. Go straight to How the Missing Part Can Help.

Coding Efficiency​

Inefficient coding process leads to more man-hours, higher costs and longer TTM (time to market) for the client. Many non-IT people like managers and product owners believe in a myth that practices like pair programming and knowledge sharing sessions are a waste of billable time. The former because the time spent in man-hours counts twice (two devs working 1 hour together means 2 man-hours), and the latter even more times (10 devs having a 1 hour knowledge sharing session means 10 man-hours with nothing tangible produced). Also, there seems to be the impression that pair programming means hours and days spent by two devs sitting together and staring at one screen.

Why does this myth exist? Primarily because dev work is seen as linear. Meaning that the managers' expectation is that spending twice as much time should produce twice the result (lines of code, tickets, etc.). As devs we know that this is not how we work! Software development requires time for thinking, reading, planning, googling, learning, discussing, and refactoring and does not consist only of routine repeatable work. 😃

Another myth is that having devs work each of them 100% on their own is more efficient. Although this can true to some extent for senior devs, it is hardly so for junior devs! The knowledge and experience of senior devs is vast enough to know in advance how to best tackle almost every task at hand. However, when a junior dev picks up a new task, they may face a number of uncertainties:

  1. which technique to use? what are the options?
  2. I have some vague idea how to go about it but is my method the right one?
  3. do I know enough about this technique I must use it or should I spend more time learning it first?
  4. if I fail to get the desired result quickly enough, how much time should I keep trying before I ask for help?
  5. everyone else seems to be doing fine with their tickets, if I let them know I need help I will be the only one!

Let us consider the corresponding potential negative impact of these uncertainties on the Coding Efficiency in terms of time spent or waisted:

  1. time spent on research of the possible options like trying to find similar piece of code in one of the other existing applications;
  2. should the chosen approach finally prove to have been wrong, time has been wasted on the wrong approach;
  3. if I don't know enough, I will first have to spend time to learn the new technique, and even then I still may get stuck when trying to implement it for the first time in my life;
  4. and 5. time spent on trying to solve the task longer than necessary in desperate hope that will save me my face, so I will not have to admit I failed and had to ask for help.

Another negative impact is due to the time lost on fixing merge conflicts. Real massive time consuming issues can arise when large changes are uncontrollably merged into the code base while there are other open pull requests (PRs).

Code quality​

Code quality is not only linting and formatting. Every programming language has its own tools to automatically take care of those. We are talking here about such notions as the code style, how clean and modular the code is, whether the S.O.L.I.D. principles are observed, and of course code testing. I strongly believe that it is practically impossible to always produce high quality code working 100% individually. The choices we make as devs while coding have to be reviewed and challenged by our peers. PR reviews are a good way to have some control on this but they may not be enough due to PR fatigue. Other devs don't always have enough time for thorough analysis, so they may unintentionally approve low quality code.

What is the impact of the low quality code for the company? Potentially it is a time bomb. Its negative effect can grow over time and manifest itself in worse performance, readability, maintainability and robustness. All of which leads to higher future maintenance costs as low quality code adds to the technical debt needing rework some time in the future.

Fun and Satisfaction @ Work​

When devs are bored, don't get enough opportunities for professional growth, don't feel that their work is valued by the peers and the client, and become SCRUM tickets conveyor belt operators, they are more inclined to leave the company having found a more exciting and stimulating job, which many IT startup companies have to offer. Don't forget that enterprise level companies often have a lot of legacy code requiring the knowledge and the usage of outdated techniques.

Lack of knowledge sharing and positive feedback has considerable negative effect on devs, especially the junior devs. It may lead to stress, the feeling of being overwhelmed and having too much on their plate. This can happen when the task itself is unclear or it is unclear how to solve it from the technical point of view. Even bigger stress can arise when the "wrong path" has been chosen. Imagine being busy for a couple of days only to find out that one did the wrong things and the code must be completely rewritten! Or, even worse, it has now to be rewritten by a senior dev to fit into the current sprint. What a waist of energy and a huge disappointment for the first dev!

How the Missing Part Can Help​

Let us now consider the positive impact of adding the Missing Part both on the company and on its employees. The effect is like that of spreading the wings, feeling that anything is possible and knowing for sure that it is.

Knowledge Sharing vs Information sharing​

Quite often, what we think of as knowledge sharing is actually just information sharing. These two notions are not one and the same (see, e.g., Information vs Knowledge: Key Differences). Information has more to do with presentation of facts and data and being informed about certain subject. Knowledge, on the other hand, while certainly is based on information, has more to do with learning and discovering process and being able to practically use it, either to make conclusions or to create, build something. In that respect, information is rather passive and knowledge is rather active.

The funny thing is that for one person, e.g. a senior dev when they tell about some difficult technique they have used, it is certainly their knowledge they are sharing. But if we look at it with the eyes of a less experienced junior dev, this knowledge can become just information. Imagine that this dev's level of prior knowledge, experience and understanding of the matter is insufficient to grasp the whole picture to say nothing of the small details. For this junior dev to use that technique, they would first need to study it or at least sit together with that senior dev and go through the whole process once again step by step.

If we now look again at the conventional ways of knowledge sharing described above as GURU to ANYONE type, we will see something interesting. Although those sessions may indeed be knowledge sharing for those participants who have similar level of prior knowledge, they are but information sharing for all the others. It would be utopia to expect those others to be able to use that information the next day as their knowledge. Maybe even to remember it!

A good example of this is a PR session. The whole team is looking at the code diffs between the old and the new state. For some team members, especially those who were at one time involved in that particular area, these diffs can be quite meaningful. For other team members it can be just loose bits of information giving them some very general idea about the change.

Mental Shift: GURU ⇒ ANYONE​

This one is my favorite. 😃 Remember the conventional GURU to ANYONE mental model described above? Not every dev feels themselves as being a guru and thus have the urge to share their knowledge. If one looked through the history of the knowledge sharing sessions and the names of their presenters, one would notice that it is a small number of names that repeat many times each. Same devs make presentations. Other devs don't venture.

Let us make a shift to a different mental model: ANYONE to ANYONE. This shift makes all the difference in the world! Anyone here means any dev, no matter their level of knowledge and experience. So, according to this new model anyone can share their knowledge. What knowledge? A good question. We know that senior devs can share their knowledge. But what about all the others?

This new way of knowledge sharing requires a new way of listening on behalf of the team or colleagues. It requires a more supportive attitude. To illustrate this, I have put the differences in the following table:

RoleGURU to ANYONEANYONE to ANYONE
Presenter- Is this subject interesting enough?
- Does the company require it?
- Will I score if I make this presentation?		- This new technique I learned is fun!
- This difficult issue I solved was so tricky!
- I see potential value for the team!
Listeners- What's in it for me?
- Do I need to know this?
- The boss requires me to be present 😢		- Let us support our team member!
- I know this topic, it's great to talk about it!
- Are there any useful tips for the future?

As you can see, the new model is more oriented to support every team member in learning new things, solving difficult issues and telling others about their achievements so that the whole team can celebrate each step in their personal growth as a dev and a professional. And this applies to every team member from a newcomer to a veteran. Knowledge sharing does not have to be related to the application code only. Ik can be anything as long as the Presenter believes that their insights can contribute to the improvement of the team spirit, its efficiency, and professionalism.

Another important feature of it is that these knowledge sharing sessions can be very short and are similar to brainstorming. They can be short because sometimes all it takes to show is just a couple of lines of code or a small tip. Brainstorming follows a very important agreement: nothing is wrong! Meaning that no idea, no matter how crazy or impossible it is, is rejected. Rejection is forbidden! Same here. No matter what kind of idea, technique, tip, or achievement is presented, the team is excited as they witness a step in the professional growth of one of their team members. So, it does not matter if other team members already knew the subject before. These short sessions are always very positive and supportive.

Coding Efficiency​

Let us consider several approaches that stimulate coding efficiency. We have already touched the myths around pair programming above (see Code Efficiency). Let us now go into it in more details.

Pairing or Pair programming​

Pairing or pair programming is not new. To remind you what it is all about, let me cite Martin Fowler, a great software guru, from his On Pair Programming article:

Pair programming essentially means that two people write code together on one machine. It is a very collaborative way of working and involves a lot of communication. While a pair of developers work on a task together, they do not only write code, they also plan and discuss their work. They clarify ideas on the way, discuss approaches and come to better solutions.

Opposite of what many people think about it, pairing does not necessarily mean that two developers are working on one machine all day long. Each of them can even work primarily on their own ticket but several times a day as necessary they get together for a short session, just a quarter of an hour in order to unblock, to plan, to discuss, or to challenge each other's progress.

Here is one of the possible scenarios:

  1. Mark picks up a ticket from the SCRUM board and asks Emmy to be his second.
  2. Emmy picks up another ticket from the SCRUM board and asks Steve (or Mark) to be her second (Steve does the same, etc.).
  3. Mark and Emmy get together for 15 minutes to agree on the approach for Mark.
  4. Emmy and Steve get together to agree on the approach for Emmy.
  5. They repeat these sessions from time to time until the ticket is done, making sure
    1. none of them is stuck for longer than 30 minutes
      1. if one of them does get stuck, they call their pair for help
      2. if that appears not enough, they both call a more experienced team member for help
    2. the implementation matches the chosen approach
    3. the code quality matched the requirements
    4. the ticket is fully implemented
  6. The ticket is ready for PR only when both devs are happy with it and are both prepared to defend its choices and its code in a PR session.
  7. During the PR session it is the second dev who defends the PR and answers all the questions. Only then everyone can be sure that both devs fully understand the proposed change in the code.

In this way, each of the devs works more or less individually but the pair is ready at hand as a standby. By the time the ticket is done, both know everything about the approach, the choices, the reasons, the changes in plan, the motivations, the difficulties and the final code. None of them has got stuck for longer than 30 minutes at any time. It makes it a no-brainer to call for help, fun to plan and work, and the chance of following the wrong path is very low. In other words, this way of working is very efficient and produces high quality results.

It also does not matter who of the two is a more experienced dev. The less experienced dev gets a chance to learn from their more experienced pair. The more experienced one has to make sure that their pair has grown in their knowledge and is ready for PR questions. In a way, the more experienced dev becomes a short term coach for the less experienced one.

Crowd Programming (Hackathon like)​

This is a variation of the pair programming technique, which I have personally experienced a couple of times. In three hours we have developed and deployed a fully functional prototype of a new CRUD API using C#.NET and MSSQL. It is especially great when a team starts on a new project completely from scratch.

Here is how it works. The whole team of 5-8 people goes to a separate location for several hours. That location has a wall TV mirroring the computer screen and a huge whiteboard. The team has two computers: one for the TV and another one for searching the Internet. There are three roles in the team:

  • The Coder is the dev who is writing code on the computer mirrored on the TV
  • The Assistant is the dev who is watching everything Coder is doing and is assisting him (typos, missing details, etc.)
  • The Thinkers are all the other members

The complete team starts by drawing the project diagram on the whiteboard until they have a good idea what they need to create. Then they choose the Coder and the Assistant and start the timer for 15 minutes. The Thinkers tell the Coder what to code watching the progress on the TV screen, the Assistant helps the Coder in minor details. If necessary, someone of the Thinkers searches for more clues on the Internet using the second computer.

When the timer stops, the Coder joins the Thinkers, the Assistant becomes the new Coder, and one of the Thinkers becomes the new Assistant. In this way, every team member takes turns in every role. The team may switch from coding to drawing and back again if and when necessary. Very intensive workflow, huge fun, and it quickly produces results on an MVP level.

What is maybe even more important, is that by the end of the session EACH of the team members knows EVERYTHING about the created product, its concept, design, model, code, database, and deployment, so no extra knowledge sharing is necessary after that. 😃 How exciting!

Merge conflicts​

There are a couple of rules in regards to merge conflicts that can really save much time and increase work efficiency. The most important one is:

The devs from both sides of the merge conflict should be involved in the resolution process together to ensure the correct choices.

This saves time because these two devs have full knowledge of their changes. So none of them needs time to investigate the conflicting code from the other side trying to discern the code intent. This also saves a lot of frustration when later it appears that certain lines of code were wrongly removed or left behind. And then it saves the effort to fix those - well hidden - wrong merge choices.

Next rule:

Don't let PR's stay open for several days

When that happens with one PR while other PRs are being merged into the main code base, more and more merge conflicts are accumulating between the open PR and the main code base. So, the consequences described in the previous section become more and more severe. I pity the dev behind the PR staying open for a long time.

Finally:

When doing massive refactoring, make sure that that PR contains only refactoring and very few to no other changes. Let everyone else merge their PRs first, freeze new merges, help the refactoring PR dev solve the merge conflicts, then merge it a.s.a.p. After that everyone starts afresh from the fully refactored code base.

If you don't do it this way, your team may be facing a nightmare of merge conflicts by those devs who had started their feature branch before the refactoring PR has been merged.

Code Quality​

A lot of what has been said in relation to the Coding Efficiency applies to the Code Quality as well. The most important factor here is the second opinion. As has already been said above, PR sessions are after the fact and it can be too late. When the ticket is done and there are many tickets and many PRs, the PR fatigue may kick in. Then it can become practically impossible for the other team members to dive deep enough in each of the PRs because of their sheer number and their own tickets. Especially if the project has to meet a very tough deadline. It can happen that a ticket is done and accepted although the code quality leaves something to desire. If that happens, that PR introduces a new piece of technical debt.

Whereas if each dev uses another dev as their pair, poor choices and poor quality code have much less chance to slip into the code base. And by the time the ticket goes to PR, there are two devs able to defend that ticket who know its every detail. At the same time, this serves as a great quality assurance step firmly built into the development process.

Fun and Satisfaction @ Work​

When we agree that any dev is welcome to share any insight, whatever concern they might have had whether they are guru enough in a certain area for knowledge sharing, disappears. Every session becomes a celebration of a step in the growth process of some team member no matter junior or senior, By the way, doing a presentation is also a step in personal development. Which is very encouraging for each dev no matter their experience.

Regular short knowledge sharing sessions introduce a lot of excitement, pleasure and satisfaction in daily work. Sharing and learning become a new norm. Every dev learns new small tricks all the time, which makes it possible to immediately reuse some of them in their own work.

Imagine the kind of positive impact it can have on the employee turnover. The happy devs who a feeling that they grow as professionals and that they are part of a great team will stay longer! If the company ignores their need for professional growth and happiness at work, they may leave sooner. Then it may become a constant chore of spending time and resources trying to attract new devs and training them only to see them leave again in disappointment shortly after.

From Theory to Practice​

Active Knowledge - Passive Knowledge = Action​

The knowledge can be passive or active. When we first learn something, our knowledge becomes passive. It is more like information sharing. We have learned about something but we have not yet mastered it. We have seen things being done but we are not yet able to do it ourselves. Now, in order to make our new knowledge active we need to take action. Meaning to build something new based on it or to use it in some project or application we are currently working on.

If we don't, the risk is to forget what we have just learned. Every college or university student knows how quickly the theory is forgotten after the exam is passed! 😃 In order to make our new knowledge active and persistent, we must use it in our work.

I strongly believe that this gives the senior developers a very important coaching role in relation to other, less experienced, team devs. This coaching process may go through the following three phases:

  1. SHOW - show the dev how something is being done (e.g., during the knowledge sharing session)
  2. WATCH - do it together but let the other dev do it themselves under your supervision
  3. REVIEW - let them do it completely by themselves and review the final result

NB. this technique is known in The Netherlands as doe voor, doe mee, doe zelf

In this way, the senior dev and the team can be 100% sure that the new technique has been really mastered by every team member.

Side Projects​

Another exciting way of acquiring and mastering new knowledge is through side projects. These are small projects that are not part of our regular work nor projects. When we create an app after app after app for our clients, we tend to use the same techniques all the time. Copy&Paste from the previous app becomes the modus of operation. The risk is to get in a rut and bored. And then the devs start leaving the company...

Side projects give here a breath of fresh air. New ideas, new techniques, new frameworks, new tricks come out every day. It is impossible to learn all of them. Some of them may be potentially useful for our company but we don't know for sure. It is alto too risky to try them out on client projects. But what is possible, is to try things out on a micro side project using just that technique or trick or framework. The project should be small enough for a dev to finish it within a couple of days working primarily in their private time, e.g., in the evening or over the weekend. The results can be shared with the team in a knowledge sharing session. For the dev it is a new step in becoming a better professional, and the team may even get a new insight that can be used in the real project.

So, the dev is happy because they have learned something new = have grown professionally, and the team is happy at least for the same reason and maybe because of the new insights. Which in the end is also great for the company and its clients.

In Conclusion​

In this blog post, I have demonstrated that the conventional formal knowledge sharing techniques are not enough any more if the company wants to stay relevant and competitive in the modern market. Modern developers, especially the good ones, want to have exciting work and stimulating working conditions. They need incentives to feel great about their work and it is up to the company if they get them. A good salary is not the only important incentive, maybe even not the most important. Having room for professional growth and being supported in their drive to grow, is extremely important for modern devs.

Knowledge sharing is capable to give the devs that great feeling if the Missing Part is taken care of and is not missing. They learn new things. they share them freely, other devs share back their discoveries. The new knowledge is being trained and used in side projects. The whole team is supporting and celebrating everyone's growth. If all that is in place who would even think of leaving such a wonderful company!!! 😃

References​