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
Latest comments (31)
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...
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.
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.
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
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!
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.
In my anecdotal experience, convincing CS grads of the need for semantic and accessible HTML is usually an uphill battle.
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.
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.