Six Steps to Better Communication as a Software Developer
I’ve long held that communication is the most important skill for a software developer. Here are some quick-hitting tips that have helped me become a better communicator.
1. Be responsive but honest
Reply to emails as soon as you get them, but don’t give quick answers for the sake of having a quick answer to give. It’s important to let the other party know that you’ve acknowledged their request and (if you don’t have an answer ready) that you’ll get back with them when you’ve had more time to research.
People are generally OK waiting for your to respond if they know that you’ve understood and acknowledged their request; what drives people crazy is not knowing if you even read their email.
2. Let your availability be very public
The next best thing to responding to every email/phone call as soon as they are received is to let everyone on the team know when you are available. It’s important for your team to know when they can reach you, and when they should expect that you will not be able to respond.
You should be strict in not responding during your off hours; if it appears that you are always available to talk, even during family time, then your colleagues won’t respect that time as truly “off time” and you could be branded as “un-responsive” because you don’t respond.
3. Be empathic
This is a hard thing to master, but it is super valuable when you get it down. Your teammates are humans (hopefully) and they have lives that affect their own ability to communicate; you should do your best to be aware of their situation when responding to them. If a team member sends in a very long and opinionated email at 9pm about an issue with the team; that’s probably something very important to them; your response should reflect that you understand this gravity.
I personally believe that building genuine relationships with your team members is one of the most valuable things you can do as a software developer; it’s very difficult to build genuine relationships without some depth of empathy.
4. Figure out co-worker’s medium preferences
This is related to empathy, but I feel it needs a category all it’s own: you should be aware of the communication mediums that each of your co-workers prefer. If Sally generally is very responsive over email, then you should make an effort to communicate with her predominately over email, even if it is not your own preferred medium.
It’s also important to be introspective, and understand your own preferences; this will help you to identify any bias you may have for using a particular medium over others and how your particular communication style may be affecting your team.
5. Clarify misunderstandings early and often
If something is confusing to you, it’s probably confusing to other people as well; you are doing no one any favors by reserving your confusion until it causes problems for the business. People generally don’t mind clarifying things, so ask them!
You should also make an effort to be cognizant of likely misunderstandings in your own communications and attempt to preempt them with clarifications (This is a trivial but powerful example: if you are writing an email to a new-hire about some internal tools, don’t blindly use company-specific acronyms without defining them!)
6. Document Everything
If you made change to something; write it down. If you stumbled across something confusing and subsequently figured out how to solve it, write it down. If you had to do something funky to get development software working correctly (and are assuming it was “just you with this problem”) - write it down!
Where you write it down is important; it should be some place that everyone else can also access. I don’t think I’ve come across one peculiarity that no one else at the company has seen before (or eventually saw again). Writing down how you solved problems will always be worth the time it takes you, and will likely save you (or someone else) several multiples of work time when you/them come across that problem again.
The top 20 most frustrating experiences I’ve had as a software developer were the result of having to re-solve problems already experienced by myself or someone else that could have been quickly dismissed if the solution was simply written down.