Thread by @HeyChelseaTroy

So, engineers get blamed for a lot of stuff.

To be clear, engineers have a lot of power and share blame for a lot of stuff.

But also, engineering suffers a bit from the goalie problem, and it ends up negatively impacting orgs' opportunities to fix things. 1/

The Goalie Problem:

Any time the opponent scores, what's immediately obvious is whatever the goalie did wrong.

But the most fruitful answers to "how can we not let this happen again" often have to do with how that ball got into the goalie territory in the first place.

2/

Here's a common one: some kind of joke about "Engineers write bad error messages."

'kay, well, sure, hardy harr, but that's what happens when you don't give eng the time or access to ask questions and then and hire a designer who doesn't design failure cases.

3/

BOTH those things have to happen to end up with "bad engineer write error messages bad." At least two misses have to happen: one in management, one in design, before the engineer even gets the CHANCE to bork this up.

4/

Here's a more serious one: Dieselgate. Not familiar? See report below (hosted on my site because the best access point for it was...ahem, removed).

5/

chelseatroy.com/wp-content/upl…

Basically, VW had software in their cars to cheat emissions tests.

Execs straight up tried to blame the engineer who typed the characters.

In this case they failed, but it set a precedent for tech execs getting sued and blaming their hired muscle.

That's dangerous.

6/

Am I saying an engineer is zero percent responsible for this?

Do you know who I am and what kind of shit I've said? Of course not (see articles below).

HOWEVER

7/

chelseatroy.com/category/techt…

If execs can tell engineers what to do and then shift legal, regulatory, and ethical accountability for their decisions onto those engineers, they're incentivized to maximize short-term profits with no concern for consequences.

That is bad for all of us.

8/

Another one I see going around right now is this meme about how engineers don't do refactors or update their dependencies and instead switch jobs every two years so they never have to deal with the consequences of the code they wrote.

9/

Lemme be clear witcha about some things:

1. I have a consultancy where I specialize in dealing with code like this. Most of the time the code isn't actually that awful, it just suffers from context loss. Engineers don't suck as much as people want to believe.

BUT ALSO

10/

2. I have also worked at orgs where the authors of version 1 are still there, 10 years later, and THAT code looks just like the code engineers "leave companies to get away from."

FTLOG, engineers are not PLOTTING to crank shite code and bail.

THIRDLY

11/

3. Code stewardship is a skill set, separate from cranking code, that is:

- not taught
- not even RECOGNIZED as a THING in most places
- CERTAINLY not INCENTIVIZED

More on this, and if you think I'm salty NOW, wait'll you read this series

12/

chelseatroy.com/2021/01/14/qua…

Engineers crank code when they're told that that's what gets them promotions, raises, and cool projects.

They then leave after 2.2 years because, in spite of having followed the directions, they're still not given promotions, raises, or cool projects.

13/

Seriously, it's like a joke in tech that it's 100x easier to get a promotion by leaving than by staying.

That's not an engineering decision. That's a management decision.

14/

Decisions (and their consequences) flow from the top of the org to the bottom.

From the executives to the implementers.

From the front of the field to the back.

From the striker to the goalie.

15/

When I didn't want to write code to fuel drones to go kill kids in MENA, it was on me to leave my job.

When I want to maintainable-fy some code, it's on me to start a consultancy to do it. Because orgs aren't hiring for that (until they're super stuck; then they call me).

16/

We limit our ability to address insidious structural problems when we depend on the assumption of individual responsibility by the people at the end of the decision-making chain.

Even in the har-de-har cases, it's actually not that funny.

17/

Let's talk about the system and understand failures not as the SINGLE POINT where the situation became irredeemable, but as the accrual of risk along the chain of decision-making.

And, AND, the incentives and context that contributed to how those decisions were made.

18/18