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.

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

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

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

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

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

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.

This is a good example of what the author calls a code-focused attitude. I'm not going to judge anyone for wanting to work that way, but there's a lot of roles where it's just not very useful.

Stripe Atlas, to take the author's example, is in the fundamentally communication-based business of helping new companies legally incorporate. The vast majority of their technical challenges are going to sound less like "how do we write code that does X" and more like "should the code do X or Y"? So people who see only the former as "actual work" are going to have a hard time producing any value.

An ability to communicate is the bare minimum to be effective in almost all jobs. A team of mediocre anythings who communicate effectively will achieve more than a team of exceptional anythings who communicate poorly.

The way you’re characterising communication shows that you’ve been unfortunate enough to work in environments where volume of communication has been mistaken for a measure of quality. Good communication is characterised by the ability to share in the understanding of others, effective communication makes a group of people more than the sum of their parts. Effective communication leads to less communication.

I hope someday you’re fortunate enough to find yourself in a positive environment that is able to demonstrate all of this to you, because effective communication will improve your output more than any programming experience ever could.

> will achieve more than a team of exceptional anythings who communicate poorly

Not being a good communicator doesn't make you a poor communicator. My point is that you don't have to be a good communicator, I never said you can be a poor communicator. Just being normal, not poor or good at communication, but just being normally capable of speaking and good at coding is better than being a great communicator with average coding skills.

It depends. If you are on a team with full support, designers, product management, project management, etc., then sure.

But as soon as you lose one of those engineers (e.g., internal tools teams often pick up those tasks and so to build the right thing requires better than average communication skills.

The median communicator is a very poor communicator most of the time. Communication takes active focus and effort and the default is zoning out or making assumptions about what the other is saying.

> [...] just being normally capable of speaking [...]

I think you may be confusing a medium (speaking) with communication itself. Successful communication is as much about the choice of medium as it is what you're communicating. Communication is the method through which we extract thoughts from our own brain and share them. Code is a form of communication! You can be a fantastic speaker and a terrible communicator, likewise you can be a terrible speaker and a fantastic communicator. The right environment for you is an environment in which you're able to choose to communicate in the medium that has the best outcomes.

For example, spoken communication is my weakest form of communication and yet it has not hindered me at all, in fact, I am considered an excellent communicator by the people I work with. Sometimes, you have[1] to use a method of communication that you're not confident with, so you can develop strategies to help you communicate more effectively in that situation. When I'm speaking, I take notes in advance to flesh out my thoughts, and if I find myself struggling during a conversation, I'm honest about it and recommend next steps -- e.g: "I'm not sure about that off the top of my head, so after this call I will put together some thoughts and get back to you by the end of the day".

The people you work with benefit most when you succeed :) You're clearly a very capable communicator based on your comments here, you don't need to argue against the fundamental importance of communication, rather, you need to find an environment where you're encourage and rewarded for embracing the communication methods that work best for you.

I couldn't have spoken this comment out loud and that has zero impact on my communication ability.

[1] Dyslexia is a common example of this that I've encountered. If a colleague prefers listening to reading due to dyslexia, I will choose to speak with them because even though I'm bad at it that is the most effective means of communicating with them.

The job of a software engineer at Stripe is not solely code. The job is to deliver business value, and that requires communicating with others across and outside of the organization. I’ve been at Stripe for over five years. I would not have lasted five months if I just sat at my desk and coded all day.

Engineers at Stripe wear many hats, depending on the project. My best example is Paper Checks. I’ve been an engineer, project manager, sales support, designer, support personnel, docs writer, and even visited lockbox facilities. I learned and did a lot on the project, and loved it. None of that happens if engineers just sit and code. We don’t get all the information about the flow of data and paper, and we build a poor product.

The same goes for internal projects. I was a DRI for a complex rewrite of our system. I regularly worked with six other teams to ship that project. That project doesn’t happen without communication.

Thanks for adding these points :)

If you are not a good communicator, you will build the wrong thing. You will not fully understand what matters in what you building or be building something that is a lower priority. If you are still a good listener, which is 80+% of the way to being a good communicator, you will end up being the right thing but you effort will not be used to their full extent. People will now know about the improvements or align with what you are doing.

Exactly. Communication is both sending and receiving. And receiving it the more important part.

I'm sorry, but you are not being "berate[d]". Your take was bad and it is being constructively criticized.

A senior engineer should be making an impact outside of their own team and to do that you need to be an effecitve communicator.

> being a good communicator is the _last_ thing that makes a good engineer. The best software engineers are good at - I know this comes by a huge surprise - writing code

Surely you're not measuring how good the engineer is based on number of lines of code he produces per day.

If LOC is not the metric, what is the difference between 1000 LOC written by good engineer vs 1000 LOC written by bad engineer?

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

Agree completely. People want to work in a way they are good at so if you hire good communicators you will get a lot of communication. If you want to ship a lot of products hire people who are good at building products.

It seems people misinterpret you as saying you don’t need any communication skill which is clearly not what you meant.