5 ms·

> They just disappear and go quiet for a week and then deliver some solution that was not specified by the product team because they think it's better. That ha

> They just disappear and go quiet for a week and then deliver some solution that was not specified by the product team because they think it's better. That has nothing to do with communication but either with an inability to read and understand the specification which is an issue with intelligence or they have an attitude problem thinking they know everything best. None of this can be fixed by them being a good communicator, you will have the same just with a lot of extra debate. The best engineers disappear for 1-2 days in quiet and then deliver exactly what you needed, do a bit of review/refinement with 1 or 2 other team members to tidy things up and polish the quality and then they'll pick up the next task and disappear again for a day.

haspok 4y ago
> read and understand the specification The what? Sorry? If you had the specification you could just give it to the latest ChatGPT et al and it would create 90% of the code for you (just kidding, but kinda not). No, the most important task of a software engineer is to help gathering requirements, understanding them and then translating them to code, considering internal and external constraints. Actual coding is usually the smallest part of this process. Communication may not be THE most important, but it certainly is important.
DoughnutHole 4y ago
> The best engineers disappear for 1-2 days in quiet and then deliver exactly what you needed Communication is hard, and what someone communicates what they want is very rarely exactly what they actually want (or need). Sure, sometimes the stars align and you have perfect communication of exactly the needed specification and a dev who can perfectly translate that to code. But in most real world conditions you need good communication skills at both ends. Language is full of ambiguities, and it's possible to have a perfectly reasonable interpretation of something that is totally wrong. I've worked with plenty of competent people who have had plenty of bad ideas. If I wasn't competent at communicating my issues with these ideas I would have spent many more weeks of my life on unnecessary or poorly thought out features.
TremendousJudge 4y ago
> an inability to read and understand the specification I'd say that being able to read and understand what others want is part being a "good communicator", alongisde understanding reviews and comments from other devs and addressing those. Also, good code is good at communicating what it does to future readers, via comments, variable names, and structure. And if you do that, you're being a good communicator.
- dustedcodes 4y ago
  If just being a normal human being who can read and understand normal stuff makes you immediately a "good communicator" then I also agree that being a "good communicator" is important for any job really. I personally think of someone as being a good communicator as somethign more than just normal basic humans skills and abilities to function around other people. I mean by that measure we are all good athletes if you can run 10 metres or kick a ball down the hill.
  - sdm 4y ago
    Communication is both sending and receiving. If you are only good at sending, you're not a good communicator. You have to be able to listen, both to what is said/written and what is not to be a good communicator. It's not a common skill with most engineers.
zamnos 4y ago
> That has nothing to do with communication but either with an inability to read and understand the specification I must have a different definition for the word "communication" than you. If person A writes a spec, and then person B reads the spec, isn't person A communicating with person B about the specifications? If persons C D and E also read the spec and only person B doesn't get it, wouldn't you say person B has a communication problem?
kenmorechalfant 4y ago
> inability to read and understand > or they have an attitude problem These just sound communication problems. Every failure to understand is also a failure of the explainer.
volkk 4y ago
out of curiosity, how many YOE do you have? a lot of the stuff you've written reads like exactly how i felt 2-3 years into my job and thought everything was bs except the code. "screw sales, what do they even do, code is all that matters", "screw PMs, their jobs is just spreadsheets and docs, code is all that matters" i'm over a decade in at this point and couldn't disagree more with all of your points. nothing makes me want to run away faster than dealing with some genius who "disappears" or argues around a ton of things/has no EQ.

haspok 4y ago

> read and understand the specification The what? Sorry? If you had the specification you could just give it to the latest ChatGPT et al and it would create 90% of the code for you (just kidding, but kinda not). No, the most important task of a software engineer is to help gathering requirements, understanding them and then translating them to code, considering internal and external constraints. Actual coding is usually the smallest part of this process. Communication may not be THE most important, but it certainly is important.

DoughnutHole 4y ago

> The best engineers disappear for 1-2 days in quiet and then deliver exactly what you needed Communication is hard, and what someone communicates what they want is very rarely exactly what they actually want (or need). Sure, sometimes the stars align and you have perfect communication of exactly the needed specification and a dev who can perfectly translate that to code. But in most real world conditions you need good communication skills at both ends. Language is full of ambiguities, and it's possible to have a perfectly reasonable interpretation of something that is totally wrong. I've worked with plenty of competent people who have had plenty of bad ideas. If I wasn't competent at communicating my issues with these ideas I would have spent many more weeks of my life on unnecessary or poorly thought out features.

TremendousJudge 4y ago

> an inability to read and understand the specification I'd say that being able to read and understand what others want is part being a "good communicator", alongisde understanding reviews and comments from other devs and addressing those. Also, good code is good at communicating what it does to future readers, via comments, variable names, and structure. And if you do that, you're being a good communicator.

dustedcodes 4y ago
If just being a normal human being who can read and understand normal stuff makes you immediately a "good communicator" then I also agree that being a "good communicator" is important for any job really. I personally think of someone as being a good communicator as somethign more than just normal basic humans skills and abilities to function around other people. I mean by that measure we are all good athletes if you can run 10 metres or kick a ball down the hill.
- sdm 4y ago
  Communication is both sending and receiving. If you are only good at sending, you're not a good communicator. You have to be able to listen, both to what is said/written and what is not to be a good communicator. It's not a common skill with most engineers.

zamnos 4y ago

> That has nothing to do with communication but either with an inability to read and understand the specification I must have a different definition for the word "communication" than you. If person A writes a spec, and then person B reads the spec, isn't person A communicating with person B about the specifications? If persons C D and E also read the spec and only person B doesn't get it, wouldn't you say person B has a communication problem?

kenmorechalfant 4y ago

> inability to read and understand > or they have an attitude problem These just sound communication problems. Every failure to understand is also a failure of the explainer.

volkk 4y ago

out of curiosity, how many YOE do you have? a lot of the stuff you've written reads like exactly how i felt 2-3 years into my job and thought everything was bs except the code. "screw sales, what do they even do, code is all that matters", "screw PMs, their jobs is just spreadsheets and docs, code is all that matters" i'm over a decade in at this point and couldn't disagree more with all of your points. nothing makes me want to run away faster than dealing with some genius who "disappears" or argues around a ton of things/has no EQ.