A piece of advice I heard at a pool table years ago became the lens I use for everything. Here's what a billiards shot taught me about how engineers actually learn.
"Do one thing every day to challenge yourself."
I heard this years ago. Not in a conference talk, not in a book. At a pool table.
Also shared on LinkedIn.
When I was learning billiards seriously, there was one particular shot that destroyed me in every league match, every tournament. Same shot. Every. Single. Time. Didn't matter how well the rest of the game was going — when that shot came up, I missed it.
So I did the only thing that made sense: I spent months shooting nothing but that shot.
Over and over. Watching what happened. Not just when I made it — when I missed it too. Paying attention to where the cue ball ended up, which rails it hit, how the angle changed with different cue power.
Eventually I landed on something specific: at a 72° angle for a back cut, with a medium stroke and a tip and a half of top-right English, I can make the object ball in the corner and get shape for the next ball on the bottom rail. Every time. I'm hitting the object ball with about 35–40% of the cue ball face, and that combination of contact and spin tells me almost exactly where the cue ball will be when everything stops moving.
That sounds like a lot of detail for one shot. It is. But it came from a long time of watching results — successful and unsuccessful — and building an understanding rather than memorizing a recipe.
There are always external variables. How old the cloth is. Humidity in the room. Rail bounce. Shaft deflection. Tip hardness. None of those are in my control.
But because I understand what is happening when I hit that shot — not just that it works — I can adjust for those variables when they're different. The knowledge is portable. It adapts.
That's the difference between learning something and just executing something you were shown.
Here's the thing I noticed after spending months on that one shot: the process I used wasn't unique to billiards.
Hypothesis. Test. Observe results. Adjust. Test again. Repeat until you understand what's actually happening — not just what outcome you want.
That's the scientific method. It's also just how engineers think. And it's also, it turns out, how I approach everything.
Code I've never worked with before. A framework I've never touched. A domain completely outside my background. The shape of the problem is always the same: I don't know something, I form a guess, I test it, I look at what happens, and I keep going until I understand it well enough to adapt.
The challenge stops being scary when you recognize it as a process you already know.
Something shifts after a while. I'm not sure exactly when it happened, but at some point I stopped seeing challenges and started seeing learning opportunities. The frustration doesn't go away — it's still there. But it stops feeling like a wall and starts feeling like a direction. Like a sign that says something worth knowing is on the other side of this.
The other thing that changes: you start seeing it everywhere. The same curiosity that made me spend months on one billiards shot is the same thing that makes me want to tear apart a piece of failed hardware just to understand what happened. The same thing that makes a new library feel interesting instead of overwhelming. It compounds.
Every time I learn something, I can't really unlearn it. It just becomes part of how I see the problem next time.
So here's mine to you: learn something new today. Something that gives you a little friction. Watch what happens when it doesn't work. Watch what happens when it does. Then pass it on to someone else.
The knowledge doesn't do much sitting still.