I’ve been thinking a bit about rowing recently and, as always, a lot about software.

I bought a rowing machine before Christmas and I’ve been learning how to use it properly. It has been fun—though the standards are low when you’re confined to a 5km radius during a worldwide pandemic—and it tickles some of the same parts of my brain that swimming does.

I’m very much a beginner so the rowing knowledge here is probably at the “well, duh!”-level for anyone that’s used a rowing machine for a while. For anyone who hasn’t, it might be surprising…

Fair warning: I’m going to make an analogy between rowing and software development. If exercise-based analogies make you queasy, please depart the boat now…

The hidden effort in Rowing

Indoor rowing looks like this…

via Gfycat

You start in the catch position, push with your legs, lean back slightly, and pull with your arms; then you recover and do it all over again. A stroke is each cycle from the front position, pushing out, and then back again.

The monitor counts our strokes and gives us a “stroke per minute” (SPM) metric: The higher your SPM, the faster you’ll be moving up and down that rail.

This motion of sliding up and down the rail is the visible action of rowing. It’s the very obvious, visible output of the exercise.

How do you go faster? Raise your strokes per minute of course!

If you’re banging up and down that rail at 34 strokes per minute you’re going to look like a badass. Everyone can see you’re going really fast.

Except…

The point of rowing is not to be sliding up and down the rail at fast as possible. Our aim is to move a boat as fast as possible (albeit, a fictional one). Luckily the monitor also gives us data about the speed of our boat.

Here’s the surprising thing: moving faster up and down the rail might make the boat go faster, or it might not, or the boat might stay the same pace.

Huh?!

The sliding up and down, the strokes per minute, is the visible effort. The invisible effort is the power the rower is producing with their legs. It’s how strong their core is, how efficiently they can translate the force from their legs into the movement of the oars. It’s probably fast-twitch muscles, and muscle control, and flexibility, across many muscle groups, and tons of other biomechanics I have yet to understand.

To an outside observer, a rower doing 30 strokes per minute is going faster than the rower at 24spm. It’s not true though. The rower at 24spm might be putting in much more power with their legs, which is causing their boat to go faster.

I know this. I’ve been following along a couple of workouts and training courses and they often get you to row at a specific stroke rate. One early session was 5mins at 24spm, and I could match the instructor stroke for stroke. Spot on! Did I row the same distance as he did? Hell, no! He’d done about 500m more than me and I was confused.

Over more training sessions, we started playing a lot with stroke rates. Doing things like 2mins at 16spm (horribly slow), then 20spm, then 24, 28, and finally 32. Sometimes we’d have to keep a steady pace (the speed of the boat) even as the stroke rate rose. That’s hard, weird, and all sorts of weird… if you only think about the visible effort. It was worth it for learning about the hidden effort.

I know now that when I focus on my legs, I can slow my stroke rate down and increase my pace. I can go faster whilst looking like I’m going slower. I can look like I’m putting in less effort but I’m actually putting in more hidden effort.

There’s another hidden thing going on here, which is the drag factor level on the side of the fan. Push that to 0 and it feels like yeah, skipping across the water. Like you’re rowing in a simulation that doesn’t understand the resistance of water. Or you can whack it up to 10 and it feels like you’re rowing a Currach in a force 10 gale in the Atlantic. That’s the hidden resistance, not visible to an outside observer.

Alright, enough about the rowing and the rather laboured depictions!

Software

I think this idea of visible and hidden effort translates into software.

We see the visible effort. We tend to see the UI. We see the features that ship. We see the user interfaces that are implemented. We get notifications about tasks completed and tickets moved to “Done”. And sometimes, if you’re on the technical side, you might see the code. Sometimes there’s a lot of code, often there’s not much.

We don’t see the hidden effort. We don’t see the day that was spent debugging one line of code, or understanding the state of one attribute. Or fixing a problem with an external library. Or simply reading the existing code you understand where to wield our surgical knife to insert our feature. We don’t see the two week dead-end the developer went down before encountering some major problem.

I think it’s important to recognise what’s visible and what’s hidden.

Push harder

So the visible effort is visible and the hidden effort is hidden. That’s hardly a revelation!

Here’s where I’m going: to get better, we need to focus on the hidden effort, not the visible effort.

When we focus on the visible effort, we celebrate it, we encourage it. It’s natural that when we elevate the visible effort to such a high level that developers need to be reminded to push harder on the hidden effort.

I think sometimes it’s not about asking developers to ship the feature faster. That’s just asking to see the visible effort. Oftentimes I find myself asking people to push hard on the hidden things. Make this faster; make that more secure; rework this to make it easier to understand. Inevitably I’m saying, “push harder on this thing—I value this thing—even though it’s not the most visible artefact”.

What’s visible isn’t the same for everyone. Ironically, the visual elements like the precise styling of a button are something that’s hidden to me. I just don’t notice them like a good designer or frontend developer does.

Different organisations make different things more visible than others. If you celebrate feature shipping with big announcements and parties but site performance doesn’t even get a public dashboard, then shipping features is the only visible means of progress. To counter that, you need different people who will insist on, advocate for, push for, and celebrate hidden effort.

Photo by Victor Freitas on Unsplash