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?

Discussion (31)

Collapse
valeriavg profile image
Valeria

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.

Collapse
grocker42 profile image
Grocker

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.

Collapse
ziker22 profile image
Zikitel22

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 :)
Collapse
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

Senior devs dont give a f about free pizza & beer

Preach!

To my wife

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

Collapse
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" ~> ๐Ÿ’ฏ

Collapse
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.

Collapse
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.

Collapse
conw_y profile image
Jonathan

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.

Collapse
madza profile image
Madza

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

Collapse
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.

Collapse
lucidpolygon profile image
lucidpolygon

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.

Collapse
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.

Collapse
curiousdev profile image
CuriousDev

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.

Collapse
ryotabs profile image
ryotabs

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.

Collapse
karmavil profile image
Federico Gallo • Edited on

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

Collapse
terabytetiger profile image
Tyler V. (he/him)

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

Collapse
lucidpolygon profile image
lucidpolygon • Edited on

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.

Collapse
moopet profile image
Ben Sinclair

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

Collapse
jasterix profile image
Jasterix

Such a good question! I would the most difficult aspect is intention vs sincerity vs grace. A person should approach a conflict with approach the conversation with good intentions, it will be easier for them to hear the other person

Collapse
kspeakman profile image
Kasey Speakman

Including subtext from your other recent questions, the toughest part tends to be that departments and teams tend to focus inward rather than being cooperative. And it's not totally their fault, since execs tend to set this tone with their behavior.

Collapse
cricketsamya profile image
Sameer

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!

Collapse
mfurmaniuk profile image
Michael

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.

Collapse
fzn0x profile image
Muhammad Fauzan

Task Priority. It's much challenging, because in my experience, we need the task to get done as fast as possible to get announced by marketing team, also we must sync with the marketing team deadline.

Collapse
booboboston profile image
Bobo Brussels

Abstractions โ€” without great principled alignment, it's really hard to get on the same page on how abstractly a problem should be solved.

Collapse
alanmbarr profile image
Alan Barr

Creating an inspiring vision, writing and communicating design docs that encourage collaboration, and finding the right balance of your time between execution and strategy to tweak your plans.

Collapse
canro91 profile image
Cesar Aguirre

Code reviews I would say...giving clear, non-judgemental, on-time comments

Collapse
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

In my anecdotal experience, convincing CS grads of the need for semantic and accessible HTML is usually an uphill battle.

Collapse
perplexedyawdie profile image
Javel Rowe

Ensuring that we all mean the same thing when we use a particular phrase/word or jargon. I've realized how easy it is to think that we're on the same page when we're not even in the same book!

Collapse
cess11 profile image
PNS11

That'd be in organisations governed by the Peter principle.

Collapse
jeel profile image
JP

As per the book "Mythical man-month"

Brooks's Law (simplified):
Adding manpower to a late software project makes it later.

And guess the reason...

Collapse
jenc profile image
jen chan

Lately I've been finding it hard to ask questions that reveal and guide those to solve their own problems and find gaps in their mental model instead of just giving them the answer.