What Basketball Taught Me About Software Engineering

Wed, 07 Oct 2026 00:00:00 +0000

—2" tags: [“tachera”, “software-engineering”, “programming”]

I’ve been playing basketball for about five years, and I’ve been programming for about the same amount of time. I started basketball back in school because I wanted something physical to do. I wasn’t trying to become a professional. I just wanted to get good enough to enjoy playing.

Five years later, I’m still doing exactly that.

And somewhere along the way, I started noticing that the way I play basketball has a lot in common with the way I approach software engineering.

I’m not about to tell you that basketball is a metaphor for life and then put a picture of Michael Jordan underneath it.

These are just things I’ve actually noticed.

I’m 6'1", and apparently I’m supposed to be a big man

At 6'1", people sometimes assume I should be playing forward, grabbing rebounds and doing all the tall-person activities. I don’t particularly care. I like playing point guard. I like having the ball, controlling the pace, finding my teammates, and, probably more than I should admit, dribbling the hell out of the ball.

Give me the ball.

I’ll figure something out.

I pass a lot too. If my teammate has a better shot, I’ll give them the ball. There isn’t much point in forcing a difficult shot just because I happen to be holding the ball.

That part translates pretty directly into programming.

As a point guard, you’re constantly reading the court: who’s open, who’s about to cut, who’s defending badly, and whether I should just embarrass this guy for a second.

Programming is the same, minus the embarrassing part.

Most of it isn’t typing. It’s deciding where a responsibility should live, whether something actually needs another abstraction, whether a problem belongs in the frontend or backend, and whether the thing you’re looking at is actually the bug or just the thing that’s easiest to see.

The code comes after the thinking.

Disclaimer: I talk trash

I enjoy trash talking.

Not because I’m angry. I just think it makes the game more fun.

I’ll tell someone they’re not getting past me. They’ll tell me I’m not scoring. I’ll tell them they’re wrong. Then they’ll try to prove me wrong.

Perfect.

That’s exactly what I want.

I actually like when someone comes at me seriously. I don’t want someone defending me at 60%. If we’re playing, come at me with everything you’ve got.

Otherwise, what’s the point?

There is also a funny switch that happens when I’m playing casually.

Sometimes I’m quiet. I’m barely trying. I’m just messing around, enjoying the game.

Then someone starts talking.

And suddenly:

Oh. So we’re playing for real now.

Now I have a personal project.

For the next fifteen minutes, my entire purpose is to put buckets on this person.

It’s not particularly mature.

It is, however, extremely effective at making the game interesting.

And honestly, I think there’s a useful engineering equivalent to this.

I like problems that fight back.

Give me something where the answer isn’t obvious. Give me a system I don’t understand. Give me a weird bug. Give me something that makes me go down three layers of abstraction just to figure out why something is happening.

Easy problems are nice.

The difficult ones are usually where I actually learn something.

Sometimes I play shooting guard and say absolutely nothing

When I’m not playing point guard, I’ll sometimes play shooting guard.

And I’m much quieter.

I’ll move, find space, defend, shoot, and let the point guard run the game.

I actually enjoy that too.

Because being useful doesn’t always mean being the person holding the ball.

That’s something I’ve had to learn in software as well.

You don’t always need to be the person making the decision. Sometimes someone else understands the problem better. Sometimes another engineer has more context. Sometimes the best thing you can do is take the task, do it properly, and let someone else run the play.

There is no prize for touching every part of the codebase.

I’ve learned that the hard way.

Court vision is basically systems thinking

The better I got at basketball, the less I focused on just the person directly in front of me.

You start seeing the whole court.

If I drive left, what happens to the defender behind me?

If someone helps, who’s open?

If I pass here, what does that create two seconds later?

You’re not just reacting to what’s happening.

You’re trying to understand what happens next.

That’s pretty much how I’ve started thinking about software.

A request isn’t just a request.

It touches an API, which touches a database, which might trigger another service, which might put something on a queue, which might eventually affect something completely different.

Change one thing and something three layers away might suddenly start behaving strangely.

This is why I enjoy systems work.

The interesting part isn’t always the individual component.

It’s understanding how everything interacts.

You will get cooked

Basketball has a very efficient way of reminding you that you’re not as good as you thought you were.

Someone will cross you.

Someone will hit a shot over you.

Someone will get around you so cleanly that you briefly consider changing careers.

It happens.

You can’t spend the next ten minutes thinking about the possession you just lost.

The game is still going.

Programming is the same.

You’ll write terrible code.

You’ll make an architectural decision that seemed brilliant at the time and looks completely insane six months later.

You’ll deploy something broken.

You’ll spend four hours debugging a problem only to discover that the issue was one character.

And yes, sometimes that character is a missing !.

You fix it.

You stare at the screen for a while.

You question your entire career.

Then you keep going.

That’s part of getting better.

Practice isn’t supposed to feel impressive

I practice basketball because I want to be good enough to enjoy playing.

That’s really it.

I don’t want to go pro. I don’t have some secret NBA dream I’m hiding from everyone.

I just like being good at something I enjoy.

The better my handle gets, the more fun the game becomes. The better I shoot, the more options I have. The better I understand the court, the more comfortable I become making decisions.

Programming works the same way for me.

I don’t want to learn Rust because I need to collect another language.

I don’t want to learn Zig because it looks good on a CV.

I don’t want to understand operating systems because somebody told me I should.

I want to get better because understanding more makes building things more enjoyable.

That’s why I keep going lower.

Web apps led me to backend systems.

Backend systems led me to infrastructure.

Infrastructure led me closer to the operating system.

And eventually I found myself writing very low-level code in Zig and thinking:

Wait, so what exactly is the computer doing here?

Apparently I had opened another rabbit hole.

You don’t have to take everything seriously to take it seriously

This is probably the biggest thing basketball has reinforced for me.

I can talk trash, laugh during a game, mess around, try some ridiculous dribble move, and still genuinely care about getting better.

Those things aren’t contradictory.

I think programming can be the same.

I can spend an afternoon writing serious infrastructure software and then spend the evening building some completely unnecessary terminal tool because I thought it would be funny.

I can care deeply about writing good software without treating every bug like a personal attack.

I can want to become a better engineer without turning programming into my entire identity.

The point isn’t to make everything serious.

It’s to care about what you’re doing while you’re doing it.

The part I didn’t expect

When I started playing basketball, I wasn’t thinking about any of this.

I just wanted something physical to do.

When I started programming, I wasn’t thinking about systems engineering, infrastructure, compilers, operating systems, or any of the other rabbit holes I’ve somehow ended up in.

I just wanted to build things.

Five years later, I’m still doing both.

I’m still trying to get better at basketball because it’s fun.

I’m still trying to get better at programming because building things is fun.

And both have taught me that getting better doesn’t mean you stop making mistakes.

It means you start recovering from them faster.

You see more of the court.

You recognize patterns earlier.

You make better decisions.

You know when to pass.

You know when to take the shot.

And sometimes, someone starts talking trash and you suddenly remember that you can actually play.

That’s between me and them.

Here is a video of me playing ball: https://vt.tiktok.com/ZSbVEET2J/

Originally published on Medium.

Lessons on Tachera W Sasi, Backend & Infra Engineer (Go, Self-Hosted, Observability)