Strawberries 8: Joy

Technical Practices, Craft, Excellence, Improvement, Ease, Joy. What ARE you talking about??

On Twitter the past few days, my good Tweep Alex Bunardzic was commenting that his biggest career challenge has been “selling technical excellence”. It seemed to him that the issue for devs who wouldn’t buy in was that while it might be better later, it would involve hard work now in return for a promise of good things later¹.

It’s a problem for my current strawberry thinking. A strawberry is supposed to be an idea, for something we can do, that delivers very prompt results, and which cannot be watered down. It can be small, but needs to be immediate, and lumpy.

In our Friday night Zoom ensemble sessions—today’s Monday—so there’s one tomorrow night, we often talk about Hill’s notion of “geek joy”, the sheer pleasure of doing that thing that we do. I don’t like the word “geek”—shades of a really awful summer job I had, never mind—but I do like the concept. I have enjoyed programming since back in the year nineteen and sixty-one. Oh I’ve had jobs that I hated. I’ve had stress that harmed me and my family. But I’ve always been able to find true joy in the programming. Even if I had to do it at home.

Even if I had to do it at home.

Now I’m weird. I enjoyed most math classes and physics classes. I enjoyed solving problems. I enjoyed taking the car apart and putting it back together. I enjoyed building weird things with my erector set. I enjoyed creating nitrogen triiodide, which explodes with a nice purple iodine smoke.

But bless you, if you’re in a programming job and you don’t enjoy solving problems, run, don’t walk, to the nearest exit and start doing something you enjoy. The problems won’t stop coming in programming. I’m sorry, but programmers are machines where you dump problems in the top and solutions (and often new problems) come out the fingertips².

OK, if you’re still here, you like solving programming problems. Let’s move on to how we can motivate ourselves to solve them better.

Gom Jabbar, by Intel

Paul Atreides: What’s in the box?
Reverend Mother Mohiam: Pain.

If you’re like me, or even if you’re human, you’ve probably quite often felt frustration while programming. Mental pain, maybe even the physical pain of stress. There comes a time when the computer just won’t do what we want and we want to scream “WHYYYYY” and pull our hands from the keyboard and fling it across the room. It’s usually only the strong corporate strictures against damaging company property that stop us.

Few of us are ever actually forced to program by the application of a meta-cyanide needle to our neck, but somehow we suffer the occasional pain provided by the box we work with our hands.

The worst thing is that the pain is almost always self-induced. We wrote the code that refuses to work, often just moments before. What kind of fool builds a pain box and then sticks their hand in it? There must be a better way.

Of course, there is, and it’s all tied up with taking much smaller steps, and moving from working to not working and back to working very rapidly, rather than from working to not working to not working worse to not working but why to oh no now even the old stuff isn’t working …

We need a box that isn’t full of pain, and that tangibly improves our lives right away, not after a year or ten of effort. And yet, what we need is greater skill. We can’t just take a skill pill, can we?

Big Deal Learning

It seems that what we have to learn is huge.

My friend Alex is selling “technical excellence”. That’s a big deal. I’ve been at this for a long time, and there are few areas of technology where I consider myself excellent. Maybe there are none, and there are plenty where I’m barely adequate and many more where I know essentially nothing. There’s pain in the box right now, we don’t have time to wait past our eighth decade to start getting good.

We see proponents of “Craft”, good ones like Pete McBreen (time to reread his book), and other proponents who seem perhaps just a bit too intense for most of us. Now, I feel strongly that programming is a craft, not a science, and not engineering as I was taught engineering. Some folks differ, and honestly, I don’t think it matters.

What is clear is that even in a very narrow type of programming, there are tens, hundreds of individual skills that go into the making of the thing, and we need to be at least pretty darn good at most of them. And we’re faced, day in and day out, with a box full of pain telling us that we’re not good enough, and folks like me talking about XP, and TDD, and Refactoring, and al that jazz, every one of those things way too big to pick up while we’re on break, or even of an evening or over the weekend, even if we were inclined to spend our time that way.

What’s to be done?

A Box of Skill Pills?

As I think my way through this article, Wordle comes to mind. This very popular little game has done more than fill Twitter with irritating colored boxes. It’s a very simple game, and in its original form you only get one Wordle puzzle per day, and it takes just a few minutes to solve. (You only get six tries, so sometimes it just takes a few minutes to fail. That’s OK too. P.S. I found today’s word impossible.)

What if we could learn to package our learnings about the craft, about excellence, about just getting by a bit more easily, into tiny interesting problems that only take a few minutes to solve.

Think about it: I’m always up in here saying that I do best when I can move from green to green in five or ten minutes. What if we could produce a bunch of ten minute TDD problems, in the language of your choice, where you’re presented with a small body of code, a capability to add to that program, and you win the game by writing a test that shows the code doesn’t have the capability, and then by adding it?

What if, then, the game would show you its test and its solution, which might be better than yours, or maybe even might not?

Then, when you’re stuck, or tired, or bored with reruns, you could click over to Codele and try a problem. Each problem would be designed to give you a little practice, and most of them would be “teaching” some particular lesson in TDD or refactoring, or whatever “technical excellence” aspect the problem’s creators had in mind.

It wouldn’t be about “technical excellence”. It would be about tiny bits of practice, small learnings, tasty little strawberries of programming pleasure.

Over time, as we played this little game, we’d get ideas for our work. We’d improve our testing and programming skills, we’d find our work easier, and perhaps even begin to find more joy in the work.

That’s Not Possible–Is It?

I don’t know how to create that product, and without support from the Scrum / Agile Industrial Complex, there aren’t the resources to make it happen.

But I do know of some things that are close to it. Here are the mentions from my Jam Session article:

GeePaw Hill has some outstanding videos, in which he focuses in on small lumpy ideas. Amitai Schleier has a delightful 3 minute podcast. Dave Farley has a number of videos relating to continuous delivery. Ted M. Young has videos and more. Clare Sudbery has the Making Tech Better podcast. Bill Wake does live coding and publishes at Xxp123.com. I’m told that Hon Reid is offering TDD in Swift.

I’m sure there’s more out there. I’ve given up seeking funding to create a general repository for such things. The Scrum / Agile Industrial Complex doesn’t have the will to do it. I guess it’s going to come down to people, to individuals and interactions, folx doing their best.

And for Alex, and those like him who are embedded full or part time with teams, I think the thing to do might be to do the occasional “lunch ‘n’ learn” kind of thing where the team gets together for a bit of pizza and sees a demonstration of some technique that the instigator has chosen to be easy to try, and applicable to the team’s work, right now.

One strawberry at a time, custom selected to apply to this team, right here, today. I would hope that the instigator would then separately write up or video their examples that worked, and make them available to the world. But even if it’s just the other three people in the room, it’s worth doing.

Tiny bites of strawberry, little jolts of pleasure, little discoveries to make the day a tiny bit better. We might progress toward greater ease, a bit of pleasure, a feeling of accomplishment, maybe all the way to occasional joy.

Maybe that’s all there is. Maybe that’s all there needs to be.