Approaches in software development -- or anything else -- that don't take ordinray human failings as their starting point are prone to dramatic failure. "The Impossible Human" is, well, noticeably uncommon. Let's dig in on that.
More geek joy comfort food from me today, but please think & work outside the monitor by enabling and encouraging change in our wider world.

Black Lives Matter.
Some years back, I made content for a CMS that had a whole lot of overlapping parts, each with its own special language. I found it very difficult to express myself quickly & cleanly, and, it being me, I complained about it a lot.
And very often, the responses I received were in the form of "It's easy, just remember X." It still being me, I became sullen and resentful, and was largely unproductive for long stretches.
"It's easy, just remember these 371 simple rules" is a formula for disaster, because it's an approach based on "The Impossible Human". Ordinary humans don't remember 371 simple rules about anything they haven't already mastered.
Now, of course, extraordinarily unlikely humans do exist. Some of the easiest ones for us to share and witness are the great sports heros. MJ, let's say, or Serena. These are, to an arbitrary error epsilon, patently impossible humans.
But we never build a basketball system on the assumption that our team will have twelve MJ's. And we don't build a Davis Cup team with six Serena's, either. Because there *aren't* twelve MJ's or six Serena's. There's one of each.
Humans have astonishing capabilities, both "built-in" and "learnable". But they also have astonishing frailties, built-in and learnable. And any approach to utilizing the former must absolutely also account for the latter.
To be sure, there is no such thing as an "average human". The space of possible humans is too high-dimensional for averages or bell-curves to have useful meaning. Any such average would point to an empty space into which not a single human on earth actually fits.
(That's not psuedo-science. Look into Gilbert Daniels's work on measuring just 10 physical characteristics of pilots. Even *that* was too many dimensions to make "average" meaningful. When he reduced it to just 3 measurements, he got <5% of his enormous sample to be average.)
Can we say *anything* about our imaginary average human? I think, if we abstract our way out high enough, we can. We have to do so with a light touch, and we have to accept the vagueness that comes from an analysis that's so meta-, but I think we can say a thing or two.
My ideas about harvesting the value of change, elaborated out in terms of advice for the software trade, are all attempts to get at these meta-level observations about human strengths and weaknesses. What we are, on imaginary "average", good at, and what we are poor at.
A side note: why worry in particular about *human* strengths & weaknesses. Software development methods combine humans, procedures, and machines. In one sentence: in these tripartite systems --human, procedure, and machine -- the human term dominates the results.
For instance, humans have rigid limits on their mental reach, even when they utilize the ingenious mechanisms, naming, chunking, stacking, scanning, their brains supply. Noticing this, I frequently advocate techniques that assume it.
When I say take many more much smaller complete steps, part of my rationale is in noticing this attribute of our "imaginary average human".

Smaller steps require less mental bandwidth, fewer things to remember, fewer live entities to juggle while working.
The techniques of microtest TDD, of continuous integration, of trunk-based development, these are the positive advice that comes from this observation.
My general resistance to repo-branching, to sprint-length stories, to long methods and large classes, to implementation inheritance, this is negative advice coming in part from that same observation.
Of course, and very much not a coincidence, smaller steps, and that self-same technical advice, goes quite well with another "imaginary average human" attribute: our taste for short-term gratification and our need for rhythm.
The world is full of Aesopian fables about the benefits of delayed gratification. But we're not actually good at that, especially when the enterprise we're engaged in is regarded as merely instrumental to our mission, for most of us taking care of ourselves and our loved ones.
Add rhythm into that mix, alternating multi-frequency cycles of tension and release, and again, smaller steps, the same advice.
There are people who run, every day, as part of their routine -- or, anyway, I've read about such weirdos -- and tho some of them will speak of the great higher goal they achieve, the vast majority of runners, in a quiet moment, will tell you they do it because it feels good.
Endorphins matter to us. And the same endorphins are released by rhythmic multi-frequency tension and rerlease as by running every day. *Both* can acheive long-term faraway goals. But *both* operate by delivering gratification -- partial, incomplete -- to their practicing humans.
Another example of an imaginary average human trait, the one that actually got me started: humans make mistakes. Lots of them. Lots and lots. No. More. Humans make a lot of mistakes.
And though we very often assign human mistakes to failures of will (or morality), that's actually mostly not the case.
Humans weren't built for navigating the modern world. They are the result of navigating yesterday's world, and the day before, and the day before, stretching back a very long ways.
We like to think of ourselves as creatures of reason, but the important word in that phrase is "creature", not "reason". We make thousands of choices every day before the first zoom meeting even starts. It is ludicrous to think that mistakes are a rare exception.
Anyway. There are others. Our gift/need for social interaction. Our ability to sense things we can't say or even know. How lousy we are at objective probability. How hard it is to break mental inertia. How susceptible we are to experience over argument.
It comes down, for me, to this: what I seek is an approach to software development -- the whole trade -- centered on the humans in the system. And I think we need to start by incorporating not just their strengths, but their weaknesses, as well.
Thanks for reading along, a great baggy wandering one today. If you like my work, please subscribe.

