Do call yourself a programmer, and other career advice

Blog<br>Site<br>𝕏<br>Feed

Do call yourself a programmer, and other career advice

July 12th, 2013

This is a (very late) reply to Patrick McKenzie's "Don't Call Yourself A Programmer, And Other Career<br>Advice". I find much of his advice very sensible, and it might be very helpful to someone in the beginning of their career –<br>assuming they can act upon it (and I really don't know whether my 20-year-old self could actually use the advice to improve his<br>negotiation skills, for example).

A few things in the article I disagree with, however. Here I'll mostly focus on those few things, recommending you to read<br>the original article so that you don't miss the rest of it.

"Disagree" is not necessarily the right word – a more precise way to put it would be "it's different in my experience". Which<br>is to be expected because both of us are speaking based on our own careers, which have been rather different. Patrick McKenzie<br>is a small business owner running Bingo Card Creator and a successful consultant.<br>I'm a lead chip architect at a billion-dollar company. Both of us have thus traveled some distance away from "purely<br>programming" (whatever that means), but in rather different directions.

What company are you going to work for?

Patrick McKenzie says 90% of the jobs involve things like implementing an internal travel expense reporting form, rather than<br>a product shipped to external customers. He advises you to get used to the idea, even though such software is "soul-crushingly<br>boring" as he puts it.

How bad is it, and is it really 90% of the jobs? Spolsky thinks it's maybe 80% – and that it's bad enough to "drain the<br>life out of you". He goes on to elaborate why it "sucks to be an in-house programmer":

There's rarely a business reason to improve in-house software past the point of "barely good enough". "Forget any pride of<br>craftsmanship – you're going to churn out embarrassing junk".

At software companies, what you do is more directly related to the way the company makes money, so you're more likely to be<br>respected. "A programmer is never going to rise to become CEO of Viacom, but you might well rise to become CEO of a tech<br>company." "...no matter how critical it was for Viacom to get this internet thing right, when it came time to assign people to<br>desks, the in-house programmers were stuck with 3 people per cubicle in a dark part of the office".

Note that McKenzie and Spolsky are in almost complete agreement over these points. But then Spolsky says you should be<br>gunning for a position in a software company – the environment where creatures of your kind naturally thrive. Conversely,<br>McKenzie explains how to prosper as a programmer outside software companies – moving in the opposite direction of where<br>things go by default (being stuck in a dark part of the office while they're trying to outsource your job.)

So the question is which path you prefer. "Not so fast", you say: one of these jobs is way easier to land – 80-90% of the<br>chances are you're not getting inside a software company – so it's not just a question of preference.

Here I disagree: even if only 10-20% of programmers work in software companies (where are the stats?..), and even if they're<br>"the best" (according to what metric?), McKenzie himself says in that same article:

You radically overestimate the average skill of the competition because of the crowd you hang around with:  Many people<br>already successfully employed as senior engineers cannot actually implement FizzBuzz.

But if competition is relatively unskilled on average, you probably can land a job in the 10-20% of the sector that you want<br>– as did most people who graduated around the time I did. So I rather firmly believe that it's a matter of choice: do you<br>want to work on in-house software or one-off businessy projects of that kind, or do you prefer a software company?

Let's proceed to McKenzie's advice to in-house programmers – which should in itself help one make that choice.

How to call yourself

One such advice is:

Don't call yourself a programmer. “Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some<br>other mumbo-jumbo.” Instead, describe yourself by what you have accomplished for previous employers vis-a-vis increasing<br>revenues or reducing costs.

Sure – an in-house programmer is likely doing some type of expensive mumbo-jumbo in the eyes of his non-technical<br>MBA-wielding manager.

To me, however, a programmer is who I'm looking for, while a resume full of revenue increases and cost reductions sounds like<br>an "anomalously high-cost parasite who types some mumbo-jumbo into Excel and PowerPoint, claiming credit for others' work".

McKenzie says a software company looks at this just like a company hiring internal programmers, essentially. His example is<br>"the guy who wrote the backend billing code that 97% of Google’s revenue passes through – he’s now an angel investor". The guy<br>apparently got rich by...