Thread by @HeyChelseaTroy

Jean identifies a narrow slice of perspectives that disproportionately drive the conversation about what "good software eng" looks like: both the code itself and the work that produces it.

Here's my $0.02, as a S.Eng and an educator, on what this conversation misses.

/1

https://twitter.com/jeanqasaur/status/1455589141299675139

So first of all: a few tweets downthread, Jean brings up FAANGs. I promise, I'll get to FAANGs. But that's not where this conversation starts.

It starts with the dissonance between what 90+% of devs do and what they THINK they do.

/2

The lion's share of "THE OTHER STUFF," from my perspective, are the parts of engineering that The Conversation about "good software engineering" habitually ignores or under-discusses.

Once again, educator and practitioner here: I think "the parts" are like 80+% of the job.

/3

I've said this before, so this'll be review if you've ever broken bread with me:

MOST dev education, from academia to YouTube tutorials, is "How to build Y from scratch using X."

Meanwhile, most engineering projects look like "add to, fix, or maintain this thing."

/4

And I think if you were to ASK devs what they do, they'd often SAY "I build [thing]." But that's aspirational. They want to be building. They think of themselves as builders.

Enhancements, repairs, and maintenance lack relative desirability, so the convo glosses over them.

/5

What's the impact?

We fail to hone a slate of skills that we then spend 80+% of our time using.

Like debugging skills, or figuring out what the hell this code is meant to do (I call this 'forensic software analysis').

ALL these, in fact:

/6

chelseatroy.com/2021/10/29/a-r…

...and the follow-on impact of THAT is that, because we're bad at these things, we spend more time doing them worse, and in the process make our jobs less fun for ourselves and leave behind code that makes our successors' jobs less fun, too.

/7

For example, let's take just one: debugging.

It doesn't even have to suck.

It CERTAINLY doesn't have to be as stressful as it is when we're all conditioned to treat debugging like standing on tiles barefoot during a game of "the floor is lava"

/8

chelseatroy.com/2019/12/30/pos…

For the record, I know plenty of FAANG devs and ex-FAANG devs. They, too, do loads of debugging. Maintenance. Forensic software analysis.

The "dark matter of software engineering," to me, is less "FAANG vs not FAANG" and more "A dev's plum project vs most of the actual job."

/9

I'm also gonna note, I'm not a willing subscriber to the FAANG-hegemonic view of software eng.

I WILL concede that commonly used open source dependencies, and therefore a disproportionate piece of everyone's code bases, belongs to these companies, so we'll discuss that.

/10

For the uninitiated: FAANG stands for "Meta/Apple/Amazon/Netflix/Google," and it's like the Harvard-Yale-Princeton of tech employment.

/11

So, note that I said the dependencies "belong to" these companies, not "come from these companies. The things we credit FAANGs for, upon close inspection, are themselves often testaments to the fact that quality tools come from everywhere.

For example...

/12

FB did not build React. They acquired it.
Apple did not build the iconic touchscreen. They acquired it.
Google did not build Android. They acquired it.
Netflix did not build Metaflow. They acquired it.

These places don't universally generate 'excellence'. They buy it up.

/13

But, OK, so the QUESTION was "are their practices universal?" and the proposition was that they're NOT, and I agree.

Most folks don't have billions of rows of data. They don't have HUNDREDS of engineers theoretically available like interchangeable parts.

/14

That is a very unique, particular situation, and I'd say it applies to...honestly not even most teams at the FAANGs. Again, that situation is aspirational and therefore overrepresented.

Let's compare it to some of my clients.

/15

My clients are often social-good projects run on grants, donations, and the goodwill of the privileged.

In that world, 'Bus count of 1' is aspirational. It's frequently 'we WISH we had a dedicated person, but for now it's either LaQuan's Friday evenings or nothing.'

/16

In THAT world, you can't count on context handoffs, and your patterns have to withstand it.

It's not "we do this because our engineers suck." It's "we do this to navigate a constraints that no giant OS sponsor deals with to this degree."

/17

Example:

https://twitter.com/HeyChelseaTroy/status/1452153909208829952

Another example: there are operational & ethical questions associated with the use of small-n data.

"What guardrails do I need to efficaciously and ethically predict off of a training set with confidence intervals THIS big?"

In fact...

/18

Default and commonly-taught practices are INSUFFICIENTLY RIGOROUS or small-n data.

We train people on giant datasets with no ethical concerns like MNIST and Iris, and then ask them to analyze 200 medical records.

Teams need much MORE knowledge to do that correctly.

/19

OK, so in addition to the slew of skills we use all the time as engineers that we mostly don't discuss in tech education,

there's also a slew of constraints and circumstances we face all the time as engineers that we mostly don't discuss in tech education.

What do?

/20

"Fix all of tech" look brah I'm TRYING, but it's taking a second. Patience plz.

In the meantime, on the backend, we can get more nuanced about how we evaluate practices, skills, and solutions.

Starting with, ditch "best practice." That's fake. That's not a real thing.

/21

There's no universal best practice because there's no universal. If we're acting like it's universal, there's some specific context that we don't realize we're treating as the default.

Watch me drink wine and yak about this in my Oscar the Grouch PJs

/22
chelseatroy.com/2021/10/04/yow…

INSTEAD of evaluating a skill, practice, or solution on whether we "like" it or whether it's called "best", we can EXPLICITLY consider who it's for, how they use it, and whether their context transfers to us.

The questions I ask in tool evaluation:

/23

chelseatroy.com/2021/09/22/cri…

OK I think that's plenty for one thread. Calling it here.

24/24