Hacker News Reader

Comment by tootie | Hacker News Reader

Nah, the article is right. I see a lot of really smart devs who just write great code that nobody wants. 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. I've had to tell really smart engineers to straight up delete code they wrote because it's not what we want to show to users. Some of the best EQ/communicative developers are the ones that work collaboratively and frequently come up with trivial solutions by asking the right questions. Really, the best orgs have a mix of both or, ideally, individuals who can do both.

View on HN

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

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

> 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?

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

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.

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.

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

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.

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

Reply on news.ycombinator.com