editione1.0.1
Updated August 7, 2023Good communication is about being able to convey your ideas in ways that are properly received by your audience. It’s simply not enough to assume that just because you said something people will understand your ideas. You may not always be able to get your point across, which can be frustrating as a programmer when it comes to conveying technical ideas to your teammates.
Additionally, just because you tell someone something doesn’t mean it’s no longer your responsibility. As programmers, we’re prone to the bystander effect when it comes to the maintenance and operations of our systems. Individuals are less likely to take responsibility for something when there are other people present, because they assume someone else will step up to the plate and take care of what needs to be done.
don’tYou: “It looks like the build server is about to run out of disk space, which will block deployments and prevent tests from running on pull requests.”
Later that day, the build server runs out of disk space.
You: “I thought someone was going to fix this since I announced it during stand-up?”
Your teammate: “I thought you were going to fix it since you announced it during stand-up.”
doYou: “It looks like the build server is about to run out of disk space, which will block deployments and prevent tests from running on pull requests. Does anyone know how to clean up the old builds so we can prevent this from happening?”
Your teammate: “Yes, I cleaned up the old builds last time this happened. Come find me after stand-up and we can take care of it together.”
You: “Thanks, I can document the steps as you walk me through them so anyone will be able to do it next time.”
A better approach is to not only communicate what the problem is, but also communicate what actions should be taken, and if possible, come to an agreement on who will take responsibility.
The best communicators are successful because they have the ability to inspire actions that lead to certain outcomes. Senior engineers tend to learn this skill as they work to develop their teammates and improve the codebase. They don’t just assume that everyone will understand what needs to be done or how something should be done, and they know that just raising concerns about something doesn’t mean it will get done. If you want something to get done, you’ll need to learn how to inspire action.
If you stick with programming long enough, you’ll eventually be a part of some emotional discussions. As programmers, we take pride in our craft, and it can be easy for individuals to get attached to certain solutions or architectural designs. You’ll deal with conflicting views at some point in your career, and emotions may run high.
It’s okay to disagree with your teammates, but how you handle yourself will speak volumes about your character and how your teammates view you. In fact, healthy debates are a sign of a high-functioning team, but the discussions must be respectful. While it’s good to debate the pros and cons of different designs and algorithms, it can be bad if things turn from a civil conversation to a full-blown argument.
In rare cases, passionate developers may get into tense arguments over which solution is the better approach. It’s possible that each approach has its strengths, weaknesses, and trade-offs, and that both developers are correct. No solution is perfect, and that’s okay.