(2022-01-24) Jeffries Strawberries8 Joy

Ron Jeffries: Strawberries 8: Joy. 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.

we often talk about GeePaw Hill’s notion of “geek joy”, the sheer pleasure of doing that thing that we do. (cf Hacker Ethic)

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.

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

you’ve probably quite often felt frustration while programming. Mental pain, maybe even the physical pain of stress.

The worst thing is that the pain is almost always self-induced. We wrote the code that refuses to work, often just moments before.

There must be a better way. Of course, there is, and it’s all tied up with taking much smaller steps (MMMSS), and moving from working to not working and back to working (Refactor) very rapidly

what we need is greater skill. We can’t just take a skill pill, can we?

Big Deal Learning

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.

We see proponents of “Craft”, good ones like Peter McBreen (time to reread his book), and other proponents who seem perhaps just a bit too intense for most of us.

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

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

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.

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?

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

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. (many other video-makers listed)

• I asked him about TDD kata

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

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