# Knowledge Sharing in a Development Team

As a software developer, you are required to deal with a vast amount of complexity daily. What was once a small application in which most code you were familiar with now starts to grow and become more and more complex. New colleagues keep on joining, new technologies are emerging - making your tech stack more obsolete - and more features are being created. In this scenario, we developers must be open to help each other constantly.

I believe there is no such thing as a 10x Software Developer. When a developer decides to share his knowledge and help someone else, he becomes much more valuable to the entire team. This helps reducing knowledge gaps between developers, which leads to a more productive team in the long run.

There is a variety of ways in which software development teams can share knowledge. Let's talk about some of them.

## Written Documentation

In my experience, writing documentation is not something most developers enjoy doing. What you write today will quickly become outdated tomorrow and as the common saying about documentation goes: "The only thing worse than no documentation is incorrect documentation.".

However, written documentation is a way of avoiding repetition and can still be useful within its limitations. Certain topics won't change that much. For example, explaining the architecture of the application or how to set up your environment are not changed overnight.

At quantilope, most of our software development onboarding process has been documented. To improve the documentation, we ask the new colleague to directly edit any misleading parts or even add new content, which helps to polish and keep the onboarding up to date.

## Code Reviews

Code reviews present a great way of sharing knowledge because it helps developers identify and fill the existing knowledge gaps in the team. The code submitter is likely to receive feedback and learn new things, but the code reviewer could just as much learn new things by reading through the code.

One of the most important aspects of a code review is the fact that the developers are forced to come together to discuss better approaches, making everyone better.

Also, when working in a team, it's highly unlikely that every developer is familiar with all parts of the app. Therefore, performing code reviews is also a nice way of getting to know areas that they haven't worked before but might be asked to help with in the future.

## Internal Workshops

Wouldn't it be great if software development teams had a reserved amount of time to share their expertise? At quantilope we do! Every two weeks, we are provided with a one hour slot where any developer can take the spotlight and share a topic of his interest with the team.

So far, some of the covered topics include TypeScript, functional programming with Ramda.js, Chrome DevTools, Usability Engineering and React hooks.

The presenter is not expected to be an expert on the subject and will be given the liberty to learn and prepare the presentation during work hours.

Right now, we are even opening up the workshops to the entire company, since we have found out that people from other departments were also interested in some of the topics. This entire initiative has been working out so well that all the slots are full 3 to 4 months before a workshop presentation.

## Conclusion

There are many other ways to share knowledge in a software development team, but all of them are based on communication, whether through written documentation, code review, workshop or directly asking a colleague for help. I wanna improve this conclusion, it’s a bit too short.