I want to start talking about teaching in the geek trades.
Today in particular, I want to talk about "emphasis", what our style & materials stresses or underlines about the path to mastery for our up and coming geeks.
Black lives matter. Here I sit writing geekery, a sideshow, while my siblings are out there day on day putting themselves at grave personal risk in the quest for equity. I strongly support their efforts. Stay safe, stay strong, stay angry, stay kind. Embrace change.
I am by nature an analyst, a theorist, and a person driven to critique. That makes me pretty negative-seeming at times. That’s not accidental. I find that I often can’t find a way forward until I have thoroughly identified what I don’t like about where I am now.
Of course, while one does this, one also shares it, often enough in snarky asides. I recently tossed one out about the damage done by crummy pedagogy. It was with respect to TDD, but that’s irrelevant. I actually feel the same way about most of our teaching in the trade.
A respondent asked me to say more about how we could change — for the better –professional teaching and learning in the trade. This is my first swing at a more positive response.
I’m going to start at a very high level of abstraction, grand strategy really. I have ideas about tactics, and we’ll touch on them on other days, but let’s be clear: master teachers could take my ideas and make many tactics from them, almost certainly far better than I could do.
When I read, listen to, or watch educational content from our trade, it’s not so much what’s there and what’s not that troubles me, it’s what is stressed and explicit vs what is unstressed and implied, or sometimes even ignored altogether.
Thus we start with emphasis. I have several key pillars in my professional practice that I wish to underline, to stress, to emphasize, to highlight, to shout to the heavens even. To me, these are key orientation landmarks on the many paths to mastery.
You’ll notice that each of these emphasis points are cross-cutting concerns. They apply at various levels and roles, code-ish and not, and to various techniques and topics, and to individuals, teams, and whole organizations. This is substance, style, and strategy at once.
(Whoa: Scary thunderstorm here. Be back when things get less terrifying for me and Molly.)
The emphases represent an atmosphere, the water we swim in, they are a culture. My hope is that by calling these positive ideas out, we can find myriad ways to re-center ourselves around professional education in the geek trades. Without further preface, here are my thoughts.
1. Emphasize collaboration.
Modern software development is almost never a lonely solo enterprise. It is absolutely chock-a-block with human interaction. Effective professional software creation demans effective human interaction.
Important sub-ideas here: direct collaboration, not hand-offs or documents or meetings. nuanced collaboration, not rule-driven verbal patterning but genuine conversation. joyful and painful collaboration, the sharing of the world not the beige-ifying of it.
We need to be pouring collaboration on our up and coming geeks. Style and substance, approach and content. They will have gotten very little of it in the pre-trade learning or the materials they find in technically oriented texts.
2. Emphasize iteration.
The skills and attitude required for gradual refinement of working software are of critical importance in the modern trade. Writing software resembles the act of sketching a cat more than it does the act of building from a blueprint.
These apps are big, and modern software investment is consistently "pay as you go". That means we have to get to market early and return to it often. Iterative style is the only style that fits here.
The day a piece of software stops changing, or a team, or an organization, is the day it ends. Pedagogy focused overmuch on forethought, planning, and "finality" ignores reality.
3. Emphasize brownfield technique.
The overwhelming majority of what we do as makers may look like "add" on the surface of the app, but it looks like "change" in the code. Even at its most pure, adding function is nearly always changing function, even if only to "hook it up".
We need approach and technique that specializes in getting something that’s already working in one way to be also (and sometimes instead) working in another. That technique isn’t about filling a blank page, it’s about altering a page that’s already filled out.
Ideas like Incremental Switchover, More Smaller Steps, Easiest Nearest Owwie First, and techniques like TDD, refactoring, continuous integration, continuous deployment, this is the stuff of change, and change is what makers do the most of.
4. Emphasize judgment.
There is no valid formal method for making and shipping software. If there were, humans would not be programming, computers would. Software making is irremediably, permanently, thoroughly, and happily dependent on individual humans using judgment.
(Storm returning with a vengeance, power wobbly, if I get popped, I’ll be back, trust me. God I hate electrical storms. So does Molly. I wish I had a thunder shirt.)
Successful developers make seat-of-the-pants decisions every day. Master developers use their intuition constantly, and very few of them can really describe what’s going on when they do it. Operational and situational awareness is everywhere in geekery.
Rita Mae Brown wrote: "Good judgment comes from experience, and experience comes from bad judgment."
Overstating the value of rules is one of the most anti-learning aspects of the software trade.
5. Emphasize self-sensing.
Master developers are acutely aware of how they feel when they’re working. They observe themselves before, during, and after the coding. They attend to their experience. And ultimately, they act on it.
When a pro uses a tool she doesn’t like, or a technique, or a chunk of code, or even a process, she changes it. And how does she know she doesn’t like it? By sensing what is happening to her and others while it’s going on.
I often suggest "more sullen resentment" amongst my juniors. If they weren’t so tolerant of discomfort, so sure that that’s just the way it has to be, they’d become a lot stronger a lot quicker. The first step in that maturation: noticing.
6. Emphasize experimentalism.
The humans we work around — the market, the org, the team, the coders — are the absolute maxed-out definition of organic complexity. They can’t be solved in theory: the only way forward is the continuous process of experimentation.
Software making is often billed as some kind of ultimate bastion of logic and theory, because computers work that way. But making software isn’t software. The more we reason from pure theory, the further awry we’re likely to go.
A standard question for a master confronting a new and scary idea: What’s the easiest way we can find out whether this definitely won’t work?
This applies in code, in process, in teaming, in organization, in teaching, in learning, and in marketing.
So these: collaboration, iteration, brownfield technique, judgment, self-sensing, and experimentalism, are my first six points of emphasis in changing — at a very high level — how we open our geek protoge’s to the path to mastery.
And the question, for me and I hope hope hope for this trade’s leadership, now becomes one of how turn these grand strategic ideas into tactics and praxis. It’s daunting, but here’s the thing. We can bring these same strategies to bear on our pedagogy as we do on our making.
I will likely think of others, and you may already have thought of some, but this is almost enough for now.
I just have one more for the moment.
Emphasize joy.
Software makers are sitting in the catbird seat, and we have been, for several decades. Demand is high, pay is good, and making is some of the most fun there is.
Supporting The PawCast
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. Support GeePaw Here.