Why Developers Should Care About Knowledge Sharing
Tags: knowledgesharing, teamwork, culture
Published: 2021-10-18 09:18:44

_Sharing knowledge usually comes as the last step of a process, or even worse, as something optional, that can be passed on if need be. This makes it easy to skip on this step if you feel you’re tired, or your team is busy. Developers are almost always creating new technologies and figuring out new solutions. Odds are, whatever knowledge you acquire won’t be available anywhere else. The time has come to remind everyone of the fundamental benefits of making whatever knowledge you’ve acquired available to your colleagues._

Why it helps you
----------------

Knowledge sharing is [the second biggest problem software companies face](https://codingsans.com/state-of-software-development-2020). It affects everyone, so it also affects anyone. With the advent of remote work, this issue may become even more important. First of all, let’s appeal to our own self-interest. Sharing knowledge doesn’t only help our team, it actually helps those who are imparting the knowledge in more ways than one.

Let’s see:

*   You are **advancing your own knowledge**. By explaining what you’ve learnt to someone else, you are consolidating what you’ve learnt. You will retain it better, systematise it better, and, frankly, you’ll probably advance it by seeing it through others’ eyes. You will have to consider what you’re sharing and think twice about it. That reflection will bring with it valuable learning.
*   You will be **receiving feedback**. No developer is an island. We learn from others. By sharing what you’ve learnt, you will be receiving other people’s thoughts on the subject, which will surely advance your own understanding. Maybe they will even correct some aspect of it that you misunderstood.
*   You will **help future you**. If you learn something and just file it away in the caverns of a closed pull request, odds are you may not remember it fully whenever you bump into the same problem again. If you write it down, though, and teach it to others, it will be right there for you when you need it. It’s the easiest way to **only solve problems once**.
*   You will be **advancing your career**. Sharing knowledge and contributing to the team’s success does not go unnoticed. If when people are in trouble and seek solutions your name pops up all the time, everyone will take notice. This is how promotions happen.

Why it helps your team
----------------------

But sharing isn’t just about oneself, now is it? There must be advantages for the whole team. Let’s see what they are.

*   It helps **build team spirit**. This may sound like a meaningless phrase, but it isn’t. What goes around comes around, and a team that is accustomed to helping each other will resort to helping each other naturally. Giving everyone a hand shouldn’t be contingent on someone being in trouble.
*   You will be **saving everyone A LOT of time**. How long did it take you to solve the problem? An hour? Two? A whole day? Whenever someone on your team runs into the exact same issue, they will (depending on skill level or just sheer instinct) take roughly the same amount of time. If there’s an explanation available, though, that everyone has knowledge of… Not so much.
*   You will be **building a knowledge base**. It may seem like just a small addition, but small additions build up. If your team develops a culture of sharing knowledge, they will inevitably create a repository that will become a cornerstone of success.

How to do it
------------

So, are there any best practices, aside from simply gathering the team and telling them, or writing stuff down somewhere public, such as an internal Wiki?

We do have some ideas:

*   If you’re using **Reviewpad**, which you should, the _Comments from the Past_ feature makes it so whenever someone touches code with comments, they’ll be able to see what was shared when that code was made. Forget about re-working the same problems, or going down avenues that somebody else already found out that don’t work.
*   Whenever a team member explains something to you, **encourage them to document it**. If it was useful to you, it will likely be useful to others.
*   Much in the same way, whenever someone asks you for help, **document it**.
*   Whenever you are the one who needs an explanation, avoid asking in private. **Ask on a public forum**, so everyone can read the discussion and take advantage of it.
*   Make it **easily accessible**. Your knowledge base needs to be freely and easily accessible to everyone, at all times. Developers don’t particularly like over complicated wikis, so it’s up to you to create this space.

One of the reasons why we are building Reviewpad is making knowledge sharing easier and more convenient to everyone involved.

Reviewpad is about communication as much as it is about reviews.

[Are you ready to give it a go?](https://www.reviewpad.com/get-started)