When I first start thinking about writing about this topic I was waiting for a flight in the airport some years ago when I was still a junior software engineer. These career thoughts came up in mind after a major bug was released by an experienced engineer that could be evicted. Of course this is not about the bug itself, but it motivated me on writing this post. Hope you enjoy!
Knowledge Sharing
Everyone who works with software development knows how things can grow and get really complex. Even the simplest programs, the ones that solve simple problems, could be hard to understand and not be so straightforward as you think - or as the one who made it thinks.
This unbalanced understanding has many causes that I can address shortly.
In an average-sized company, there are people with different knowledge levels that work on the same project. A piece of code, an architecture decision or a certain model design can make sense for someone in a considered higher level of knowledge, but not for an entry-level engineer.
Another probable motive that makes a project harder to be understood is that teams are sometimes focused on some certain technology stacks and due to the rapid changes of priorities, a developer may see her/himself ahead of a new project with a completely different stack.
A pretty obvious cause is lack of documentation. We all know we should document our projects, but we never do. It's common to do that after the project is considered done and the team has few energy left to do so. It is important to make informal notes to document the decisions made through the project development process and wrap it all up on the very end or increment it along with the code itself. This could mitigate not only the causes previously quoted but also prevent over engineering since we will have a macro vision of everything by the time the design decisions are being made.
Whit that being said, we can see that with proper documentation and simply sharing information with others we can prevent hours of workforce trying to figure out how a software work (or why it isn't). In a higher level a proper knowledge management system is extremely important, but I'll not cover in this post. So why don't we just start sharing all we know? This open a precedence of what I call relevance.
Relevance
Before actually write about this topic, I want to make sure that not all professionals think and behave the same and this is my humble opinion about it.
Everyone wants to be relevant inside a company and have all the benefits that come along with it. Promotions, acknowledgments, good feedback etc are always welcome for any professional willing to grow and develop his/her career. Although this is true, having that by any cost is not write at all, at least in my opinion.
This eager of being vital in the company sometimes make people hold crucial information to themselves, mainly when dealing with legacy software. By keeping these to themselves, some may have the false sensation of usefulness and start to think things like: "If I'm the only who knows it, I will never be fired." or "People will see me as a reference if I'm the only one who knows that.".
Those thoughts might work for you. You can be in a company for years having this approach. However, this mistaken sense of ownership could lead to unhealthy work environment and could cost a lot to the company as the productivity is not as good as if you share what you know with others.
I can imagine many unpleasant situations if you stick with this behavior. Being the only one called off the working hours when some bug occurs, having to always take questions from others and being stick to legacy projects on the company are some of the things you might go through. Moreover, other professionals may need the information you're holding and insist to have it. In other words, don't be this kind of professional.
Side note: Everyone is replaceable, holding information to yourself is not your safeguard.
Tips
For those who didn't read the entire post, these are some important tips I would like to share:
- Keep in mind that the code you're writing is not for yourself. Pretend that some completely random people will try to understand your project.
- You can get out of the company at any moment. By your free will or not. Who is going to take on your duties?
- The IT network could be used in your favor. Your legacy in your current company will be important for you in the future. Share what you know.
- This is for life: Be on others shoes. Always try to think how would you feel if no one shared their knowledge with you.
Oldest comments (2)
Thank you for the knowledge sharing, it was a good reading!
I want to highlight about "people hold crucial information to themselves."
Being the only one who knows about a software or a system may give you the illusion of stability, but it isn't the best option.
Knowledge is better when shared, I use this in my daily life. We can all share, learn and grow together.
Imagine if no one shared, in the past, knowledge with you, how much would you know today?
Thanks for the reply, that's absolutely right.
Beyond following my last tip to be on others shoes I can picture a scenario where someone may get the same information by other means and the person holding the information to him/herself is the only one losing.
I'm pretty glad you are aware of that and you practice knowledge in your daily life, Eduardo.