Many software developers have a tendency to avoid talking to people. They would rather just rely on written communication in chats, email or issue tracker tickets. However, talking to people more can make them more effective as software developers. Here are some examples:
Example 1. Suppose you are implementing a new feature. The ticket in the issue tracker describes how the new functionality should work. As you start working on it, you discover that implementing it exactly the way it is described will be difficult and take quite a bit of time. However, if the new feature it changed slightly, it fits right in with the existing code, so it would be possible to implement it much faster. At this point, many developers think to themselves: “they asked for the more complicated version, so that’s what I’ll implement”.
Instead, talk to the product manager (or whoever requested the feature) and explain the trade-off you discovered (slightly changed feature would be much faster to implement). Ask if they still want it as originally described. The point isn’t that you should persuade them that the feature should be changed – the point is to let them know about the trade-off. Often they are not aware of it. Whether they change their mind or not, the discussion leads to better understanding for both of you.
Example 2. Recently, a tester was verifying some small changes I had made. He wrote down in the ticket the cases that worked, and some cases that didn’t work. The reason some cases didn’t work had to do with how I had deployed the new version of the software. I could have written down an explanation of that in the ticket. However, it takes time to explain something clearly in writing. So instead I walked over to him and explained what had happened. This way, he had the opportunity to ask more questions, and I had the opportunity to add more clarification without it ping-ponging back and forth as comments in the ticket.
Even better, as we were talking about the ticket, I showed how I would check if the problem was due to the deployment or not. As I did that, he said “wait, what was that” – he had never used the command I used. So not only was the problem cleared up quickly, the tester learned a command he didn’t know about.
Example 3. The other day, I was going to add a feature that required knowing if another feature had been activated or not. The activation check had been a bit problematic before, so I wanted to clean it up a little in the process. So I thought about where to put the changed activation check. But before going ahead and implementing the solution, I mentioned to a colleague what I intended to do.
He immediately said “why don’t you put it there instead?”. Sure enough, his proposal was much better than mine – a better place to put it, and less impact overall on the code. So by just discussing for a few minutes, we found a better solution. I think of this as an informal design review, similar to a code review, but done before implementation, not after. I frequently try to discuss a change with a colleague before going ahead and doing it. Time and again I am grateful that I did. Many times we discover flaws, or better solutions, that I would never have thought of, no matter how hard I tried. So with a little bit of discussing, I end up with much better solutions.
Conclusion
In a lot of cases, talking to developers, testers, product managers and other stake-holders is beneficial to both parties. It is usually also faster than written communication. Despite this, I see many developers that are a bit reluctant. If you are one of those developers, make an effort to talk more to people for a few weeks, and see if it makes a difference.
Top comments (0)