August 2018 Archives

What makes an engineer

Jean Epperson said,

You don't pay engineers to write code, you pay them to understand subtleties and edges of the problem. The code is incidental.

This made me think. It fits in a tweet, so loses some of the subtleties that will definitely cause people to critique this. However, this makes sense when you look at career progression. Given a job-progression like this...

  1. Associate Software Engineer
  2. Junior Software Engineer
  3. Software Engineer
  4. Senior Software Engineer
  5. Staff Software Engineer
  6. Principal Software Engineer
  7. Software Architect

An Associate Software Engineer knows what code is, and has some skill at making the stuff.

A Junior Software Engineer is getting their feet under them, and has some actual experience at this stuff.

A Software Engineer knows how to produce code given whatever is thrown at them.

So by rung 3, you're good at slinging code. Is the code produced by higher rungs better? Maybe. But look at what skills are being used to make that code better. Why is it better? Is it simply more stylish? Or does it understand the edge-cases in the code-base better than others? Does it have fewer side effects, or is that because experience knows that you just don't do that kind of thing in $language?

Having recently made the jump to Staff myself, this is relevant to my concerns. It isn't the fact I write code that gets me the big money. It's the fact that I can be selective in which code I write, the code I write is aware of side-effects, I have opinions on which code needs to be fixed now versus later, and so on. This is all code, true. However the skills I'm applying to my code-production aren't required to produce code at all, since producing software is more than simply producing code. The skills I'm applying can be used to inform others on the right code to produce. That's what gets me the money.

Taking a different turn, let's look at the deliberately provocative part of that statement:

The code is incidental.

This will piss people off, and I suspect this is intentional.

Recompiling this statement for structural engineers:

You don't pay structural engineers to pour concrete, you pay them to understand subtleties and edges of the problem. The concrete is incidental.

The concrete is hardly incidental, it's what keeps the building/bridge up! And yet, knowing which specific formulation of concrete to order, which is governed by the structural properties it will need as well as the likely weather it will experience during the cure process and later during its structural lifetime, is very much the kind of problem you want handled by someone who has the full context of the problem. Yes, pouring and curing concrete correctly takes a lot of skill. So does knowing which concrete to pour, when. Producing a bridge is more than knowing concrete. Like those Staff and Principal Software Engineers, often they're not the ones writing the code/pouring the concrete. They can, but that's not always why you pay them that much.

Don't yet believe me? Tanya Reilly gave a talk at Write/Speak/Code Conference 2018 last week on the topic of "Being Glue". Or, what happens when you do Senior engineer stuff while you're still a Junior. Juniors get promoted based on their code production. Seniors get promoted based on how awesome they make everyone else. It's a good presentation, and I encourage you to read it.