What are some strategies for becoming an "X who programs"?
Ref: XWP, http://michaelochurch.wor
2 Answers
1. Go into Statistics/Data Science. This has been a popular field for a long time, and the ability to automate statistical reports is still extremely rare and valuable.
2. Go into data-driven marketing. Patrick McKenzie has tons on this, but the field is so ripe for Marketing/Programmer hybrids that they've even come up with a term for it: "Growth Hacker"
3. Go into any other field that involves moving around a lot of numbers, such as finance/accounting. Right now most people do most data transformation by hand, and there are tons of opportunities to automate it. If you can get paid $70k to move data around, and through scripts become 5 times as effective, you can easily justify a much higher salary.
Note: I have actually worked in each of these fields and had significant successes by automating a lot of what people did by hand. My programming skills are terrible-I barely know what an object is-but basic programming skills applied to a valuable problem are often more useful than advanced programming skills applied to a problem no one cares about (or a problem 50,000 others are working to solve).
2. Go into data-driven marketing. Patrick McKenzie has tons on this, but the field is so ripe for Marketing/Programmer hybrids that they've even come up with a term for it: "Growth Hacker"
3. Go into any other field that involves moving around a lot of numbers, such as finance/accounting. Right now most people do most data transformation by hand, and there are tons of opportunities to automate it. If you can get paid $70k to move data around, and through scripts become 5 times as effective, you can easily justify a much higher salary.
Note: I have actually worked in each of these fields and had significant successes by automating a lot of what people did by hand. My programming skills are terrible-I barely know what an object is-but basic programming skills applied to a valuable problem are often more useful than advanced programming skills applied to a problem no one cares about (or a problem 50,000 others are working to solve).
First, it's important to assess why having an X (as in X Who Programs) is so important. The problem with software engineering comes down to the fact are multiple stable equilibria in the status ranking of software engineers. Remember college, when you could get into flow and crank out 500 lines per night on your Support Vector Machine? Well, on most software teams, it works like this: one engineer (the "blazer") gets to be in flow and have fun and make architectural decisions and accomplish a lot, and the rest keep up with his changes, being downwind of the complexity, and split their time between (a) adapting to the blazer's changes, and (b) implementing trivial features he needs but doesn't have the time to write. The blazer keeps making cool stuff, and the other developers keep up and occasionally get a minor accomplishment that might amount to 20 lines of code.
The default is that you end up with one key player and N-1 support people, and whoever is the key player will very likely stay in that role, because there's no way for the others to outperform him. It doesn't always happen this way on a software team, but to have it otherwise usually requires intelligent forethought regarding division of labor.
The software industry is full of cycles whereby perception enables performance that strengthens the perception. For example, the only way to get good projects is to have worked on good projects. The truth is that performance is very hard to measure. The only people who can evaluate a programmer's performance is a much better programmer, whose time is so valuable that it's almost never put to that purpose. Perversely, even though the differences in productivity among programmers are vast, companies are terrible at measuring them. It's clear that some people are highly valuable (and others are not) but almost no one can get a decent picture of which set is which. The first-order approximation of capability or performance is visibility, but there's a lot of competition for high-visibility projects and the only way to get on them is... well, you get the idea.
So that's why you need an X. Being a software engineer doesn't mean anything. It's not impressive, because there are so many bad ones who work on stupid projects and never learn anything. Being a really good software engineer is impressive, because there are so few of those around, but getting the chance to prove that you're good is difficult and usually involves a lot more politics than it does engineering.
Software engineering is a 3 class society (with a 4th if you count executive nobility):
Peasants spawn with the bozo bit set, free folk spawn with it cleared, and high priests get to toggle it indirectly (through tech stack choices that determine the performance ranking). The managers (nobility) can toggle it directly.
As in medieval Europe, the peasants are about 80%, the free folk are about 10%, and the high priests and nobility (managers) are about 5%. Open Allocation promotes engineers automatically to that middle-class status but, sadly, it's rare thing to see, and it will be a few years (possibly more) before the outsized effectiveness of that model percolates and becomes so obvious that the alternative looks like the insanity that it actually is.
Your X needs to give you enough credibility to start in the middle class, because if you're a peasant, you'll probably never get out, because you'll never get to accomplish much. You'll be fixing bugs and adding features of minor importance and have to convince your boss that they're hard enough to be considered a real accomplishment... and if you have that level of social skill, there are better and faster ways to get out of the peasant class.
On Wall Street, X is going to be either a statistical or financial knowledge-- something that an engineer would never learn doing enterprise apps, which therefore shows that you have a certain curiosity. Or it could be very low-level knowledge (cache-hit frequency optimization) for the purpose of writing low-latency trading systems.
In startups, that X is usually either going to be product management, customer relationships, domain knowledge or machine learning. In fact, "data scientist" seems to be a code word for a programmer who gets to start out in that middle class.
I'd imagine that, in game companies, it's game design knowledge. You're probably better off if you've read, e.g., Rules of Play, than if you haven't.
The X needs to (a) establish long-term viability (growth potential) in the company, and (b) prove that you're smart in a way that's independent of software engineering. Software engineering is very important, but it's also an extremely inefficient way to prove your worth and intellect. How do you prove that you can build architecturally sound, scalable systems if your boss won't let you take time away from that stupid app that helps HR fire people?
The default is that you end up with one key player and N-1 support people, and whoever is the key player will very likely stay in that role, because there's no way for the others to outperform him. It doesn't always happen this way on a software team, but to have it otherwise usually requires intelligent forethought regarding division of labor.
The software industry is full of cycles whereby perception enables performance that strengthens the perception. For example, the only way to get good projects is to have worked on good projects. The truth is that performance is very hard to measure. The only people who can evaluate a programmer's performance is a much better programmer, whose time is so valuable that it's almost never put to that purpose. Perversely, even though the differences in productivity among programmers are vast, companies are terrible at measuring them. It's clear that some people are highly valuable (and others are not) but almost no one can get a decent picture of which set is which. The first-order approximation of capability or performance is visibility, but there's a lot of competition for high-visibility projects and the only way to get on them is... well, you get the idea.
So that's why you need an X. Being a software engineer doesn't mean anything. It's not impressive, because there are so many bad ones who work on stupid projects and never learn anything. Being a really good software engineer is impressive, because there are so few of those around, but getting the chance to prove that you're good is difficult and usually involves a lot more politics than it does engineering.
Software engineering is a 3 class society (with a 4th if you count executive nobility):
- High priests who have titles like "Chief Architect" or "Principal Engineer" and get to build systems that other people will be expected to use, and to make large-scale technical decisions. They're trusted to make decisions that impose complexity on other people, and one generally hopes that they make good decisions. If they're good, they make the lives of the rest much better. If they're bad, they create disasters. In small companies, a bad architect can be fatal.
- Free townsfolk (middle classes) who have the right to opt out of complexity coming from other people, because they're implicitly assumed to be doing something useful. They're expected to contribute, but they get a lot of autonomy in what they work on and how they deliver their work. They don't get to impose complexity on others freely, but they aren't having unfunded mandates shoved in their workflow constantly. Most data scientists and financial quants work in this way. If they want to work in Python, R, or Clojure, they can.
- Peasants who maintain or work on systems where the decisions are already made. The surplus engineers who aren't really trusted with their own time or initiative. They plod along slowly, held back by the muck of others' complexity, and almost never get a chance to prove themselves. Once you're 3 years out of school, you won't learn anything in a peasant role and you should plan an exit strategy (from the role, not necessarily the company) starting at 6 months.
Peasants spawn with the bozo bit set, free folk spawn with it cleared, and high priests get to toggle it indirectly (through tech stack choices that determine the performance ranking). The managers (nobility) can toggle it directly.
As in medieval Europe, the peasants are about 80%, the free folk are about 10%, and the high priests and nobility (managers) are about 5%. Open Allocation promotes engineers automatically to that middle-class status but, sadly, it's rare thing to see, and it will be a few years (possibly more) before the outsized effectiveness of that model percolates and becomes so obvious that the alternative looks like the insanity that it actually is.
Your X needs to give you enough credibility to start in the middle class, because if you're a peasant, you'll probably never get out, because you'll never get to accomplish much. You'll be fixing bugs and adding features of minor importance and have to convince your boss that they're hard enough to be considered a real accomplishment... and if you have that level of social skill, there are better and faster ways to get out of the peasant class.
On Wall Street, X is going to be either a statistical or financial knowledge-- something that an engineer would never learn doing enterprise apps, which therefore shows that you have a certain curiosity. Or it could be very low-level knowledge (cache-hit frequency optimization) for the purpose of writing low-latency trading systems.
In startups, that X is usually either going to be product management, customer relationships, domain knowledge or machine learning. In fact, "data scientist" seems to be a code word for a programmer who gets to start out in that middle class.
I'd imagine that, in game companies, it's game design knowledge. You're probably better off if you've read, e.g., Rules of Play, than if you haven't.
The X needs to (a) establish long-term viability (growth potential) in the company, and (b) prove that you're smart in a way that's independent of software engineering. Software engineering is very important, but it's also an extremely inefficient way to prove your worth and intellect. How do you prove that you can build architecturally sound, scalable systems if your boss won't let you take time away from that stupid app that helps HR fire people?
