[crdoconnor]

It's a sad state of affairs if you consider it "idealized" to be able to focus on your job and rely on others to do theirs.

Yes, in the real world you sometimes have to work with poor product managers who have little empathy with customers, who deliver unclear specs and vague priorities. That doesn't mean a good developer is somebody who can handle the parts of their job that they failed at.

"Communicating clearly" is important, but when developers fail, they usually fail at writing clear, functioning code, not explaining why they did something to others in a conference room.

[watwut]

A developer may also fail in communicating how much time will something take, explaining clearly to pm why is feature harder to implement or not feasible due to existing architecture. A developer may fail at asking questions clearly - so the pm don't even know what info is missing. He may be unable to explain why more time for refactoring is needed or why change of technology is needed.

It is not possible to write specs completely without ambiguity - just like no one writes code without bugs. A developer who can ask questions to customer with empathy is more valuable then the one who plays telephone and needs interpreter.

What you are describing is junior work - juniors are closely supervised and fed every detail.

[crdoconnor]

>A developer may also fail in communicating how much time will something take

Estimation is not a communication skill.

>explaining clearly to pm why is feature harder to implement

A PM is probably not interested and does not need to know why they just need to know that it is hard to implement. I've typically done that by assigning a number (1, 3, 5, etc.) to a story indicating its difficulty.

If your communication problems extend to not being able to state numbers then you do not have a lack of soft skills, you have crippling brain damage.

>He may be unable to explain why more time for refactoring

Developers usually don't have to explain to other developers why more time is needed for refactoring, showing them the code in need of a refactor is usually enough.

PMs may ask why but they don't need to why and they probably don't care why anyway.

>It is not possible to write specs completely without ambiguity - just like no one writes code without bugs.

And? Going over to the PM and asking them to clarify a few details isn't exactly the hardest part of a developer's job. Average levels of communication skills suffice. It only becomes challenging when the PM writes horrendously ambiguous specs.

[watwut]

People with bad communication skills often think they are communicating big estimate, while no one else in the room got it from what they said. It happens. Or they refuse to hear when someone suggests easier solution or change of requirements so that it can be done faster.

Nope, showing the code is not enough to explain to other developers, unless we are talking about something extremely clear, simple and small. And yep, developers tend to have different opinions about what is important. The expectation that they will automatically share your concerns is pretty much how developers with lower social skills fail - and why lack of it slows everyone down. (And then they complain about everyone being stupid while the issue is they did not expressed themselves clearly and did not listened to contraarguments).

And PM IS interested, good one that is. It helps him to argue to customers/his bosses/other departments. It helps him to trust you. It helps him to distinguish between something that can wait and something that need to be done soon (you had him doing all prioritization and you claimed developer does not need such skill). Software estimates are wrong often enough that good PM won't take them as granted. At minimum she needs a sense of risks. It helps him to change the spec so that new one is doable faster.

Have you even consider entry that PM can react to reasons why something take long by changing spec, changing priorities, negotiating more or finding someone more experienced I that are to help you? Good pm do all the above. Which is why they can achieve more if people under them cooperate.

On your last point - given that developers with bad communication skills ask badly phrased questions or don't ask anything at all (just generically complain about bad analysis and insult pm - true story), yep it matters.

You jumped from "bad social skills" to "average" there. The two are not nearly the same thing.

[crdoconnor]

>People with bad communication skills often think they are communicating big estimate, while no one else in the room got it from what they said.

I've literally never had this happen once during a planning meeting.

>Nope, showing the code is not enough to explain to other developers

It's always worked for me. I can read code, grasp the structure and spot code smells with a glance. If it's really bad I'll be able to tell.

Usually I will just trust the people I work with if they say "it's bad" though.

>And PM IS interested, good one that is.

Good PMs learn to stay out of technical issues and trust their developers just as good developers learn not to second guess their PMs.

>Have you even consider entry that PM can react to reasons why something take long

Uh, was that English?

>On your last point - given that developers with bad communication skills ask badly phrased questions or don't ask anything at all (just generically complain about bad analysis and insult pm - true story), yep it matters.

As I said before I've worked with several developers who rarely ask questions and just do the work (and do it well). All stellar developers and highly underrated.

>You jumped from "bad social skills" to "average" there.

We were always arguing about whether it was a priority for developers to have especially good (or even above average) soft skills, not whether it was ok to work with developers with cripplingly bad communication problems.

[tbrownaw]

It's a sad state of affairs if you consider it "idealized" to be able to focus on your job and rely on others to do theirs.

It's a Platonic ideal of specialization, and in no way an ideal environment for actual humans. IRL, I wouldn't want to always be told precisely which task I should be on at every moment.