Why Good Communication Is Vital for Developers

Paul Green
The Startup
Published in
5 min readJul 24, 2020

--

We all know of the stereotype software developer. They prefer the company of computers rather than people and are uncomfortable communicators. Inside every software developer, there is probably an element of this — you must be comfortable spending long periods interfacing with computers.

But is good communication important for the modern, aspiring, developer?

Laptop with code sits on an empty wooden desk
Photo by Maxwell Nelson on Unsplash

Going Solo

I’m sure many of us have fond memories of intense coding sessions. The moment where computer and human become one, with code flowing from the fingertips to function without obstruction. You feel omnipotent, as order is formed from chaos.

It’s a personal experience, a journey, shared only with the cursor blinking back at you. There is no crowd cheering on in amazement. There is no back slapping buddy waiting for a high five. It’s a cerebral, solo, addictive, rewarding feeling that little else can satisfy.

Must we communicate? When it feels so good to code, why do we have to stop?

Talent Is Nothing Without Focus and Endurance

While it may feel great to write code, it must have a purpose if you are to make a career out of it. Writing the cleanest code, with the fastest functionality, will not pay the bills unless it fits the requirement — your enthusiasm and talent to create, must have a focus.

I’ve had times in my career when I’ve developed great code. I’ve wanted to show people its intricacies, to help them appreciate its glory and elegance. My boss didn’t care though. What he did care about was the user experience. He cared about what the application achieved, about how users would interact with it. From his perspective, the software was not fit for purpose. He was clearly very disappointed.

What went wrong? Communication failed. I was happily tearing through the code, feeling pleased with the progress. Sadly, I was creating castles in the sky, each meticulously engineered, but without a clear purpose.

Understanding The Problem

Identifying the requirements precisely is the first step towards building the solution. You may think you know what is needed, but you must be certain. The process which bridges this gap is communication. If you wish to be a successful developer, you must take responsibility for this.

If you work in a large corporation, you may be sheltered from the stakeholders. The requirements that make it to your desk are concise, considered and complete. They may have been prioritised, sized and be perfectly defined, bite sized, pieces of work. The communication required to fill any gaps may be limited to a few simple questions.

Screwed up paper with ‘ideas’ written on it
Photo by Nick Fewings on Unsplash

If you are working directly with stakeholders, often all you have is an inspirational speech or a few scribbles to work from. Turning these into something you can start to implement requires another level of communication. These are often not technical people, but they know what the business needs.

When talking with stakeholders, their view on what constitutes as ‘requirements’ may be completely different to yours. You must ask the right questions to understand their goals. You must even interrogate what appear to be firm, technical, requirements, as they may not be reasonable or evidence based. Put yourself in their position — as a business person — then work backwards towards a potential solution.

“I created what they asked for!” — While this may be true, it doesn’t help you or them.

Ask The Right Questions

Knowing what to ask can be a matter of experience, but some points to consider are:

Goal — What is the goal of the application? Is it a new or existing platform? Is the goal just to modernise an existing platform or is it to add new capabilities?

Interfaces — What are the interface points are how should they be defined? Are they user or internal interfaces? Are there existing interactions with dependent systems? Are there any shared resources between these systems?

Performance — What is the performance expectation? Does data need to be processed in real time or can it be batched, streamed and interrogated later?

Resilience — Must the application be highly resilient or is down time more of an inconvenience? Is adding additional features more important?

Security — How sensitive is the data being stored? If the data was accessed without permission, what would be the impact? Is the data location sensitive?

Technology — Are there technologies that must be used to comply with company standards? Is maintaining the software over a long period of time more important than using the latest and greatest technology? Is there in-house expertise to maintain the application? Is training or documentation required?

Migration — If there is an existing system, should transition be seamless or is a migration process acceptable? What is an acceptable impact, if migration is desirable? Will training be required both internally or externally?

Time — What are the delivery expectations and timescales? Should some features be prioritised over others to benefit the business? Are incremental or phased improvements desirable over a big bang release?

Every project and feature is different, but it is always important to gain context. Each decision point may add or save time, which can have an impact on the business. Some requirements may be critical to implement at any cost, while others may simply be desirable. Trying to separate the two is key.

But I just want to code!

If you can relate to business people, to bridge the gap between their domain and yours, you will be a powerful asset. It will elevate your position from coder to consultant. It will give you the power to influence what technical decisions are made, which can vastly improve the quality of the outcome. In turn, this will lead to your personal success.

Dark room with man at computer surrounded by bright screens
Photo by Max Duzij on Unsplash

Being able to distil aspirations into firm requirements can release your inner coder. It will allow you to roam free, confident in the knowledge that your creativity has purpose. It will enable you to use the right tools for the job, ensuring it is completed to a high standard.

Once you have cracked the consultancy question, you may find the process rewarding too. In the short term, you will avoid uncomfortable appraisals and disappointments. In the long term, it will help you to develop your career and lead you towards fresh business opportunities.

--

--

Paul Green
The Startup

Founder and consultant at Codiate, with over 20 years of experience as a developer. www.linkedin.com/in/paul-s-green