Of course, by now you should have figured out that communication is just as important as programming when it comes to software engineering.
Wait, let me start over.
At the start of my career, I was trained by a very passionate programmer. He was always up-to-date with the newest frameworks, patterns, and code styles. He helped me when I was stuck with a bug or asked to brainstorm about possible solutions. He was very detailed and puristic but also kept a good overview of the entire project.
Within a year, he was fired.
You see, although he was good at programming, he had a hard time communicating with the business. In fact, he built what he thought was right from a technical point of view rather than what users and stakeholders had requested.
Deja Vu
What did you think and feel when you read the first sentence of the article? Some might have thought, "yeah, obviously." Some might have been skeptical, and others might have felt stressed because they believed that software engineering was mostly about programming and now feel ashamed they did not know that.
The second part of the introduction makes the exact same point as the first sentence, but with a different tone and without making assumptions about what the reader knows.
Elephant
The curse of knowledge is the biggest elephant in the room that many software engineers do not see or choose to ignore. It is present during meetings, presentations, and many conversations between engineers.
The curse of knowledge is a cognitive bias that occurs when an individual, who is communicating with others, assumes that others have information that is only available to themselves, assuming they all share a background and understanding.
All roads to Rome are different
Every developer has had a unique career. They worked at different companies, on different teams, and with different technologies. Yet, we often assume that others know what we know ourselves. This applies to having learned how to use a certain technology, but more importantly, why and when using a technology or pattern works, or why not. Making a certain decision is completely logical for you because of your experience and knowledge, but that same decision could sound like a very bad idea to a colleague given their experience!
Curing the curse
Luckily, we don't have to be cursed forever. We can overcome this with three changes in how we discuss things with our colleagues.
1. It's about the journey
Unit testing can be done in different styles. I happen to be a fan of small-and-simple tests, sacrificing brevity for simplicity and maintainability.
At one of my past jobs, I pitched that we could switch to that style. Although my teammates were interested, they stuck to their own style.
Later, during a retrospective, I told them that I lost many hours fixing unit tests while working on a large refactoring. This was because certain business rules were tested over and over again in different unit tests instead of in one. Moreover, some tests were over 100 lines and had many different assertions, making them hard to grasp and to know what exactly to change. If we had used small and simple tests that only tested one thing each, it would have saved a lot of time during the refactoring.
After sharing this experience, they became more curious. We started refactoring some tests to the small-and-simple style, and we have all been fans ever since.
Just name-dropping the single-assert principle did not show the value to the team. Frankly, I would not have been convinced either. But once I shared my experience, one that they could relate to, they gained the same insights! Share your experience and let your colleagues come to the same conclusion. They can also share one of their experiences to show why they come to a different conclusion, which also increases your understanding.
2. Consider your colleague's journey as well
Sharing an experience instead of a statement is not enough if your colleagues are not familiar with what you are proposing.
One time my team and I faced a fundamental problem in our data model, which restricted us from delivering the requested features. We went to the drawing board, and a part of the team agreed that a certain controversial pattern would solve our problem. We explained to the rest how it would solve our problems and what all the benefits would be. To my surprise, not all colleagues were on board, while for me it was obviously the best way forward.
A few times a year, I ask teammates for feedback on my performance and if they have any tips. As it turned out, they mentioned that situation and told me that although the idea sounded cool, we forgot to explain the basic mechanisms underlying the pattern we were proposing. Would you be convinced to adopt a new complex solution without understanding how it would work? Of course not! Since then, I try to make sure to build up to a certain solution I want to propose.
3. Dare to be vulnerable
One thing I learned over the years is to not be afraid to admit when I do not know something. I recently switched between technology stacks and sometimes have to ask basic questions about the programming language we are working in, as I was used to different languages in the last few years. The same goes for business concepts, abbreviations, and software patterns I am not familiar with during meetings.
This has two advantages. First and foremost, I fill the gap in my knowledge as quickly as possible so I can participate in the discussion again. Secondly, it opens the door for other colleagues to do the same, creating a safe environment. Both help to cure the curse of knowledge in a group setting.
The 3 takeaways
Share your experiences rather than principles or conclusions. This gives others insight and understanding and can save a lot of frustration during meetings.
Do not assume your colleagues know everything you know. Feel out where their level lies on a certain topic and build up to your idea from there.
Be vulnerable by admitting what you do not know. This helps create a safe place for others to do the same and allows others to bring you up to speed. After that, you can participate in the discussion.
Keep these things in mind for your next whiteboard session and thanks for reading!