Have you ever talked to a software developer? You know that nerdy guy sitting in the corner of the office with his headphones on writing mystical commands very fast on his keyboard?

It’s very common that us, software developers, are introverts and instead of talking would like to concentrate on programming. I am software developer myself and I can see introvert side of me popping out from time to time while I try my best to hide it in most situations. Talking for introverts is not an easy thing to do but really necessary especially if they have to meet with a customer or present in stressful situations like for a large audience.

If you haven’t noticed, it’s not easy to talk with a person who doesn’t answer or doesn’t express their opinion. With software developers this might be the case if you are talking about something else than some technical, programming related things. In fact, when talking about software development with software developers you can see some of them opening up and then it’s really hard to stop them going on — especially if the topic is very dear for the developer. If you’re not in software industry and know a somewhat shy developer, I encourage you to try this out.

#### Importance of good communication

What makes this interesting is that it’s really essential to have good communication methods and skills in software development. Passing information about specifications, requirements, bugs in the code etc. is really crucial for the developer, the product and the business. There must be strong common understanding between the requester and the one actually doing the work. Otherwise you might end up with bad or even completely wrong solution for the problem at hand.

Many times information is lost no matter what communication method is used. To be sure all necessary information is known to people you should ask questions or test them otherwise. This might be difficult especially if the audience is large.

#### Silent information

Among developers there is **A LOT** of silent information that is not shared anywhere. Problem with this information is that it’s only known to an individual or at best, a small group. There are communication methods that allow sharing this kind of information but the problem is that they are rarely used correctly or at all. Especially developers are often not willing to share their knowledge to public at least inside business they are working at — after all, their knowledge is the reason they are paid.

I have seen, and also been, in a situation where person is about to leave his/hers current team and last task is to write everything they know somewhere. This shouldn’t be the way to do things but instead all developers should be encouraged to keep up data in some location for all crucial information others might need. Especially developers in key positions should be active with this because of the well-known [Bus factor](https://en.wikipedia.org/wiki/Bus_factor).

![](https://hackernoon.com/hn-images/0*9pybswMWIO9iOiex.)

#### Methods

While talking may not be the best way to communicate with software developer (of course depends on the person), there are multiple other ways to do this:

*   **Email** — Oh the good old email. There was [study](https://blog.sanebox.com/2016/02/18/email-overload-research-statistics-sanebox/) that showed that an average person uses 28% of their work time for reading and answering email. This is a lot of time and most of the emails don’t even have information relevant to the receiver. So if you are communicating plainly with email, I consider using something else or at least check your _TO_ field carefully to only include people who actually need the information. Personally I hate email because I get lots of unnecessary mails and would use some other channel instead if possible.
*   **Instant messaging** — Skype, WhatsApp, you name it. The IM systems popped out during the 90’s and there are lots of provides for different systems now-a-days. In most companies at least one IM system is in use — some even have many of them which makes it even more difficult to do your work without interruptions. Problem with IM is that sometimes people miss the information as they are not at the time on computer.
*   **Wikis** — Wiki systems are another way of communication and they are used widely in many organizations. While wikis can be used powerfully to provide information to lots of people, they usually lack functionality to notify people about new information. Also most of the wiki systems do not have, or have very bad, version control and there is no possibility to check what was changed and by who. Another problem is that these systems need to be kept up to date or they do not benefit anyone; have you ever bumped into an old wiki page?
*   **Chat systems** — IRC, Rocket.chat, etc. These systems are good for sharing information for a group of people at the same time. Also they do not overload people as much as for example IM as the information can be read when the person has time and can concentrate on the information. Problem with these systems is that it’s really hard to get back to previous conversation. Also they mostly lack notifications about new content which is good and bad.
*   **Issue queues** — Use of JIRA, bugzilla or other systems to exchange information about development is very common in today’s software development. Main problem with these systems is the lack of feedback of changes where they mostly fallback to sending email. While these systems can add lot of value to the development process if used correctly they are not very useful for getting
*   **Social media** — Many social media platforms, such as Facebook ([Workplace](https://www.facebook.com/workplace)), are offering tools for companies to have their own, internal, social media channels for their employees. This is actually very interesting way of communication in businesses and I could see it tackling most of the problems with other methods. For software developers these platforms might not be the best solution as at least some of them are against these platforms by nature.
*   **Drawing** — One of my favorite ways of communicating with people. Drawing to a whiteboard or a paper can open totally new perspectives to the problem. Problem with drawing is that it can only be distributed to the persons in the same room as most of the time drawing requires also some verbal communication to make it understandable. It’s same problem if you use some program (slides or digital images) for communication. Also most of the tools lack support for version control.
*   **Multimedia**—Methods such as videos or audio recordings can be used to share information to lots of people. These methods have their own place and should be utilized for example for simple trainings as much as possible as they will always save someones time (trainer or trainees). Problem is that they are not very easy to keep up to date and usually require more effort than just presenting information to the audience.

These are some of the most used systems for communication used among developers. Most of them have some problems and can be overused which can lead to spending time on totally unnecessary things. If you can invent one to tackle all the listed problems I think you would become a millionaire.

#### Interruptions

Interruptions, as you may know, are the worst thing you can introduce to a developer at work. According to one study it can take [up to 25 minutes](https://www.fastcompany.com/944128/worker-interrupted-cost-task-switching) to get back to task after an interruption. This can cause significant losses to the business and is also very frustrating for the developers. In the longer run constant interruptions can decrease job satisfaction and cause even more damage in ones performance.

Personally I prefer communication methods that do not create an immediate interruption while still notifying the receiver about new content. Of course sometimes instant messages are necessary but one should always think twice before using them — especially if the receiver is in deep “flow” state. Even a simple questions over IM, phone call or by talking can create interruption that will take minutes to overcome. Please try to remember this if your matter is not urgent and you don’t need answer straight away.

#### The superlative

![](https://hackernoon.com/hn-images/0*7lVB2XXGhXhIKWGR.jpg)

© [http://finnishnightmares.blogspot.fi/](http://finnishnightmares.blogspot.fi/)

Superlative for introvert developer must be FINNISH DEVELOPER. Many of you might know that us Finns are not the most talkative nation. Mix that with being a software developer and you have person that doesn’t talk much but when he/she does, you really should listen.

#### Putting it all together

Most important thing is that you communicate, no matter what method you use. What comes to the methods you should really try out different things and agree together what works and what doesn’t. Also try to avoid unnecessary interruptions as they will cost you a lot of time (=money).

I am also interested if you have seen problems in communication and what has been your solution to those. Please leave me a response!

### About me

I am Heikki Hellgren, Software developer and technology enthusiast working at [Elektrobit Automotive](https://www.elektrobit.com/). My interests are in software construction, tools, automatic testing and all the new and cool stuff like AI and autonomous driving. You can follow me on [Medium](https://medium.com/@drodil) and [Twitter](https://twitter.com/dr0dil). Also you can check out my [website](https://drodil.kapsi.fi/) for more information.

Facebook

Twitter

Read My Stories

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

Communicating in software development

Too Long; Didn't Read

People Mentioned

Companies Mentioned

@drodil

RELATED STORIES