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?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (31)
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.
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.
To (some) team members
To (some) higher ups
To my wife
Preach!
Eyes so glazed you could play a game of hockey on 'em
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" ~> 💯
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.
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.
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.
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.
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.
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.
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.
Was genuinely interested in reading the responses as this topic is undervalued in the software development. Thanks for creating the discussion! 👍😉
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:
I'm wondering why you did not extended an article like this .. I guess you know the trade well enough
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.
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.
Communicating what exactly you/they are talking about with a non-technical client 😅
That estimations are nearly impossible. They're fractal, not granular.
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
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.