|
After two weeks of hectic travel, it's good to be back at Fair Pavilion. Where the honeysuckle is in full flower, and just inhaling is like a draught of sweet wine.
Co-teaching POOD courses has a way of consuming every waking minute of my attention, so I don't have a lot of notes for you this week. Instead, I have some thoughts on disciplined practice.
I think a lot of people who take the POOD courses are surprised by the format. In particular, they are surprised by the emphasis on extremely disciplined refactoring in order to achieve emergent design epiphanies. The disciplines are strongly influenced by Katrina Owen's approach, and if you've ever watched her refactor code, you have an idea of the level of rigor I'm talking about.
At the end, class attendees always express amazement at the results achieved by dogged commitment to rote, prescriptive steps. But along the way, there's usually resistance.
Here's what the resistance looks like: after a few minutes, students start to speed up. They feel like they "get it now", and they begin to combine steps, or skip steps.
Counter-intuitively, the more they "speed up", the more likely it is they'll still be fighting test failures while the rest of the class has finished the exercise successfully.
I understand why they do it. I've done it myself, over and over, for years.
Because this is what we do, right? We're smart people, programmers. We absorb new skills quickly. And then we accelerate.
But there's a kind of exceptionalism reflected in this perspective.
Programming is often described as a craft. Think of the other crafts you know:
- You might expect an apprentice bricklayer to practice laying mortar over and over, brick upon brick, for months or years, before being judged consistent enough to be called a master.
- You know that musicians can expect to practice simple scales and arpeggios thousands of times before they are said to be professionals.
- When my grandfather taught me to use a jigsaw, he told me to draw simple curves on bits of scrapwood. And then follow the curves with the jigsaw. Over. And over. And over.
In every other skilled craft I can think of, years of rote, repetitive practice plays a major role. And yet, as programmers, we often expect to absorb every new skill in a matter of hours if not minutes.
Consequently, we often decide that if we don't see returns on a practice in the first few hours or days of using it, it must have no value for us.
There's a certain amount of impatience in this, I think. And perhaps also some hubris.
But I've started to think it goes deeper than that. I think this reluctance to practice rote skills also reflects fear.
In The Now Habit, author Niel Fiore explains how procrastination isn't simply a character failing. It's a rational reaction to unconscious fear. It's a choice to avoid an emotionally threatening situation by replacing it with a less-threatening distraction. For instance, for a doctoral student, finishing her thesis might mean dealing with the even scarier prospect of defending the thesis, and then the far more overwhelming prospect of figuring out what to do next in her life.
I'm going to explain how this fear plays into avoidance of discipline. But first I need to talk about Expert Beginners.
In the preceding issue I linked to the beginning of Erik Dietrich's terrific series on the Expert Beginner. In case you haven't read it, though, let me paint you a quick picture of a stereotypical Expert Beginner:
Meet Steve. Steve manages the IT department, such as it is, at a successful RV sales company. When Steve was 15, the company's owner (a family friend) paid him to create the dealership's first website. Ever since then he's been managing anything software-related at the company.
Just about everything Steve knows about code, he learned from googling and Stack Overflow. Steve has practices that work for him. Steve remembers all the changes he's made to the company's codebases, so he doesn't see why he should use a revision control system. Or why anyone else bothers with one, for that matter. Typical Enterprise overkill.
Steve has a 28-step checklist for manually updating the website. When he hires new helpers for the IT department, Steve indoctrinates them into the checklist. If they make noise about automating any part of it, Steve explains why it would be impossible and/or a pointless waste of time because REASONS.
Steve is an Expert Beginner. He is the local maxima in technical acuity, and because he has always been able to solve hard problems that no one else understands, he thinks of himself as an expert.
Yes, Steve is a bit of a caricature. But I also think that as developers, we all have a little bit of Steve in us.
Because here's the thing: wherever we're at in programming, we have certain types of problems we work on which are excitingly hard. These are the problems which justify our being paid the Big Bucks.
If every time the site goes down, we spend hours poring over inscrutable log output, correlating time series and dropping tracers in just the right obscure code points, we feel like we've done a serious day of work.
If we spend three days agonizing over an ideal object model, and finally come up with something everyone agrees is an elegant and novel approach, we feel like we've justified our existence.
And if someone comes along with a set of practices, or a rote discipline, that promises to reduce one of these tasks to a mechanical, nearly brainless chore, that's a little bit scary.
Not because it threatens our job. But because once the "hard stuff" isn't hard anymore, that means we have to grow. With the time and brainpower it frees up, we have to face the prospect of solving bigger problems on a whole new level of abstraction.
We might even find that with our software problems no longer as excitingly hard, we have to graduate to solving human problems.
I'm not mocking anyone here. This kind of transition is legitimately terrifying.
I remember, as a younger programmer, how I used to accept the dictation of requirements as interpreted by management. And sure, I'd complain about how nonsensical the requirements might seem sometimes. But there was something essentially safe about the arrangement. Management would talk to the customer, and then tell me what to implement. And I'd tell the how it was much harder than it sounded, and then I'd deliver anyway and they'd be happy and I'd feel useful and if it turned out the customer hated it, that was somebody else's problem.
The idea of ever graduating to a level where I was responsible for keeping the customer happy was scary. Much easier to make sure the technical problems stayed hard and interesting and engrossing. With my time and energy consumed by the essential difficulty of my job, I would always require a buffer between me and the higher-level business concerns.
And that's why I've started to think that resistance to boring, rote, simplifying disciplines in software development reflects a certain amount of fear. I'm curious if you agree, or if you have a different perspective on this.
Notes & Quotes
Have you ever noticed that you come in as a consultant or specialist, and are regarded as a high priced, hot shot commodity? And then, you just kind of run out of steam somehow, without realizing it, six months in? When you started, the CTO was interested in your strategic expertise, but now some project manager is chiding you for not reporting your status with a little more flair during a daily standup?
--- Erik Dietrich on The Gravitational Force of Wage Labor
The easiest people to recruit are ones with alert, questioning minds who want to debate issues with other people. You take a strong-willed, strong-minded person and put them into a cult environment and the techniques used will break a person down very, very quickly. The smarter, the healthier the mind, the quicker and easier you are to control.
That's from a Vice article on cults. This may seem off-topic for this newsletter. But one of the most worrisome trends I see in the software industry is the assumption that since we're all smart, alert, critical thinkers, we're better-equipped to avoid fallacies and failures of human judgement. Nothing could be further from the truth.
So is Elm about FRP anymore? No. Those days are over now. Elm is just a functional language that takes concurrency very seriously. And from a user's perspective, Elm is just a friendly functional language!
The Elm language is bidding farewell to Functional-Reactive Programming. Elm continues to be a fascinating study in user-oriented programming language evolution.
Out and About
NOTHING! NOT ONE THING ON THE CALENDAR! I GET TO SIT AT HOME IN MY PAJAMAS! Wait, I don't even own pajamas. Time to go pajama shopping...
This week I'm grateful for...
Delta Airlines. The other day I experienced my first major delay (maintenance related) on this airline. And it has given me cause to reflect on how basically non-eventful, competent, and professional my experience has been on Delta compared to every other US international airline.
(Honorable mention: Southwest is still the most fun airline to fly domestically. But since I've been traveling out of country more often, it has become more important to me to accrue status on a single international carrier.)
That wraps it up for this week. As always, if you have a comment on anything in this week's letter, please reply! I'd love to hear from you.
Have a great week, and happy hacking!
-- Avdi
|
