- Tech: It’s Not Just Programmers
- A Brief Caveat
- Why Does It Matter?
- Types Of Tech Workers: A Summary
- Programmer
- Sysadmin
Tech: It’s Not Just Programmers
If you have found yourself to be good with computers, you’ve probably had people tell you that you should become a programmer because they make a ton of money. You’ve probably heard this a lot.
It’s only a tiny part of the story.
You have almost certainly come away with a false impression, which is this:
The only way to make great money with the giant tech companies as an individual contributor (IC) is to be a programmer.
Like, it’s either management (probably upper management), or programmer, right?, everybody else is like, I dunno, someone who gets the coffee for the programmers, or something?
This simply isn’t true.
A Brief Caveat
I’m drawing my experience here from the software industry, primarily on the web-facing side of things, and also from the Unix side of the industry. This may limit the applicability of my views, but I know for example that there are banks that have people just like what I’m describing here, so there are certainly many companies where these descriptions apply.
Why Does It Matter?
Why does it matter that everyone who is interested in computers automatically drifts to “programmer”?
The problem is that “programmer” isn’t just a set of skills, it’s a mindset. It’s talents and inclinations. This matters. People who are doing work that doesn’t match their nature aren’t going to be happy with the work they do. Given the number of very different personality traits that can be matched to the needs of most software development organizations, this is a waste of people’s energy and talent.
One of my favorite management books, First Break All The Rules, is largely about this. Ignore the horrible title. The book is actually about identifying what personality traits of ICs match to what sorts of work you need, and making sure that those things line up. It specifically demolishes the idea that you can mold a person to a line of work that their talents don’t mesh well with. You can, of course, force such things, but people’s best work only come out when their talents align with the work, and it is very much worth experiencing yourself doing your best work, and for managers who want to build an effective team this is also essential.
Another important issue here is that you really should be working on stuff you find easy and/or enjoyable if at all possible; I wrote a little something about that.
Types Of Tech Workers: A Summary
I’ve noticed 4 broad groups of tech worker types that each have a nice, high-demand bucket to fit it to. These are by no means all of them, but if you look for yourself reflected in these personalities, you might end up much happier than if you simply go with the default of “computers == programmer”.
Here’s the summary, but I have much more to say about each of them below.
Programmer
Needs: To build things. Usually, but not always, needs to see the things they’ve built get used.
Hates: Interruptions.
Sysadmin
Needs: To fix things. To make disparate systems work together.
Hates: When humans do work that computers could easily do.
Project Manager
Needs: To organize things. To understand what’s happening, who’s doing it, and when.
Hates: When people refuse to help in the process of predicting the work and engaging with the customer.
Tester
Needs: To pull things apart and see where they break.
Hates: When people treat testing as a necessary evil, rather than a core aspect of producing a great product.
Technical People Manager
Needs: To grow and develop great people.
Hates: Complex, but often includes things like “wasting good people on the wrong work” and “having arbitrary edicts delivered from upper management with no context provided for the actual people they will affect” and “to see teams being antagonistic towards each other when we’re all supposed to be trying to make a great product”.
Programmer
Programmers are builders. More precisely, they’re long-term builders. A programmer expects to be given a blank sheet of paper (metaphorically speaking), an idea, and the freedom to build that idea.
Interruptions
A fundamental thing about programming that non-programmers don’t get is that programming as right at the edge of what is possible for most of the people that can do it at all. If humans were any dumber than we are, we simply wouldn’t be able to do it. This leads to a process every programmer is familiar with, of slowly wrapping your head around the problem before you and the code that is already there, until you can understand the whole thing in your head; only then can you start coding effectively.
The problem is that this can often take 30 minutes or more; sometimes an hour or two. When a programmer is interrupted for more than a few seconds, there’s a very good chance that their precious understanding is lost, and they’re in for another 30+ minutes to get it back.
This is why programmers tend to be incredibly sensitive to interruptions, and why you can often make friends with programmers very quickly simply by stopping talking immediately if they make it clear you’re interrupting. They know you’re there; they’ll be with you as soon as they’ve written down enough to be able to get back to where they were quickly.
Love Of The Product
For many programmers, the thing they’ve built is an incredibly important part of their value to themselves. It’s the thing they’ve given to the world. They tend to be very sensitive to anyone saying bad things about their product.
This can, especially in poorly-managed environments, lead to strong antagonism between QA/Testing and Development. It is a constant struggle for most programmers to want their code to be bug free; their desire to have written the perfect thing on the first pass is typically stronger. The best programmers come with a built-in positive response to other people bringing them bugs, as it lets them build better stuff, but this is very rare.
Misanthropy
Technical people in general have a famous reputation for frequently being hard to get along with.
The truth of the matter is that in basically all modern development contexts, the lone maverick who no-one wants to work with is a liability. Having said that, it’s definitely a part of many programmers’ personalities that they’d rather be coding than talking to you, and knowing this is valuable for both recognizing your internal programmer and for dealing with them in your life.
Programmer and (in very limited contexts) Sysadmin are the only tech jobs I’m talking about here in which misanthropy can be made to work, given a careful and skilled manager. For the other two “gee I really like computers but I really don’t much like people” is a pure show-stopper.
Even as a Programmer or a Sysadmin, though, I really suggest you read “How To Win Friends And Influence People”. Horrible title, great book.
Sysadmin
(Fair warning: I was a sysadmin for 20 years before transitioning to management; I have a lot of strong opinions here.)
Sysadmins are problems solvers, fixers and connectors. They usually have a near-compulsive urge to repair broken things and systems. (As a friend once put it “If you have ever spent an entire afternoon untangling a rope instead of spending 10 minutes buying a new one, you might be a sysadmin.”) This often extends to a similarly strong urge to make disparate systems work together, even though they were never designed to do so, if making them work together will solve a problem.
I spent about a decade of my sysadmin career describing my job and primary skill set as “I solve problems”; if this sounds like you, you might have The Sysadmin Nature.
Sysadmin vs. SRE
There’s something of a move in the world of sysadminning to define ourselves (at least those of us that operate at large scale) as Site Reliability Engineers. This is a much clearer description of what many of us do than Systems Administrator. The focus with SRE is on automation and large-scale thinking. There is also a strong implication that you are working with other teams, such as the development/product teams, and not just operating in a vacuum.
Misanthropy
Sysadmins are, if anything, more famous for being horrendously arrogant than programmers (see http://bofh.bjash.com/ , a piece of cultural mythology which I loathe, by the way).
This attitude comes from the distant past wherein a sysadmin was responsible for one or two machines and was the only person who knew how they worked, or how to use them in a reasonable fashion. The world is not this place anymore.
In a sufficiently small show you can maybe get away with not interacting with other people very much as a sysadmin. In an SRE context, that’s not going to work; you can’t do your job if you can’t understand the context of your systems.
The “being mean to everybody” side of misanthropy, on the other hand, is a non-starter in all modern sysadmin contexts.
As I said in the Programmer section, if this is a problem for you, I really suggest you read “How To Win Friends And Influence People”. Horrible title, great book.
Attention Problems
Sysadmins are
Test.
You might be a sysadmin if:
- you don’t like to work on the some project every day
- you have to take regular breaks from any given project
- you like to get regular hits of accomplishing something
- you like fixing things more than you like building things
- you have lots of things to say about a completed, or partially completed, design, but a blank sheet of paper stops you cold
- craftsperson; need for apprenticeship; FIXME: expand
- role of experience; noticing problems
- dev, test, pm, sre
- building, breaking, organizing, fixing
- whether or not cleverness is a virtue (yes for devs, no for sres)
Sensitivity to interruption.
Love of people/helping people.
SREs often do test automation; very similar
- dev = builder, qa = finder of problems, ops = fixer of problems, pm = organizer
- This concept may be of use, regarding QA: https://en.m.wikipedia.org/wiki/Kaizen