In software development there is a lot of oral Torah. Studies have found that as developers we spend more than two thirds of our time just understanding and analyzing the system we are working on. That is, writing code is only the tip of the iceberg. Although in feature development there are many different approaches to everything, it seems that there is one thing that everyone agrees on: sharing and preserving knowledge in the team – this is a difficult problem, which does not really have a solution. In the eighth episode of the network series Dark {MOD}, we set out to check why this is such a difficult problem, and what can still be done to increase the sharing of knowledge in the team?
“It’s a problem that’s really not completely solved, knowledge management in the organization,” Ido Rachalevsky (ZipRecruiter) tells us, “We try to document as many things as possible, keep it as current as possible, and develop with the tools as they come out, but it’s also a cultural thing.”
Yotam (Development Manager at Milio), shares his own example to illustrate how much knowledge sharing can affect our development experience: “When I arrived at Milio, Sunday at work, they give me some kind of readme, and every time I start switching between links. Every time install Install it here, install it there – it took me about three days to set it up.” He recounts, and adds: “So the first thing I did was sit down and write a long readme, one, but from end to end you will start and finish and you will have a working environment. This is what I wanted, so that the person after me would come and be able to set up an environment quickly.”
To describe the difficulty in transferring and preserving knowledge, it is common to use the lightning metaphor, or the “lightning factor”, meaning how the team will continue to manage if a senior programmer no longer comes to work because, God forbid, he was struck by lightning. Keren (Taboola), shares: “I had to deal with someone who left and really took a lot of knowledge. We tried to drain him of all the knowledge, the brain, everything, just tell us what to do. And make sure we have all the permissions for his stuff.”
So how will you improve the flow of knowledge and increase your flash factor? Well, it all starts with fostering a culture of knowledge sharing. At Wix, for example, they work according to the “guilds” method – professional content communities within the company. all of which aim to share and promote knowledge, tools, and methods around a specific content world: “Knowledge sharing was one of the main reasons why the guilds were established,” says Aviva, leader of the backend guild in Wix: “Knowledge sharing is reflected in two practices, one of which is guild days – half One day a week, on Thursday, we meet, the whole guild, do activities related to training and knowledge sharing: lectures, case studies, people sharing their experience – and workshops”
ZipRecruiter also adopted the idea of guilds as a method of preserving and sharing knowledge, “What is interesting about the guild is that each representative who comes from a different group,” says Ido, “he comes and tells what problems he has in the area of the guild and in this way we can also work, also on information sharing And basically sharing knowledge between every area of the guild, between all the groups and also giving groups like my group the opportunity to actually improve the lives of several groups at once”
In other companies, they take an “extreme transparency” approach, where anyone who wants to can take part in solving the problem and everything is transparent and accessible to everyone, or even insist on writing as much as possible in open Slack channels.
Yotam (Miliou) emphasizes that sharing knowledge requires a lot of energy: “I think that preserving knowledge is an issue that requires a lot of responsibility on the part of all the developers in the company. I can say that for us it is divided into writing it in a readme and sharing it on dedicated Slack channels for sharing knowledge. A real knowledge channel sharing and of engineering, and we literally write all kinds of things that happened to us there,” he says.
Another interesting approach is automation. In a certain sense, process automation creates the knowledge within it and reduces the knowledge that needs to be shared and transferred between teams, as is usually done at Wix: “If we started documenting the entire production procedure and what we do and troubleshooting on each side, we would never finish”. Aviva says, and talks about how they found an alternative using automatic tools: “And what I created instead is a tool called Alert enricher. It’s a system that actually already does the next troubleshooting steps by itself. It checks the error and gives the developer access to the next steps he needs to take.”
And if all this didn’t help, you can always try and use the documentation – within the code itself, or in more creative ways:
“Documentation can be many things.” Says Yael (AppsFlyer), “Even writing a name of a function that is very, very good is good documentation”.. Keren (Taboola), puts the emphasis on the fact that knowledge can also be transferred and shared in creative ways, not specifically through long and tedious documentation documents: I did something cute once after I wrote a very big feature,” she says: “I made a video of how to use this feature, with music and everything, and I put it in our knowledge base, and every time when I was asked how to use this feature, then I just directed them to the funny video and that’s it.”
There are also those who do not connect to the documentation. This in itself is a matter of style, but what is equally important is that this documentation should be very easy to find, when you need it.
“We have an amount of documentation that I haven’t seen in any other company,” Hagar (ZipRecruiter) tells us, “and what’s the problem with that? Searching for the documentation you want and need. It really becomes one of our challenges.” Little (Torii), admits: “It can also be a bit annoying that you invested and wrote documentation about something and you don’t use it or look at it,” she says, “What makes documentation convenient, easy for developers to find their way around, is that there should be a good search, so that you can write and get to a page that You need to maintain some kind of systematicity.”
It seems that after all the guilds, shared Slack channels, documentation and videos – after all this, probably the most effective way to share knowledge is to simply work with people, together: “I think the most important thing is communication”, says Harel (AppsFlyer), “It Says regular and very open communication between the teams. I think there should simply be some kind of right combination between time of focus and time of more collaboration and knowledge sharing. This is something that I very much felt, say, during the closures [קורונה] who worked exclusively from home. At first you say, ‘Oh that’s cool, I’m focused, I work full hours, I don’t have all the coffee conversations and those things that find me out of the work zone. But over time you realize that actually this thing is very, very much missing from you. You miss hearing what other people are doing. You miss hearing ideas they are working on, getting their opinions informally. Just tell them what you’re working on in a coffee machine and see what they think.”
We can summarize and say that in software development Context is the king. Therefore – sharing and flow of knowledge are so critical to our development experience. There are many tools and methods that can be implemented, but no matter what you choose, a lot of investment and good intentions are required – from all the members of the team.
Watch the full episode of Dark {Mod} the network series for developers and developers:
Dark {MOD} is a docu-comic network series for developers. Every two weeks we will upload a new episode on the YouTube page And in an extended version here at Giktimes