Communication and problem solving in software development

Let's discuss this

This may sound counter-intuitive, but communication is hands-down the most important skill for your job as a developer. It’s a vital skill for expressing ideas, thoughts and feelings, and building relationships. Good communication can bring out the best in every member of your software development team, help set clear expectations, and save everyone time and money— ultimately giving your team a huge competitive advantage.

Bad or passive communication can be toxic in a dev environment.


One person saying, “not my problem,” hiding their mistakes, or bringing a bad attitude to work can handicap the job at hand and bring the morale of the entire team down. By not taking the time to help your team or company do the job properly, you’re effectively helping your competitors.

“That’s not my job” or “I don’t own that”

In the software development world, perceived ownership of a product or process can cause folks to waste a gigantic amount of time. Have you ever needed help with something before, databases for example, and had someone give you the runaround?

“Look, our code just reads the database from a web service; we don’t own the database — maybe you should talk to the database team. Who is the database team? I have no freakin’ idea, because it’s not my problem. Good luck with that!”

I like to defuse these situations with a problem-solving process that I learned during my time at Intel.

Identify the problem.

I believe that the first and most important step in problem solving is to clearly identify what the problem is. Even if you don’t have enough knowledge to fix the problem, sometimes taking the time to help someone understand (and even document) the problem can be huge.

You’d be surprised how many times the problem is just a typo or simple user error— the person asking for help just needed a second set of eyes to realize that.

Get the facts.

If there actually is a problem, try to characterize it by collecting data or narrowing the problem down to a set of steps that anybody can use to reproduce the problem.

For example: Let’s say your web browser times out when hitting a particular URL. Does DNS resolve? If so, are you able to use telnet to open a connection to port 80 or 443? Does it work from a coworker’s machine? If all of those work and you have control over both sides, are you able to set up a packet capture between the source and destination? This is some great information to have.

Find the root cause.

Defining the problem and having data about your current situation — such as steps to reproduce — are key to solving the problem. You are essentially proving there is a problem and understanding where it lies.

If, as far as you can tell, your stuff isn’t causing the problem, reaching out to another person (or team) for help finding the root cause.

It’s extremely important that you can describe the problem in detail when you reach out for help, otherwise folks might think you’re trying to wash your hands of the issue by dumping it on them.

Having a process and then following that process is an important bridge to communication.

“I don’t have time for that”

The counter argument for taking time to understand other people’s problems, which is totally understandable, is that it’s going to eat up a lot of your time. Everyone is busy — we all have our own set of problems to solve. Why should you put your work on hold to help another person? You’ll definitely have to use your own judgement to answer that.

While it’s true that you can’t solve everyone’s problems, sometimes nudging people in the right direction can save them (and your team or company) a ton of time. Many people need help with communication, especially if they’re stressed out. If the problem is customer-facing, they’re likely feeling pressured and came to you because they thought you could help save their day.

Helping doesn’t always have to feel like you’re being nagged or it’s a chore.


Lots of times I’ll offer to help if someone buys me lunch. When the problem is solved, it’s fun enjoying a free meal over some conversation with your coworker. If you truly don’t have enough time to help yourself, refer them to someone who can.

Improve your day-to-day workflow

Take a minute and think about the number of folks you interact with at your job. There are product owners who are road-mapping future work for your team or department, creative teams that help with user experience or in-application assets, and of course, your fellow developers and their managers. That’s a lot of potential people who can be involved and communicating! It can be extremely easy to get lost in all the details, especially if communications are happening via meetings, emails, instant messages.

Let the right person make the call

So you’re working on a software development project and someone asks a question like, “When will this be ready for customers to use?” or “Will you be including a feature that does ____?”. At a smaller shop, you might very well be the best person to answer that. And realistically, you might already have a gut feel for the answer. But you need to defer those questions to the person who actually owns the answer to them.

The goal here is to only have one answer.

If everybody asks “When does X ship?” they all deserve to get the same answer. When people start guessing (instead of finding the right person to answer), it can snowball out of control and ruin estimates for other major projects.

If you’re feeling pressured to deliver and don’t think the date is realistic, sometimes reaching out to that decision owner can help; you can always negotiate features in order to hit a certain date, which can lighten the workload for your whole team or department (something you usually don’t have direct control over).

Make your communication as clear as possible

This might sound obvious, but a lot of people mess it up. When you’re talking with someone, make sure they understand what you’re talking about. If they’re able to repeat it in their own words, they likely have a good grip on it. The reverse is true, too. If you don’t understand, speak up.

It’s better to feel embarrassed for a minute by asking one more question than it is to roll the dice with an assumption and hope you’re not wrong — which will end up costing everyone time and money.

Keep stakeholders updated on priority items

If you make a discovery that roadblocks your project, you make a mistake along the way, or priorities change (impacting a date you promised someone, for example), let the folks affected know immediately. Everybody makes mistakes — they’ll likely be grateful you caught it now and not when the product went live (and customers are using it).

Set expectations

When you’re asking for help, set an expectation for the person helping you. Do you expect a resolution by the end of the day? Or are you OK with them documenting your issue in a Jira ticket, as long as they agree to look at it in the future?

If people don’t know what you expect from them, they won’t be compelled to find a resolution for you.

Sometimes, I think about what I’m going to say and then try to predict possible responses. If you know for sure the person will react negatively, you’re probably better off not saying it. But in regular situations, considering your audience’s perspective can really help you re-phrase what you were originally going to say. Will they remember what the context of what you’re talking about? Are you giving them enough information, or are they just going to turn around and ask more questions?

So what works for you? Are there practices, tips or tricks you have used to improve communication within your teams? Please share in the comments.

Image by: fabola via Compfight cc