Trying to do everything

I had an interaction on Twitter today which got me thinking – as Twitter discussions often do, because the amount of debate possible in 140-char limits leaves many things left over to think about. I think this blog post is mainly just to make the arguments that I couldn’t on Twitter. I’m not sure that’s a good enough reason but hey, it’s my blog.

The beginning of today’s conversation was this tweet I saw: “Dear developers: to have any sort of impact in this industry — managerial, or technical — you need to know how to people.”.

Now, in its defence, the tweet is true from at least two points of view. Firstly, the status quo argument: as things are, at present, you need to have influencing skills to get anywhere. That’s true, and it’s good advice if you want to get promotion. But it doesn’t really move us forward towards anything better: is that what we want the industry to look like? Is it the way to get the best results? Does it make us better developers, worse developers, or make no difference?

Secondly, of course it’s true that anyone needs a minimum level of people skills in order to – frankly – not be an arsehole to work with. Definitely. That’s a fairly low bar, admittedly, but some people still don’t reach it.

But in a broader sense, I think that it’s bad advice. Because it’s another example of trying to do everything.

Developers are supposed to have strong technical skills. They’re supposed to know how to code, how to test, how to architect, how to analyse a domain, how to work in a team, how to write good reusable APIs, and much more. They’re supposed to keep up to date with changing technologies, new languages, and changing businesses that use the technologies. They’re supposed to know databases, frameworks and build tools, all of which change constantly. And most importantly, they need to make good judgement calls on which of many different options is most likely to be robust, flexible and sustainable in an unpredictable future. This is a high-skill profession. It’s actually quite easy to learn a programming language and get coding, but to write good-quality enterprise software is hard.

All these skills can be learned, and are learned. Partly on the job, often in the developer’s own time, and continually. And yes, people skills can be learned too. But there are only 24 hours in a day, only 365 days in a year. The more skills a developer has to learn, the less expert they can become.

This sounds like a bit of a straw man – after all, asking developers to learn people skills isn’t a huge ask – maybe it takes 10% of their learning time. So they’re a bit less up-to-date, a bit less expert in some technology or other – will it really make a difference to the outcome of the project? Isn’t the benefit from the improved communication worth it? It seems like the answer should be yes. But…

The catch is this. Once we say that we expect developers to have people skills to sell their technical arguments – which is totally reasonable – we then structure the organisation so that the best presented argument wins. It is very easy to then say (in fact, hard not to say) that the developer who explains their idea best is the best technologist. They have impact and influence. The onus is no longer on anyone else in the organisation to understand the technical issues: the best solution is the one that non-experts understand, and the best technologist is the one who presented it.

If you promote based on ability to communicate ideas, you turn your organisation into a people skills competition1. Then the people who make technical decisions won’t be the ones who spent 10% of their time to learn people skills. They’ll be the ones who spent 90% of their time to learn people skills. And that’s not enough time left to spend learning the technology.

It would be great to have team members who can do everything, who have excellent technical skills and excellent people skills. Just like it would be great to deliver every project idea and great to include every feature. Sadly, that’s not how the world works. We have to choose: to prioritise and specialise. And if we say that the best-communicated argument wins, we prioritise people skills over technical ability and we will get bad software.

Which, I would argue, is pretty much the case now.

Footnotes
1 Caveat: people managers should absolutely be promoted based on people skills. But they should not have the final say on technical issues unless they also have very strong technical skills.

The Market Economy

I’ve received two letters recently, from two different institutions, telling me that they have “opportunities” to join their calling teams.

So someone somewhere has a paid job writing to me asking me to take a paid job calling other people asking them to donate money to an institution that I support.

This is distracting me slightly while I study economics which explains how in the ideal world where everything is a transaction, we will all get the best of all possible worlds.

But I’m sure that Doctor Pangloss would have approved.

Science and (Over-)Literalism

Okay, this blog post is just venting really, so I apologise in advance. Right, that was the nice bit out the way. Now… (cracks knuckles).

I’ve noticed a growing tendency from people who self-identify as ‘scientists’ or ‘pro-science’ (often, but not always, without any science training) to heap ridicule on anything they disagree with because it’s ‘unscientific’ or ‘disproven by science’. Particular themes are (i) diet/exercise advice is wrong, and (ii) religion is evil.

I’ll start with (i), and leave the religion thing for a future post. So, let’s start with an example.

Article: “Do these exercises to turn fat into muscle and get in shape”.

Commentator: “You can’t turn fat into muscle”.

Okay, commentator, here’s the thing.

  1. The person who wrote the article knows that you can’t turn fat into muscle. Because they’re not a fucking moron.
  2. The person who wrote the article assumes that their readers know that you can’t turn fat into muscle because they assume that their readers aren’t fucking morons.
  3. The person who wrote the article is using language non-literally in a rhetorical piece of writing. If you don’t understand that language can be used non-literally, you should never comment on anything anyone writes (or says) ever again. EVER. I mean it.

In this sort of article, the phrase “turn fat into muscle” is used as short-hand for “increase the percentage of muscle and decrease the percentage of fat in your body because you’re trying to get fitter / improve your body shape without necessarily wanting to lose loads of weight”. I’m sure you can see that the first phrase is shorter.

Here’s the second thing. Many articles written on diet and exercise aren’t articles targeted at science journals where precision and truth are key. Many are written to motivate people to get more healthy, and the persuasiveness of the piece is more important than getting the science exactly right. I don’t mean that the articles are untrue. But they’re trying to make someone get off their couch and do some sit-ups rather than trying to explain metabolic processes to them. They assume that the reader understands the science involved. But they don’t bother to spell it out to be sure.

Because here’s the thing. If, by some chance, a reader really is so stupid that they think fat turns directly into muscle, and follows the exercise advice in the article, they will still end up with more muscle and less fat. Even though they misunderstood the science. Wow! Mind-blowing, huh?

Yes, there are a few pieces of outright bullshit out there. (Raspberry ketones anyone?). But mostly when you pick on articles like this because they’re not exactly right, you’re not showing up the writer’s scientific ignorance, you’re showing up your own failure at basic comprehension.