Anti-technical bias

31 December 2018

I wrote a slightly ranty thread on Twitter earlier, and I realised at the end it was really more of a blog post, so here you go. It’s roughly based on this frustration I’ve had a lot when interviewing guitar players as a writer - so many guitarists who’ve never bothered to learn how to shred will dismiss playing fast as masturbatory, as un-melodic, or even as unskilled. Now, I’m not of the view that you can’t have any opinions about a thing unless you’re an expert in it, but it’s generally not a good idea to listen to closely to people who dismiss a thing out of hand without fully understanding it or putting the leg-work in to at least try.

This comparison has come up a lot in my head for discussing functional programming, and especially Haskell. Lots of folk are very happy to dismiss Haskell out of hand as useless, incomprehensible, impractical, or even just hand-wavingly ‘bad’. When you dig deeper, you find that in many cases not only have people not tried to build something with it, but worse they’ve not even engaged with the ideas behind it, tried to understand it, or in some cases even written a ‘hello world’ program in it.

It seems to me that the common thread here is actually the insecurity of the commenter. If you don’t have the time or inclination to look into Haskell - that’s cool, just say so. Similarly, if you don’t feel like you need to learn to shred, then say it in those terms, don’t trash it just because it’s not for you. Own your decision and be honest, because believe me, an experienced interviewer like me can generally smell that little sleight of hand a mile off.

Anyway, Haskell and shredding are two things that take a lot of time up-front, and then have a long tail of additional learning. What surprises me is how often I see folks in tech circles just hand-wavingly dismissing ‘coding’ or ‘tech’ or ‘programming’ skills across the board, in a sweeping fashion.

Now I’m not saying that this is bad faith, or that the tweeter is a bad person, but it’s definitely a Bad Take. For the average engineer, and especially the ‘rookie’ - or junior - folks who are still early on in their apprenticeship journey, I think the absolute opposite is true, and that this actually comes off as dismissive and condescending.

Anyway, I’m not looking to single one person out - that’s just the most recent tweet I’ve seen that’s of this genre. I’m sure you can find tonnes like it on Twitter.

So, here’s the jump-off tweet for my reply thread:

Here’s the text:

Seen another raft of tweets about how it’s a ‘rookie mistake’ to focus on programming ability. Okay - communicating is important, and it’s what separates good from great… in a large team or corporate environment.

In a smaller team, being able to independently make decent (all decisions are wrong in the long run) decisions and ship good code is by far the most important thing. In addition, when you’re still training, you need to focus on something.

Focussing on code is a smart bet, because you can only learn strong technical skills in an environment where you have the right people to learn from, to ask questions etc - if you get it right early on, you’ll develop intuition about the craft faster than your peers.

…and that’s cumulative, obviously. A few years spent absolutely grilling the hard stuff will be worth 8 years or whatever milling about and spreading yourself widely across code, communications, leadership, whatever. Focus is a strong pattern in apprenticeships.

We’re always learning, too. So being able to focus on one thing and bring it up to scratch means you will have a method for pivoting and learning more about communication, stakeholder mgmt, leadership, or what have you. But first - you need to focus single-mindedly on the tech.

Besides all of this - which is more about focus, and putting programming chops in context for your career, for every collaborative project (docker, serverless etc) there’s a lone wolf piece of work (git, linux, clojure) where tech skill was the only thing that mattered on day 1.

…and it’s only later that all of the associated skills like communication, leadership, community mgmt etc become relevant, and it’s then that smart people seek help, or build skills in other areas.

Anyway, that’s enough ranting. I’m just so so so so so very bored of people who habitually sneer at programmers focussing on the tech side of their job. It reeks of anti-intellectualism and insecurity and it’s dull.

I’ve spent most of a decade interviewing guitarists who say “shred is boring” but never learned how. Just admit you prefer a way of doing things, and can the insecurity. Own your decision and explain why. I think all the aspects are important but you need a strong foundation.

Fork me on GitHub