And far more importantly, embrace change, in the trade and out. We can fix things. We're the only thing that possibly can.

Black Lives Matter.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with GeePaw Hill

GeePaw Hill Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GeePawHill

28 Feb
"It puts the database on its browser skin, or else it gets the hose again." This task occupies the daily life of a great many programmers. Today, I want to throw out some random sparks of advice for people working in that setting.
Folks, my ideas about changing code are deeply intertwined with my ideas about changing the world, which is a far more important activity than any kind of geekery. Let's geek out, for sure.

But please keep working for change, and supporting those who do.

Black Lives Matter.
In enterprise IT, it is commonplace for backend folks to work on problems shaped like this: there's a web endpoint controller on the top, a database on the bottom, and some simple or complicated business logic in the middle.
Read 32 tweets
27 Feb
ONI: c51, and a couple of building tips. That space next to the musher is going to be infinite food storage. I need it vacuumed out and filled with chlorine.
The stairs down & up on the west are actually a working liquid lock. We usually make permanent ones, but I won't need access to this room, so I really only need the lock for a short time. Two dribbles of water is all it takes. It won't last long, but I don't need it to.
The fastest & easiest way to a vacuum is to fill all the gas tiles with a solid, then use diagonal deconstruct. Whatever was in them is gone when the tile is built, and you get vacuum when it's destroyed. Wouldn't work in this case, but it's the best way.
Read 15 tweets
26 Feb
ONI: So I showed off my base reference, and I've just about got it up and running.
Classic off-by-one, of course: I built one more layer in the base than I actually need. I'll chop that off here in a bit.
It's only c40, I feel like I'm having a good run here. I have 9 dups, the shrooms are starting to build. The next thing in the base is to get the kitchen area closer to how I want it when the shrooms are in. I have one hatch ranch to the east, just getting started.
Read 5 tweets
21 Feb
When we talk about transitioning to microtest TDD, we have to figure out how to provide the right experiences in the right order. That's why I propose we start by getting the experience of changing a well-microtested graceful class.
Folks, my ideas about changing code are thoroughly entangled with my ideas about changing the world, a topic of far greater importance. Let's geek out, by all means, but let's also act outside the monitor.

Black Lives Matter.
"Create Experiences, Not Arguments" is one of the core habits of change-harvesters. We want to take that slogan very seriously when we approach any significant change to our practice. And microtest TDD, believe me, is a significant change.
Read 30 tweets
20 Feb
@AlexandraErin If I just tweet this to you, does it count?
@AlexandraErin Hmmm. Apparently that's legal.
I have a lot of respect for you, have followed you for a while, and tho there's quibbles here or there, no matter.

Not being able to reply to you, in favor or opposed, makes me feel I should move on. I didn't come here for radio stations I can't interact with?
Read 6 tweets
20 Feb
Here's A Tribe Called Quest, "Can I Kick It".

There's no quest but quest.
Funny! Smart! Tradition-enriched!

Strong as *shit*.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!