Section650
Writing
Things I’m learning, building, riding and testing.
Some of it is about work, and a lot of it isn’t. Usually I write because I wanted to understand how something works, or because I learned something on the bike that I don’t want to forget.
Reading paths
- 673Why Hiring Is So Hard, and Why Interviews Don’t Tell the Whole StoryPredicting years from a few hours, what resumes and ATS filters miss, why interviews measure interviewing, what coding tests leave out, reading references for context, the “what would you ask?” question, the real cost of a bad hire, why good hires fail in bad organizations, managing people, building a team rather than collecting talent, and the candidate’s side of the evaluation.
- 672Good Engineering Teams Don’t Expect Everyone to Know EverythingWhat to expect from engineers at different experience levels, why experience doesn’t replace clarity, smaller pull requests and stories, acceptance criteria, saying what actually happened, reviews and documentation, distributed teams, and the habits I encourage.
- 671I Still Look Up Syntax. So I Started Building My Own Developer Tools.Why I still look up Git, Docker and SQL syntax, how bookmarks, Stack Overflow and AI assistants each fell short, the repeat searches that became Useful Little Tools, what building a tool teaches, and why I keep them small.
- 670Specialization Shouldn’t Stop at Understanding Your Own CodeDepth versus breadth, “the API works” versus a working product, what frontend and backend engineers each need to know about the other, evidence-based bug reports, developer quality of life, client versus server responsibilities, and how leaders create silos.
- 669API Architecture: What Building and Operating Real Systems Has Taught MeDesigning for consumers and workflows, choosing REST, GraphQL or gRPC, boundaries and ownership, backward compatibility, object-level authorization, idempotent retries, asynchronous work, performance, operations, cost and a decision checklist.
- 668Event-Driven Architecture with Kafka: Should Systems React to Events Instead of Calling Each Other Directly?When to call directly and when to publish, facts versus commands, topics, partitions and replay, eventual consistency, the dual-write problem and outbox, what exactly-once covers, coupling through events, the total cost of Kafka, and a leadership checklist.
- 667How I Decide Whether a Microservice Should Actually Be a MicroserviceThe questions I ask before splitting out a service, what happens to the data, the distributed monolith trap, when a modular monolith wins, and what it really costs to own a service for five years.
- 666What Open Source VoIP Taught Me About Distributed Systems Before We Called Them Distributed SystemsHow signaling, call handling, AGI business logic and billing split one call across boundaries, a hypothetical double-charge failure, routing as a business decision, why retries need context, reconciliation, and what modern tools do and don’t change.
- 665Software Architecture Through the Years: What Different Systems Taught MeTelecom and the whole call path, publishing and business-shaped architecture, the case for monoliths, what microservices and Kafka really cost, how team size changes the answer, and why boring architecture often wins.
- 663From Expect Scripts to AI Agents: How DevOps Changed During My CareerExpect and ksh in a NOC, what that taught me about operations, how Jenkins, Docker, Terraform and Kubernetes standardized the work, what AI can automate in DevOps now, the guardrails I’d insist on, and the skills that outlast every tool.
- 662Your Team Size Should Influence Your ArchitectureThe ongoing cost of every service, a hypothetical five-person team weighing twelve services, the modular monolith as a deliberate choice, when separation earns its cost, and the triggers that should reopen the decision.
- 661What Being a CTO in Publishing Taught Me About SEO, and Why AEO and GEO Matter NowContent as product and channel, search intent, technical SEO as engineering work, decisions that cost traffic without anyone noticing, social cards, measuring more than traffic, and what I’m learning about AEO and GEO.
- 660What Organizing Berkeley Omnium Taught Me About Leading TeamsShared purpose, volunteer time as a real constraint, naming an owner, letting the race date decide scope, why finished tasks don’t make a ready event, and the work that continues after the finish.
- 659What Cycling Taught Me About Engineering LeadershipSustainable pace, riding predictably in a group, taking a turn at the front, preparing for changing conditions, meeting junior riders where they are and leading volunteers without authority, plus where the analogy breaks down.
- 658The Most Expensive Engineering Work Is Work Nobody NeededWhy on-time delivery doesn’t prove value, how unneeded features get built, separating a request from the real need, three hypothetical examples, and eight questions to ask before committing a team.
- 657How to Connect Strava to Claude with MCP: A Step-by-Step GuideSetting up Strava’s official, read-only MCP connector in Claude or Claude Code, then putting it to work: prompts for volume, intensity, climbing and race prep, and what it can’t do.
- 656From an Idea to an Acquisition: What Building a Startup Taught MeCo-founding and building a global communications company: 0→1 with incomplete information, when reliability becomes the product, 1→10, learning to delegate, technical debt as an investment, and an acquisition.
- 655What Sprint Carryover Is Actually Telling an Engineering TeamThe six causes behind most sprint carryover, what each one is telling you, how to record the reason instead of just the number, and the common fixes that make the number look better without improving delivery.
- 654When Everything Is a Priority, Nothing Is: Leading Engineering Through Constant ChangeWhat a priority change really costs a team, why constant change leads to more half-finished work, how to make the tradeoff explicit, and the five things I make clear every time priorities shift.
- 6522027 Berkeley Omnium: A New Website and Building the Next Generation of CyclistsThe new berkeleyomnium.com, what bike racing teaches young riders, why local racing takes a whole community, and how to sponsor the 2027 Berkeley Omnium.
- 651You Don’t Need to Remember Everything to Be a Good Software EngineerWhy I still look things up after two decades in software, the difference between memorizing syntax and understanding systems, and what that means now that AI can retrieve almost anything.
- 650My First Three Bike Races: Race Reports From a Novice SeasonHow I got from struggling on club rides to a start line, race reports from the Livermore Criterium, Cherry Pie Criterium and Snelling Road Race, and the lessons I took from them.