Soft Skills for Software Engineers — Part 1: Communications

If you want to be a software engineer — you need to have tech and coding skills. If you're going to be a great software engineer and go ahead — you need to add soft skills.

Regardless of our profession, we often ask ourselves — what we need to develop to be better, primarily if we work in software development and the IT-sphere. And a few weeks ago, we just asked the same question inside one of the software development teams in our company. And one of the answers was — soft skills. So we tried to understand which of them are necessary and collect basic info from different sources. Our goal was to create a basis for each essential skill and have a few useful links and advice for developing this direction. Let’s start with communications because communications are everywhere.

Communication Skills

Effective communication can make a significant difference between an average software engineer and a highly performing rockstar. Programming isn’t just about talking with servers, clients, API-s, and IDE. Being on the same page as your teammates and colleagues do matter. Communications can be incredibly challenging when you add in the remote work factor as we have today. Communication can include asking people how they want to be spoken to and explaining your own boundaries, provide and receive feedback. Always keep in mind that communication is a two-way road, so if summarize it in short words:

• Listen — before you start giving your perspective on the development process, listen to your teammates, and try to get on the same page — it’s key to finding the best solution. When you listen, you are getting an unfair advantage compared to those who only talk. You get to learn things, expand your horizons, and broaden your worldview. It also helps you rank tasks and requirements.
• Don’t Interrupt — interrupting usually happens when a software engineer knows something that he feels can’t wait until others are finished talking. Just wait. It’s important to wait until the other person is finished talking.
• Speak Clearly — do it with confidence, clarity, conviction, your ability to communicate is a handy tool. So, use it!

Ask and Respond to Questions

Knowing how to ask the right questions in the right way is one of the critical skills in software engineering workflow. A well-structured question will return a useful and direct answer. Even more — sometimes a good question already contains half of the answer. If you don’t communicate with other people, you will be left alone with complex and maybe even impossible tasks sooner or later. It’s related to all your potential communications — teammates, customers, engineers from other teams, etc. No matter how professional you feel, there will always be a problem that you can’t solve alone. It’s ok to miss some knowledge. It’s ok to ask for help. It’s ok when somebody asks for your help. It’s ok to be wrong. It’s ok, so don’t hesitate to do it! Teamwork makes it easier to deal with complexities.

Useful links and how to push skill forward:

• If you need some help, ask for it. If you’ve been proven to be wrong, then you’ve just learned something new, and the next time, you’ll be right.
• Communication is a two-way road. So listen and actively listening! The best communicators spend as much time listening as they do talking.
• Forget about the fear of sounding unintelligent — questions are asked to gain understanding.
• Use a straightforward but effective algorithm from this article
• The art of asking questions for developers
• How to Ask Questions as a junior developer
• How to ask Questions as a Jr. Dev
• How to Ask Effective Questions: A Practical Guide for Developers

Provide and Receive Feedback

Feedback is one of the few tools that allows you to convey your own expectations to colleagues and help shape growth points. Feedback from other people, in turn, provides material and information for reflection. A great software engineer should support colleagues’ ideas, back up their arguments, give positive or constructive feedback — and take it. No one enjoys being criticized, but it’s an inevitability for all of us. Accepting constructive criticism is a character facet that goes a long way in the IT sphere like software development, where broad and deep knowledge is required. Accepting constructive criticism is key to growth for all employees and the internal processes inside the team and the whole company.

Useful links and how to push skill forward:

• Practice during 1-on-1 with the manager and team meetings based on techniques and information from useful links
• Speaker’s club, tech talks, etc. with feedback at the end of each speech
• Do some exercises with teammates using
• How to Deliver Constructive Feedback in Difficult Situations
• The 3 types of bullshit feedback — and what to do about them
• Exercise for improved feedback skills

Raise Concerns and Persuasion

Of course, you remember that we are always customer-centric and always listen to what the customers want. After all, we don’t close tickets — we solve customers' problems and make their work and life more accessible, especially when 95% of our customers are other engineering and operational support teams inside the company. However, in the pursuit of a customer-centric, don’t sometimes forget you, as technical specialists, must warn customers, product owners, and project managers about the potential consequences of a particular technical implementation. It is normal to express your concerns, beliefs, and possibly disagreement — this is improving the process of working out requirements, architecture, made it more thoughtful and detailed. And that’s not only about communication with customers — it’s also about tech discussions with other software engineers. You or your colleagues can know or see something that might prevent some difficulties in project realization in the future — so, tell about it. However, it is important to remember that fears and objections must be supported by facts, proofs, and evidence, and ideally by an alternative proposal.

Useful links and how to push skill forward:

• Always remember — the earlier the defect is found lesser is the cost of the defect. For our company, our project, for us, and our work.
• How to Deliver Constructive Feedback in Difficult Situations

Presentation and Explanation

As a software engineer, you will often need to talk with other team members while deciding on the merits and demerits of a coding approach. In the later stages of your career, you will have to guide your team towards a correct solution or provide solutions to customers. So, yes — you will need presentation skills whether you choose to convince via splashy and emotional presentations, well-written whitepapers, or with a series of diagrams just that it might not always be related to using PowerPoint slides. It can be a simple talk to communicate and explain some topics effectively to an audience. Be concise, be complete, be convincing!

Useful links and how to push skill forward:

• Take some courses and training such as Presentation Skills: Master Confident Presentations
• Ask help, feedback, and advice from experienced colleagues
• Make presentations demo of tools/apps/projects to internal customers, product owners, project managers the same way internal customers present it to external.
• Speak at internal meetups inside the team/company like tech talks, speaking clubs, etc
• Speeches in professional communities and at conferences
• Why you need presentation skills as a software engineer
• Tech Talks — You Do Have Something To Say!
• Presentation Skills Course: Master Confident Presentations

As Summary

A list of skills related to communications and proposed here is not a “silver bullet”. Of course, it can be changed depending on companies, projects, experience, knowledge about the process, etc. But one thing remains unchanged — soft skills and, in particular, communications are an integral part of a software engineer’s work, and they need to be developed every day. So, in the next part, we’ll analyze the time-management, planning, and getting things done approach…