Comment by mlthoughts2018 | Hacker News Reader

Comment by mlthoughts2018 | Hacker News Reader

Parent Full thread

All modern software jobs are mostly about explaining your solution to others (stakeholders, reviewers, senior/staff engineers, managers, executives).

If you can’t boil your work down into accessible presentations and adapt them for technical or non-technical audiences, you won’t get anywhere.

Nobody will agree to help you, allow your team to grow, give you budget for tools you need, make compromises with you around integration requirements or shared design patterns, unless you can frequently convert your software work into highly professional presentations.

I’d argue that competent presenting and writing skills are of equal, or even greater, importance than software skills or expert knowledge, whether for a research software job, software contractor job, SWE within tech / ecommerce / banking etc industries - across the board there are pretty much zero types of software engineering jobs in which software skills are actually the most important thing. Presenting and writing are frequently much more important.

> All modern software jobs are mostly about explaining your solution to others

This isn't true in my experience, there are plenty of well paid jobs where you don't have to talk to non-technical people. For example, lets say you are developing infrastructure at Google, how often do you think you talk to non-engineers? Never, everyone in your management chain will be engineers, your product managers are ex-engineers, your users are engineers etc. This is true for directors managing lots of people as well as well.

And even when you develop services much of it is just getting the technical parts right so you can work there as well at Google with very little time spent talking to non-technical people, so senior positions there are mostly about technical stuff.

You could argue that Google and other big companies are a special case, however if we exclude low paid jobs where you just earn half of what you'd do at Google or Facebook then pure technical work like this is a very significant fraction of the market. I'm not sure why I'd work on my presentations skills so I could get hired by a company paying me less.

> “ For example, lets say you are developing infrastructure at Google, how often do you think you talk to non-engineers?”

I can speak from experience since I help run the site reliability incident response team in my (large ecommerce) company.

How often do rank and file SRE ICs need to speak with non-technical staff about projects? All the time.

They give tech talks and council presentations, they contribute work to quarterly roadmap project pitches, and they give business scorecard presentations to walk higher level managers through the breakdown of costs and benefits, why we should pay money for a new cloud tool, what time & effort some org-wide planned migration or upgrade is going to require.

Let alone basic stuff like writing effective tickets / issues / RFCs / PR descriptions, postmortems, etc., and walking teammates through work artifacts daily.

For every two hours of software work, I’d expect 1 hour of “wider audience communication” work - and that is for deeply technical ICs in roles like SRE. The closer you get to product engineering, the more the ratio shifts towards communication.

I can tell you this translates specifically to Google & Facebook - because most of the SRE colleagues in my company came from Google & Facebook, and attest to that being the case there too.

I worked as a SWE at Google for several years on two different teams, I never talked about work with a non engineer, and one person I worked with talked to non engineers. SWE's outnumber SRE's by something like 10 to 1 at Google so my experience should be more common than the people you talked to.

Your described experience is so wildly different and long tail uncommon from the hundreds of other ex-Google SWE colleagues I’ve had over the years that we unfortunately just have to exclude it as extremely unrepresentative.

I agree with your description for senior devs, technical managers, and above. But in my experience there is no reason such a burden needs to be a core part of a mid-level team member's job description.

To be clear, explaining your work is a part of every developers job. But top notch presentation skills don't need to be a part of it. Developers can talk to other developers in sub-optimal ways that are still effective. But when your hiring process has an hour long presentation as a part of it, you are optimizing for the thing that is very likely not the most important feature of the role. The point is to structure your hiring process such that it optimizes for the right things for the role.

I've updated my initial post with a clarification since you're not the only one who came away with the impression this was an hour long presentation.

But also, I really really dislike when others talk about "optimizing" people. It's not possible to optimize your hiring process for anything useful. Due to this, there should be a lot more empathy in the hiring process than their actually is because everyone wants to make it robot-like by "optimizing" something.

Reply on news.ycombinator.com