Reflections emerged from learning to deadlift
Many years ago, I decided I wanted to get really good at deadlifting. I can’t quite remember why, but at some point I thought: women who lift heavy are pretty badass. And I wanted to be badass too.
At first, I thought the deadlift would be simple. You just pick up a barbell from the floor, right? But like many things that look simple on the outside, the deeper I went, the more complex it became. Hip hinge, grip, bracing, bar path, leverages — all of it mattered. And because I tend to get nerdy when I learn something, I didn’t just practice in the gym. I was simultaneously watching endless of tutorials, reading articles and forum threads, and even rehearsing the hip hinge and the feeling of a proper lift without a barbell. Yes you would find me pretending to deadlift everywhere – at work, at home, in the grocery shop.
The more I dug in, the more I realized how much my progress depended on the feedback I was getting. Sometimes it came instantly, sometimes much later — but the faster and more diverse the feedback, the quicker I learned. I was starting to see some parallels connected to my profession – it reminded me of the feedback loops in software development and testing.
Reflection 1: Not All Feedback Is Useful
One of the first “feedback tools” I tried in the gym was the mirror. It gave me an instant reflection of my movement, which sounded useful in theory. In practice, though, it wasn’t reliable at all. To check myself, I had to turn my head or shift my focus — and that immediately changed my form. The feedback was there, but the very act of observing interfered with the movement.
Software has its own “mirrors”. Sometimes we interact with a system and it looks fine — the page loads, the button clicks, the response comes back — but that doesn’t mean it’s really working the way we expect.
The feedback can be shallow, or even misleading. Other times we add log statements or quick checks that give us a sense of what’s happening, but only from a narrow angle. Just like the mirror in the gym, these signals can create an illusion of confidence while hiding what’s really going on. The real value comes when we go deeper and investigate beyond what’s immediately visible.
Reflection 2: Fast Feedback Accelerates Learning — Especially with Multiple Inputs
Recording myself in training sessions became a turning point, even if it felt really awkward at first. With video, I could almost immediately see what had happened and adjust in the very next set. That kind of instant loop accelerated my learning curve enormously.
But the video wasn’t the only input. Sometimes I could feel something was off — maybe my balance shifted, or the bar drifted away from me. That sensation alone didn’t always tell me why it happened, but the video often did. And the best feedback of all? A coach standing right beside me, shouting cues in the middle of the lift — “brace more!” or “push the floor away!” That was immediate, specific, and actionable
Testing is similar. We learn fastest when feedback is both fast and comes from multiple angles:
- The system itself giving you signals (logs, responses, performance “feel”).
- Tools that capture and replay what happened (recordings, traces, automated checks).
- A colleague or peer review pointing out what you might have missed.
- Pairing with a colleague to give a richer perspective of ideas and feedback on your own thoughts.
- …
One perspective rarely tells the full story. It’s the mix of inputs that accelerates learning.
Reflection 3: Interpretation Unlocks the Value of Fast Feedback
Here’s an interesting note: when I first started lifting, I wouldn’t have known exactly what to look for in a video. A rounded back or hips rising too fast didn’t mean anything to me until I had learned what good looked like. Fast feedback was only useful once I had the knowledge to interpret it.
It was similar to when my testing team was asked to explore the product for security risks. They were skilled testers, but security testing was not our area of deep expertise. We could follow guidelines, try common attack patterns, and note down the responses we got — but we didn’t know whether what we were seeing was truly a vulnerability or just expected system behavior. Even when we followed recommendations from checklists, we were left wondering: Is this a real threat, or just noise?
What we really needed was someone who could interpret the signals with expertise — a security specialist who could look at the same output and say, “Yes, this is dangerous,” or “No, this is fine.” Without that, the fast feedback we were generating didn’t translate into learning. This reminded me of the feedback I got from the coach, an expert on deadlifting. So once I had learned what to look for I could make sense of my videos.
Speed matters enormously — but it only accelerates learning if you can make sense of what’s coming back.
Reflection 4: We Can Shape the Loops
As a lifter, I learned to adjust my loops. Filming myself gave me near-instant replays. Writing a training journal and reviewing previous recordings helped me see trends across months. Without those adjustments, my progress would probably have been slower.
Sometimes, I even shaped the lift itself to get more feedback. Slowing down the movement — adding pauses at the knees, or deliberately descending very slowly — gave me more time to feel what was happening and notice where my position was breaking down. It wasn’t about moving more weight, but about creating a training scenario where I could learn more from each rep.
In software, we also have the power to shape our feedback loops. We can choose what to observe, how to surface information, and how quickly we get it. Sometimes that means speeding things up — shortening build times or adding logging — but sometimes it means slowing down on purpose. Taking time to explore step by step, to add more observability, or to walk through a workflow carefully can reveal details we’d miss at full speed.
The goal isn’t just to get feedback faster — it’s to design feedback that accelerates learning.
Closing Reflection
Software testing, like lifting, are practices that can look easy from the outside. To someone watching, it may seem like a tester is just “randomly pressing buttons.” But underneath, there’s intention: forming hypotheses, observing carefully, connecting signals, and adjusting based on feedback. Sometimes that means repeating a scenario to learn more, sometimes it means trying a completely new approach.
Of course, there are huge limits to the analogy. Deadlifting is more of a physical skill where I train my body to move well and stay strong. Testing is a cognitive skill where I train my brain to form , notice patterns, challenge assumptions, and explore risk. But the small parallels circles around the need for feedback: both require listening carefully — to your body or to the system — and using that information to adjust.
When feedback is fast, you accelerate not only your progress but also your ability to adapt. Whether it’s correcting a mistake, fine-tuning a movement, or exploring a new path, quick feedback shortens the time between action and adjustment. It gives me the ability to spot patterns faster.
And that’s the real carry-over. Under the barbell or inside a product, progress comes from designing and using feedback loops that are fast enough to guide the next step, diverse enough to reveal different perspectives, and deep enough to provide value.
Deadlifting and software testing look completely different on the surface, but at their core they are both ongoing practices of learning — ways to continuously explore, learn, adjust, and improve.
On a side note I actually don’t do conventional deadlifts any longer.
Curiousity killed the cat 