Recent studies mention that best practices and knowledge sharing are among the top factors that boost engineering performance. The StackOverflow Developer Survey 2022 report also states that a developer wastes between 6 and 13 hours a week looking for answers to their questions and spends between 5 and 11 hours per week answering questions from others. We can mention as well the SmartBear 2019 report says that developers often feel tired and frustrated during code reviews due to repetitions and explaining the same concepts to different developers.
That’s why I’m convinced there’s still much to improve in the best practices sharing process in a software development context 🚀.
💥 Let’s dive into the three main failures met by developers.
This typical pattern is easy to explain: the team has never initiated a process to record some of their best coding practices, which all went through human interactions and discussions. Considering the high turnover in our industry and the need to onboard new developers regularly, there’s probably a colossal knowledge loss there.
Sometimes it’s even “worse”: developers never discuss their best practices, there are no code reviews, or pair/mob programming, so there’s no rigorous methodology about how the source code should be written in our context. Developers have different backgrounds and preferences when they code. To maintain a codebase efficiently as a team, it does matter to align the way we want the source code to be written.
If a group of people took the initiative to write down some best practices, it usually ends in a place like a generic Wiki. It’s a great start to gather a group of contributors, like in an Inner Source model. But without consumers/readers, does it worth it?
Knowledge has value only if it’s shared.
Shared does not mean “available somewhere if you’ve got the link”. It should be presented during technical meetings (best option) or pushed to developers asynchronously using some appropriate channel. Synchronous discussions are the best way to determine if everyone understood them, to bring clarifications, and to optimize the adhesion to these practices.
We said previously that if there’s no efficient process for regularly updating & discussing best practices, the core contributors will lose motivation and stop producing content. Have you ever had this uncomfortable feeling when onboarding a new developer, asking you, “do you have a best practices guide ?”, and you, answering: “Yes, but it’s no longer maintained”.
That’s a tough challenge; honestly, most companies hardly struggle to overcome the three problems.
If you’re interested in going further, the Promyze platform has been designed to ease best practices for software developers:
- Thanks to IDE/Code review extensions, Promyze lets developers easily create and suggest best practices to their team;
- Regular technical meetings happen to review contributions and validate or not new best practices;
- Practices are available through the extensions while coding or reviewing source code;
- Onboarding modules can be created from the existing knowledge base, and Promyze also provides automatic suggestions to detect bad practices automatically.
🌟 Want to give it a try? You can get started on Promyze for free.
Of course, other alternatives deserve to be explored. I’d be happy to have your feedback on that topic; whether you’ve succeeded or failed, we always learn from our experiences.