DEV Community

Cover image for What are the toughest communication challenges in software development?
Ben Halpern
Ben Halpern

Posted on

What are the toughest communication challenges in software development?

The job would be a lot different if it were just you and the code. In your experience, what parts of the communication challenge are particularly tough in software?

Top comments (31)

valeriavg profile image

Ego vs effectivity by far is the toughest part for me.
Take a code review for instance, how does one criticize other's work without crushing their motivation? Choice of words in some cases will be more important than the message it conveys.

And the other way around: I need to keep in check that whenever I propose an alternative solution or drive a change it comes from purely technical perspective, not my own bias or personal goals.

grocker42 profile image

Do you can talk openly with other people about how they want to be critise , with out they take it personally? I think this is not easy. Just because you know some one dont want to be mean, is not enough that you dont take it personally. its just the human Nature.

ziker22 profile image

To (some) team members

  • Do things properly (no lets fix it later attitude unless we have VERY good reason)
  • Tests will make our sleep more peaceful
  • The domain knowledge is key
  • Do not write code solve problems

To (some) higher ups

  • You really cannot replace anyone (ot least not for free)
  • Senior devs dont give a f about free pizza & beer
  • Tech debt will kick us in the butt if we ignore it
  • It sucks working in Headless chicken mode we need a solid plan that doesnt change every 3 months

To my wife

  • What i esentially do all day :)
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

Senior devs dont give a f about free pizza & beer


To my wife

Eyes so glazed you could play a game of hockey on 'em

brenodamata profile image
Breno da Mata

I will definitely quote this line: "It sucks working in Headless chicken mode we need a solid plan that doesn't change every 3 months" ~> ๐Ÿ’ฏ

dinerdas profile image
Diner Das

Deciding when it is possible to move on from a thing vs endlessly maintaining it โ€” and generally communicating around and planning for ongoing maintenance. It seems like if you over-index on this factor, nothing gets done, but if you ignore it โ€” your problems are much worse.

cerchie profile image
Lucia Cerchie

Yes this! If you decide against too many things because of the maintenance load, you lose functionality, but you'll lose it in the other direction if you just say yes to all the new dependencies, projects, etc.

conw_y profile image

Coming up with clear language to describe things that you rapidly discover are more complex than you had initially thought. Distinguishing intent from implementation detail. Describing complex, interdependent processes occurring within a software system. Describing logic that includes many "not necessarily" relations.

curiousdev profile image

What I can think of is Knowledge Sharing. This is important to avoid knowledge being lost or not being available in case somebody of the team is missing, but it also can take a lot of time and effort.
Examples are Code Reviews and documentation.
Just imagine everybody only working on their own components and then you expect somebody else to be able to implement or fix something.
Also if you begin to share experience etc. very late, it just gets worse.

ryotabs profile image

More on the junior side, but learning when and how to ask for help. I was at an internship where a new developer was very quiet. When a few of us asked him if he needed any help, he always told us that he was okay. However, a few months later, my boss asked me to keep an eye on him and just keep touching base, as he hadn't picked up any tickets on our Jira board since he started.

I think a lot of it is the fear of looking stupid, or having your peers perceive you as stupid. Unfortunately throughout my time in school, I've definitely run into people who weren't the most welcoming, and had the "if you don't understand it then what the heck are you doing here" mentality. I also think the exposure to communities like /r/cscareerquestions and Blind contributes to this fear, as the demographic makes you feel like your worth is tied to how good you are as a developer, and your TC.

theaccordance profile image
Joe Mainwaring

Requirements gathering. Either itโ€™s straight forward and simple to translate into what an engineer needs to accomplish, or itโ€™s complex and likely leaving out an unknown path that wonโ€™t be revealed until QA testing or in production.

lucidpolygon profile image

There is also the situation where the client says something simple. It remains simple during discussions as well and finally, when we get into development, it suddenly becomes a complicated thing requiring x number of extra hours to accomplish.

madza profile image

Was genuinely interested in reading the responses as this topic is undervalued in the software development. Thanks for creating the discussion! ๐Ÿ‘๐Ÿ˜‰

sherrydays profile image
Sherry Day

Effective use of async vs synchronous communication. If either starts to show problems, we tend to go way in the other direction. Understanding the value of both and using them effectively is key.

karmavil profile image
Federico Gallo • Edited

No. It's more simple than that. Do you see that big cream picture with a telephone on it?
Sometimes the communication channel chosen by your client is simply a bad choice and everything becomes stress.
But that does not apply just to clients. It happens all the time:

  • friends, we've all experienced having to set up a group preferences because of too much activity.
  • business, they want to be in touch so they decide to put bots everywhere and FAQ pages sometimes making difficult to reach them when something need personal attention.
  • study platforms, lack of activity in chat rooms and not good support for smartphones.
  • communities, multiple communication channels and they're not fully compatible between each other.

I'm wondering why you did not extended an article like this .. I guess you know the trade well enough

lucidpolygon profile image
lucidpolygon • Edited

Feature creeping would be the toughest for me. While working with individuals and SME's as a freelancer, I am always watching out to prevent feature creeping. It creates a whole lot of mess and misunderstanding. An interesting project soon becomes a problem to deal with.

terabytetiger profile image
Tyler V. (he/him)

Communicating what exactly you/they are talking about with a non-technical client ๐Ÿ˜…

moopet profile image
Ben Sinclair

That estimations are nearly impossible. They're fractal, not granular.

cricketsamya profile image

Non Technical PO is sometimes hard for a developer to communicate with. As I mostly worked with Backend systems, which was setup few years ago. I know the whole system by heart, but a non technical PO sometimes makes it harder for outside world to understand what BE does.

The decisions made during this time, with less technical knowledge makes life difficult!

mfurmaniuk profile image

Plenty of what I would say about documentation and such is already here, but the worst conversation I have had is about that member of the Team not pulling their weight. It's hard to have conversations like that unless you already have the soft skills, or experience in getting into personal issues and uncomfortable situations.