Mostly reflections on engineering, basketball, hackathons, leadership, and the occasional moment where something finally clicked after breaking three times first.
Junctn wasn't a blank-slate build — it had to fit into an advisory org that already ran on habit and spreadsheets. Notes on the four features that only made sense once we saw where the real workflow broke.
Losing hurts less when you realise growth isn't measured by trophies alone. Some thoughts on almost-winning, pressure, and why I still keep showing up to hackathons anyway. Or maybe it's because of my team name: Gunners!
Leadership, accountability, communication, trust — it turns out the same things that win games also make teams build better software.
After spending too much time fixing flaky tests, I started questioning whether selectors were the problem in the first place. Some lessons from building testing tools with vision models.
Hackathons aren't really about caffeine or all-nighters. They're about making good decisions quickly, cutting scope aggressively, and learning when “good enough” is actually enough.
Two AI agents arguing over a stock sounds funny until you realise how much engineering it takes to make the system reliable, useful, and fast enough to run every day.
Building something quickly is one challenge. Supporting real users afterwards is a completely different sport.
Some parts of the syllabus aged surprisingly well. Others made a lot more sense only after building real systems and breaking them myself.
More entries eventually. Currently allocating most system resources to university, projects, and not destroying my knees.