Today, most software systems are so complex that no single person can fully comprehend them. Whether we like it or not, the norm is to have teams of software developers. No one can disappear into their corner and emerge with a complete system implemented a few weeks later. Work is divided into small units, like, for example, stories, with narrowly defined scope and deliverables. Often, these units are interdependent, so the work of one developer is usually intermingled with that of other team members.

It doesn’t take a giant leap to see that coordination is essential. Many times, developers will work on the same code base and even on the same file. Hence, it is easy to trample over someone else’s code if one is not careful. Version control systems assist to some extent in avoiding this situation, but that’s not enough.

The role of communication

Tools can help, but communication is one of the critical elements of successful teamwork. Communication needs to happen early and often. That’s the only way to ensure everyone is aware of what is happening at all times. This is a common trait of teams with critical missions. We can see this in the military, team sports, and even video games. There should be constant updates and lots of back and forth about what every member is doing, what their status is, and what problems they may be facing.

In the realm of software engineering, agile methodologies incorporate frequent communication; for example, daily standup meetings are a common practice. Nonetheless, communication remains important whether a team is following agile or not.

The fear of failure

It isn’t hard to grasp the importance of communication when things are going well. However, when problems arise, things become dicey. Suppose we find ourselves stuck, or maybe we have no idea how to solve a problem, or don’t even understand what we are dealing with. In that case, the tendency is to shy away from telling others about it. Some say they prefer to research until they know enough to ask intelligent questions. Or they will try solving the problem until they present what they have tried. In my experience (including when I find myself in the same situation), these are just excuses to delay having to “confess.” There is a fear of appearing inept or ignorant. While understandable, that is a serious mistake.

I know this because I used to do that. Whenever I faced an engineering problem, I would double down and try to find the solution and fix it on my own. I would not tell anyone because I did not want to seem “less able.” It sounds like a good idea, right? You go to your corner and work furiously on something for hours, days, and even weeks. Then you emerge from the cave with the solved problem, very proud of your accomplishment, very aware of how hard it was to produce your masterpiece. You tell your boss or teammates about your adventure, expecting recognition and praise.

Unfortunately, what is most likely to happen is that your workmates and, worse, your boss will wonder why it took so long for you to produce your deliverable. Why? Are they jerks who think they could do better? No, not really. The problem is that they were not aware of your battle. To everyone, you were working on your task without hitches. They never heard of any issues or setbacks. So, logically, everything you did was within your expertise. You just took too long to finish, probably even blocking others or impacting deadlines.

Say it. Say it early. Say it often.

Here’s the thing. As we saw earlier, software systems are so complex, and there are so many areas of knowledge and technologies that no one can master them all. The hero, the rockstar developer who knows it all, is more of a myth.

Over time, I learned that being candid about what I don’t know and what is giving me trouble actually works in my favor. First, people with more knowledge are usually happy to share it. Bouncing ideas and questions with others can be faster and more satisfying than spending hours googling or running into blind alleys.

Second, letting others know the challenges you are facing gives them an idea of what you are working on and, more importantly, what you are doing to solve the problem. They will understand that you are busy, even if progress is slow. Chances are that some will have valuable ideas and suggestions or know the solution outright.

Third, the boss or manager will know what is going on. Managers do not like to be in the dark and do not like surprises. By communicating often with them, they will learn the status of the project: its progress, risks, and obstacles that may not have been considered during planning. Armed with this knowledge, they can re-prioritize, drop, or move out tasks.

My suggestion is then to communicate. Be proactive. If no one is asking how’s it going, take the initiative and volunteer your status report. Be frank. Report successes and failures. When faced with challenges, be quick to report them as well as what you are doing or plan to do to overcome them.

(All images are properly licensed.)