Communicating as a software developer

Communicating as a software developer

Communicating as a software developer was more than I thought.

Introduction

I've now worked almost a year as a software developer, looking back, the communication aspect was more than I expected.

It was also difficult because it is not something you knew when learning to code and trying to land that first job as a software developer, hence it was something new.

Non-technical people

Communicating with non-technical people, during meetings, for example, the daily stand-ups, is tricky.

You need to keep in mind, that those people aren't developers, so don't speak using terms that you know only developers would understand.

Oftentimes you have to explain from a high-level perspective, using non-technical words, for example, what you did.

Let me give an example.

Technical aspect

  • The drag and drop functionality when reordering the tracks doesn't work properly, the items in the array are somehow getting shuffled.

Non-technical aspect

  • When reordering the tracks by dragging them, the tracklist somehow gets shuffled.

Now, this is just a quick example to demonstrate speaking to non-technical people. Try to avoid speaking in a technical fashion using words such as array.

In some instances it could be difficult, I then recommend breaking down and explaining technical terms. Sometimes I find myself using technical terms, then I try to go something in the lines of:

  • ...in non-technical words, this means the tracklist unexpectedly gets shuffled when a user tries to reorder the tracks....

This is the approach I take if I find myself having explained something in a technical fashion, but shouldn't have done so in the first place, but in some instances it is difficult, so I may start explaining it in a technical fashion as a start, and then, later on, re-express myself in a non-technical fashion.

Technical people

Speaking with technical people can be more difficult and challenging in the beginning, but is from my experience easier to get better at compared to the art of communicating with non-technical people.

Questions

Often times you will find yourself asking questions, not just when you are learning to code, but also throughout your whole career as a software developer.

Asking good questions, which I wouldn't say is difficult, but is something to be learned itself.

Your question should only contain the relevant information.

Your question should contain:

  • What is the problem?

  • What have you tried so far?

  • Do you have any assumptions?

  • Include code or other samples depending on what you are dealing with.

I strongly advise reading this wonderful article about asking good questions by my friend Artem Zakharchenko.

Developer language

Speaking with developers itself can be tough. Using language developers understand. My advice is to do a lot of pair programming, it's gonna help in this aspect tremendously from my experience.

An example would be explaining to a developer how they would approach solving a bug, refactor code, etc.

In order to explain what to do, you need to use technical terms as well, an example:

This function seems to be taking a flag argument, let's extract the logic into another function. Where the function got called, let's either call this or the new function depending on if the boolean is true. This way each function does one thing and does it well hence is easier to refactor and work with later.

Selling ideas

Perhaps you have an idea and want your team to try something, a practice, a new library, a new tool, whatever that may be.

In the end, what truly matters when developing software, are the customers.

My advice is to focus on the customers, how is the idea that you've gonna affect them, make them happier and more satisfied?

If you can express that clearly, then you've sold your idea greatly, and you understand yourself, as a software professional, why your idea should be implemented or is worth trying out at least.

An example would be why we should practice pair programming:

By pair programming we can get things done more efficiently and with quality, hence deliver better software faster, which will make our customers happier. Another bonus with pair programming is the shared learning, developers learning from one and other, which helps the team and company greatly, increasing the bus factor.

Conclusion

Communication in software development is not easy, especially at the beginning of your career, and itself is surely something very important throughout your whole career as a software developer.