Thread by @sarahmei

Good news everyone! My flight is several hours delayed, so I’m going to have a beer and read this book and think ideas and tell you them

I started reading it previously, and below you’ll find a selection of the comments I wrote then.

In the spirit of what-the-fuck-else-am-I-going-to-do-for-four-hours, though, I’m going to start back at the beginning.

One of the things I find frustrating about software design blogs/books/talks is when they repeat received wisdom about software design without questioning whether it really makes sense anymore. I mean, it might still make sense...but it really might not.

For example: the preface says the goal of software design is to decompose problems, or iow "break a complex problem into pieces that can be solved independently."

I remember hearing that in the software design classes I took in undergrad. It sounded logical at the time.

Twenty years in the trenches later...I find there's nothing in that description that rings true anymore.

Maybe it's true that 0.05% of the time when you're starting a new project? Or maybe when your goal is to delegate pieces to your reports, rather than work on it yourself?

My goal with software design is to make future change easier. Full stop. That's it.

There are many tools in the toolbox labeled "making future change easier." Breaking off pieces to delegate (if "independently" means "by different developers") is one. Deferring design decisions (if it means "at different times") is another.

But there's so much more to it.

Ok we are not even on page one yet people. This is page vii and I'm already unsure that the author and I are even remotely on the same page here

I went out to see if maybe I should sit by the gate instead of in the bar, but this is today’s last direct flight to San Francisco.

The gate area was full of executives and there’s still over an hour left before boarding starts

I could say more about the “problem decomposition” thing (like are we bacteria, and the problems are fallen trees? Our goal is to make everything dirt?) BUT I’m going to move on & hope the author goes into greater depth/nuance later.

Ok especially because one of the best tools we have for software design is called “composition” I really think “decomposing problems” is not the right way to think about this

MOVING ON

Ok I said I was going to move on, but this is VERY NEXT PARAGRAPH. “It is widely accepted”??!1??!!!??!!1one!!?? #nope

WELL ACTUALLY. Perceived differences in developer skill are more easily explained by a culture that denigrates people management skills and rewards shitty management.

It’s normal for a manager to be completely fucking unable to adapt their manage techniques to the different people they manage.

Turns out, that makes people who act like you look 10x better than everyone else. BETTER FIRE THOSE OTHERS. THEY’RE NOT A CULTURE FIT.

If you see vast gulfs of skill in your team, IT IS YOUR FAULT. You are a bad manager.

I found something I agree with

Three hours, one beer, and two profound philosophical differences later, I have made it to page one.

Sometimes the preface is sort of dashed off quickly, so ok.

I took some deep cleansing breaths. I’m ready to leave my skepticism behind and fully move on to the actual book.

Good news, everyone! My plane is here & everyone got off it, but we won’t leave for another 2 hours. Hooray! So I can at least make it through the first chapter.

Page one, chapter one: programming requires “a creative mind and the ability to organize your thoughts.”

The former: maybe sorta
The latter: #nope

This is a classic mistake that I’ve seen often enough in talk proposals to give it a name: the “my amazing journey” talks.

My Amazing Journey!!

In which a successful programmer analyzes how they think, so they can help others understand what it takes to succeed. But they lack the self-awareness to realize that their success was due more to circumstance than to their attributes or actions.

There are few talks more alienating to a diverse audience than My Amazing Journey!!.

Always a hard pass.

The trouble with working in homogenous teams is that it reinforces your idea that everyone needs to think like you to succeed. After all, only your group succeeded!🤔

This is a super common logical error that all humans are prone to, called “survivorship bias.” en.m.wikipedia.org/wiki/Survivors…

It’s also related to our brains’ insatiable desire to make a narrative out of...well, everything, but especially our own past.

Sorry to leave you hanging but MY PLANE TOOK OFF and then even more importantly IT LANDED. I’m grateful to be back in SF weather. Also that I didn’t have to read any more of that book.

But don’t worry - I took the day off tomorrow, and what better way to pass the time??

Sometimes I think that people who can hold complex systems entirely in their heads - classic ‘genius’ programmers, clearly the type this autthor is - are actually at a disadvantage these days.

At some scale, even _they_ run out of brainspace, and then they don’t have the habits people like me developed early on - by necessity - to carve out spaces where we didn’t _have_ to hold it all in our heads.

This type of programmer sometimes also has trouble collaborating, because much of the context other people require in order to understand what they’re doing has receded into unconsciouness.

Neither of the types of programmers I’ve outlined is better or worse at programming; skill is sort of an orthogonal axis. They just have different strengths & challenges.

So far this book has been an interesting (if unintentional) illumination of all the blind spots the “other type” has. It’s fascinating, but also frustrating, because I really want us to be past this oblivious generalizing.

I guess I need to write the book that moves us past it😛