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
- 684From Carrier Networks to the Cloud: What 20+ Years Taught Me About Infrastructure CostsWhy carrier capacity was capital, what a server really costs when you carry it, how call statistics improved least-cost routing and why the cheapest route loses money, how the cloud turned capital into consumption, why people and process are infrastructure costs too, the founder’s questions that changed how I decide, and the seven-layer figure that puts it on one page.
- 683The Hidden Cost of Software Architecture: Why Scaling Too Early Is ExpensiveHow microservices multiply the things that cost money, why Kafka is also a team, when managed services stop being cheaper than self-hosting, where the database leaks money, what scaling for users you don’t have costs, and the five inputs and three decisions I use to connect architecture to operating expense.
- 682Capacity Planning: What Carrier Networks Taught Me About Scaling Cloud InfrastructureForecasting carrier network capacity from measured utilization across 2,000+ collocations, planning VoIP servers behind millions of minutes a month, choosing media paths by caller location to improve quality and cut bandwidth cost, moving a platform from one data center to cloud regions as capacity followed revenue, and bringing a publishing platform’s AWS bill down by about 30%. Plus why engineering capacity is the constraint most dashboards miss.
- 681From DOS to AI: Watching the World Change, One Decade at a TimeDOS and Windows 3.1 on a 486, dialing into BBSs, IRC and mIRC, AOL bringing everyone online, dial-up giving way to DSL and cable, VoIP and Nokia apps, 3G to 5G, fiber, cloud, and now AI. What stayed the same underneath, and why the only durable skill is learning the next thing.
- 680I Used to Think Getting Better Meant Working HarderProgress in the gym takes time, Spartan courses punish narrow strength, cycling proved that riding slowly can make you faster, recovery is part of training, and coming back from a broken collarbone, a work-eaten season, a life event and this year’s surgery is its own discipline. Plus the club, the team and the juniors, and what all of it changed about how I lead.
- 679I Was Working on Network Security Long Before DevSecOps Was a ThingSecurity as a thread through a whole career: router ACLs in carrier operations, one of the first three people supporting a NetScreen managed firewall service, training the TAC, then AAA on voice platforms, authentication and authorization in applications, mobile apps as untrusted clients, IAM and Terraform in the cloud, federal security requirements, and what it means to lead with security as a release gate. With a staged timeline and a layer-by-layer explorer.
- 678Before the iPhone Took Over, We Were Building VoIP Apps for Nokia PhonesWhy a VoIP service for immigrants calling home went onto Nokia phones instead of the iPhone, what Symbian C++ development was like, how a handset talked to an Asterisk and OpenSIPS backend over bad mobile data, and the lessons about customers and constraints that outlasted the phones.
- 677I Used to Design Every Screen MyselfBeing the designer by default at a bootstrapped startup, the assumptions that turned customers away, what readers, residents and drivers taught later, how I design with an AI assistant now, and the five things that haven’t changed about building for the person using the system.
- 676I Used to Build Everything MyselfBuilding a bootstrapped communications startup by hand, the open-source VoIP stack and the failures it taught, how AI-assisted development changed the way I build FedPath, Useful Little Tools and client work, and the six things that haven’t changed.
- 675Founding a Startup Isn’t Easy, but the Experience Is PricelessBootstrapping with very little money, being the field technician, network engineer, sysadmin, developer, architect, designer, product manager and support desk at once, learning under pressure, the first paying customer, what profitability changes, why not every founder gets rich, and how it shaped me as an engineering leader.
- 674Why Smaller User Stories and Pull Requests Make Better Engineering TeamsWhy oversized stories produce oversized pull requests, how smaller stories improve planning and prioritization, how smaller PRs improve review and quality, why smaller releases shrink the blast radius, individual speed versus team throughput, and how product and engineering share the job.
- 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.