On the padel court, the shot that wins the point is almost never the one that looks good on video. It is the one that keeps the ball in play one more second than the other side can handle.
I started playing padel a year ago, badly, and I am still not good. But I noticed something within a few weeks that took me much longer to notice in software: the players who win are not the ones hitting the hardest. They are the ones who almost never miss.
The smash is a trap
Every beginner, me included, wants to hit the smash. The ball sits up nicely, the glass wall is right there, and for one second you feel like a professional. The problem is that the smash has a narrow window. Hit it a little early or a little late, a little too flat or too steep, and it either flies out or lands soft in the other team's hands as a free point.
My coach's advice was blunt: most points are not won by force, they are lost by mistakes. So stop trying to end the point early. Hit the boring shot, the one down the middle with margin over the net, and make the other side be the ones who take the risk.
That sentence rearranged how I think about a lot of decisions that have nothing to do with sport.
Most bugs are not lost, they are given away
I used to associate good engineering with clever engineering. The elegant one-liner, the custom cache, the framework I wrote myself because the existing one felt too heavy. Clever code is the smash: it looks great when it lands.
But almost every production incident I have caused came from a shot I did not need to attempt. A clever migration I ran manually instead of through the boring, already-tested script. A shortcut around validation because I was sure the input would always be clean. A new dependency added to save twenty minutes, now costing hours every time it needs an update.
None of those were defeats handed to me by a hard problem. They were unforced errors, the same as a smash into the net. The fix was never a cleverer trick. It was giving myself more margin: validate the input anyway, run the boring script, skip the dependency.
Agents play the same way I do
Working with coding agents on side projects made this even more obvious. Left alone, an agent will often reach for the smash: the biggest possible refactor, the new abstraction, the rewrite of three files when one small patch would do. It looks impressive in the diff and it is exactly where mistakes hide.
The instructions that actually help are the boring ones. Change one thing. Keep the existing pattern even if you think you have a better one. Do not touch files outside the task. Run the tests before calling it done. None of that is exciting to write, and none of it reads like a clever prompt. It is just margin over the net.
When I skip those boring constraints because the task feels small, I get the same result as skipping validation in my own code: it mostly works, until the one time it does not, and then I am the one cleaning it up.
Margin is not the same as fear
I want to be careful here, because there is a lazy version of this lesson: never take risks, never ship anything bold, always play it safe. That is not what my coach meant and it is not what I mean either.
You still go for the smash when the ball sits up perfectly and the point is actually there to be won. The difference is you take that shot because the opportunity is real, not because you are bored of rallying. Most of the time the right move is the shot that keeps you in the point, not out of it.
The same goes for a codebase. Ship the bold feature when it matters. But write the function underneath it the boring way, with the validation, the error handling, and the small, reviewable diff. Save the ambition for the part where it is actually needed.
Still losing, slightly less often
I still lose most of my padel matches. I still ship bugs. Neither of those facts changed overnight because of one lesson about margin. What changed is smaller and quieter: before I hit the flashy shot, on court or in a pull request, I ask myself whether I am taking it because it is actually open, or because I am tired of playing it safe.
Most of the time, the honest answer is the second one. And most of the time, the boring shot down the middle is still the one that wins the point.
