[UN]

I started with Scratch.Then I kept following whatever looked interesting.

I am a software engineer in Houston. The part I keep coming back to is understanding why a system behaves the way it does, especially when the problem is messy and nobody fully owns the whole picture yet.

Udenna Nebeolisa hiking in the woods

Always drawn to computers

The curiosity came before the code.

Udenna using a computer as a child
Long before it became a career

Computers had my attention long before I knew programming could become a career. That interest became hands-on in 6th grade, around 2012, when I found Scratch. From there I kept following whatever looked interesting: bash scripts, game mods, Cheat Engine, VB.NET, and the tools people were using in those communities. By high school I was deep into Roblox scripting and poking at Unity, learning by pulling things apart, reading unfamiliar code, and shipping things for real players.

How it unfolded

The work got more real. So did the consequences.

  1. Went to bootcamp, co-founded Stooty, shipped to the App Store, and joined JPMorgan Chase.

  2. Worked on high-volume trading systems at JPMC. That was where I started thinking more seriously about Java microservices, production constraints, and what reliability actually costs at scale.

  3. Left to build independently: client sites, product experiments, and the kind of work where you own the outcome end to end.

  4. Built across contracts: a production rank-management API for a Roblox experience with 150M+ game visits, POS-adjacent work for small businesses, and LLM pipeline work.

  5. Spent more time in the overlap I care about most: backend systems, AI tooling, product sense, and reliability.

  6. Looking for the next environment where I can bring more range than I had the first time around: enterprise systems, client work, product builds, and production AI.

What stayed with me

The lessons were bigger than the stack.

Systems

Enterprise work taught me to stop looking at just the endpoint in front of me. The interesting part is usually how the whole thing behaves under load, across teams, or after a small assumption breaks.

Questions

When I hit a hard problem, I usually slow down first. I read docs, compare approaches, sketch things out, ask AI or other engineers, and let the problem sit. That tends to work better than forcing a clever answer.

Ownership

Freelancing and building my own products taught me that code is only part of the job. The real question is whether the thing works, makes sense, and survives handoff.

Away from the keyboard

Still learning with my hands.

Two hikers walking along a wooded trail

Muay Thai

training

Rhythm, timing, and staying calm when the reps get ugly.

IS300

building

Tein Flex Z coilovers, Truhart rear toe arms, and a long-term turbo build plan.

Skateboarding

practicing

A reliable way to stay humble and keep trying again.