From the court to the code
Seven years of professional basketball, then self-taught software. What the transition taught me about learning and building.
I spent seven years as a professional basketball player. Then I taught myself to build software. People treat that transition like a pivot story: dramatic, inspirational, packaged for LinkedIn. It wasn't dramatic. It was slow, messy, and full of false starts.
But it taught me things about learning and building that I don't think I'd know if I'd followed a conventional path into tech.
How I actually learned
In college, I didn't take computer science courses. I printed other people's websites. Lined the pages up next to the browser's Inspect panel. Rewrote the markup. Refreshed. Watched what broke. Changed one thing at a time until I understood cause and effect.
That's still how I learn. Ship something. Watch what happens. Change one variable. Repeat.
My first app was VidSeller in 2008: video shopping, Craigslist meets YouTube. It wasn't good. But it existed, and existence taught me more than any tutorial could have.
What basketball taught me about product
Basketball is a behavior sport. You don't win because you know the plays. You win because your team executes under pressure when the play breaks down.
Software is the same. Your roadmap is the play. Real users are the fourth quarter with the game on the line. They're tired. They're distracted. They're not going to follow your onboarding flow.
Teams that win in basketball practice the fundamentals until they're automatic: free throws, spacing, communication. Teams that win in product practice the same thing: core loops, error states, first-run experience. Everything else is noise until the fundamentals hold.
The identity problem
Career transitions create an identity vacuum. For years, I was "Court the basketball player." Then I was nobody's category. Not an engineer by credential. Not a founder by pedigree. Not a consultant by training.
That vacuum was uncomfortable. It was also useful. Without a label, I had to prove value through work: apps shipped, problems solved, things built that people actually used. I couldn't hide behind a title.
I think that's why I became a practitioner instead of a pundit. I didn't have the option to advise from a distance. I had to build to eat.
Self-taught doesn't mean self-made
I want to be honest about this: self-taught doesn't mean I figured everything out alone. I had mentors who answered emails at midnight. Founders who let me watch them struggle. App Store rejections that humiliated me into learning policy. A family business that needed technology whether I was ready or not.
Curiosity got me in the door. Community and repetition kept me there.
What I'd tell someone making a similar jump
- Build something ugly that works. Perfection is a delay tactic.
- Learn in public, but build in private. Share what you're learning. Ship when it's ready enough.
- Find one hard problem and stay with it. Depth beats breadth early on.
- Your previous career is not baggage. It's a lens nobody else has.
I'm still transitioning, in a sense. Still learning. Still building things that don't work the first time. The court taught me that mastery is a direction, not a destination. Code works the same way.