5 ms·

> So many companies hire solely on technical aptitude, then design the role of the engineer as an implementer of others’ ideas. Stripe (and specifically the Atl

> So many companies hire solely on technical aptitude, then design the role of the engineer as an implementer of others’ ideas. Stripe (and specifically the Atlas team) biases hiring much more strongly on aspirations, track record, taste, and potential. The team is filled with enthusiastic, energetic, fantastic communicators who are motivated to deliver ideal user experiences. In the right environment, people with these skills are able to produce a better product and build a better team culture than a dull, code-focused, command-and-control kind of environment. I really really hate this idea that the most important skill about an engineer is being a good communicator. I know why people say that, but honestly, 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. It's strange, but people who's job is to mainly write code also should be mainly good at writing code. In fact, people who are good at communicating tend to turn everything into discussions, debates, meetings and do very little actual work. Software developers don't need to be good communicators. They stare at a screen and need to be good at being content by solving problems by writing code. If they get happiness from that and they are fast learners then they will be good developers. Managers need to be good communicators. Team leaders who need to explain concepts to juniors or discuss architecture with others need to be good communicators, but not your regular junior/mid/senior developers. If a software engineer is a good communicator they will quickly be put into a role which will make them something that is not a software engineer anymore, so it's arguably a skill that is important for other roles and not coding. EDIT: Lots of people here trying to berate me on effectively what boils down to being a normal person and describing it as a "good communicator". Sure I agree with that, you have to have some basic humans skills, being able to read things, understand basic shit and being able to speak to other people like every other normal person who functions in society. I personally don't call that a "good" communicator. Just a person. Just like I don't automatically assume that if someone is not a good/great communicator that they automatically are poor communicators. By the same measure that everyone berates me here we are all good athletes if we can run 10 metres or kick a ball down the hill. Personally I set the bar slightly higher than just being normal when I describe as something to be good or great but perhaps that is just me.

tootie 4y ago
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.
- dustedcodes 4y ago
  > 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.

tootie 4y ago

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.

dustedcodes 4y ago
> 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.