Engineering coverage in this archive spans 53 posts from Jan 2016 to Jan 2026 and treats engineering as a production discipline: evaluation loops, tool boundaries, escalation paths, and cost control. The strongest adjacent threads are teams, architecture, and ai. Recurring title motifs include engineering, ai, team, and debt.
Reliable agents aren't prompted into existence. They're engineered -- with bounded tools, validation at every step, explicit recovery paths, and the same discipline you'd apply to any production system. Here's how I build them in Go.
AI debt doesn't look like normal tech debt. It hides in prompts nobody owns, evals nobody runs, and data pipelines nobody watches. By the time you notice, every change feels dangerous.
Individual AI speedups are a distraction. The real gains come from treating AI as team infrastructure -- embedded in docs, decisions, and onboarding.
I used LLMs to help migrate a 200K-line Go codebase. The mechanical parts went fast. Everything else was still hard.
Responsible AI is not an ethics committee. It is operational risk management, and teams that treat it otherwise are building liabilities.
AI features create a new species of technical debt that hides in prompts, data pipelines, and model versions. By the time you notice it, the cleanup bill is brutal.
Everyone's complaining about LLM costs. Almost nobody has done the basics: caching, model routing, or even measuring what they're spending per feature.
AI safety is not a philosophy problem for engineers. It is reliability, security, and accountability applied to a new kind of system.
ChatGPT changed expectations overnight, but shipping AI features that actually work is an engineering problem, not a model problem.
Most engineering documentation is ignored for predictable reasons. Here is how to write docs that people actually read.
Everyone thinks hybrid is the compromise between remote and office. It is actually harder to get right than either extreme.
After running a remote-first company for years and watching everyone else scramble through COVID, here's what I've learned actually works -- and what doesn't.
Lines of code, velocity charts, commit counts — most developer productivity metrics are garbage. DORA metrics are the only ones worth your time.
Whiteboard coding over Zoom is broken. Here's what I do instead when hiring engineers virtually.
Most teams claiming to work remotely are just recreating the office over video calls. Async communication is the actual unlock, and almost nobody is doing it right.
Most BCP documents are shelf-ware written by consultants. Here's what actually keeps engineering teams running when everything breaks.
COVID forced your engineering team remote overnight. Here's the no-fluff version of what actually matters in the first two weeks.
Most engineering onboarding is a polite abandonment ritual. Here's what I've learned building onboarding across three startups about what actually gets new engineers shipping fast.
Most data problems are ownership problems. Data mesh gets that right. But adopting it as an architecture diagram exercise misses the point entirely.
Most teams shouldn't be migrating to microservices. Here's how to tell if you actually should, and how to do it without wrecking your delivery for eighteen months.
Staging never catches the real bugs. Here's how I learned to test in production without burning everything down.
Most SLOs are dashboards nobody acts on. Here's how to pick indicators that reflect real users, set targets grounded in data, and make error budgets actually change how your team ships.
Failure is not an edge case. It is the default state you temporarily hold off with good engineering. A few hard-won rules for building systems that bend instead of shatter.
Most internal developer platforms fail not because they're technically bad, but because nobody treated them like a product. Thoughts from building (and scrapping) platform tooling across three startups.
How to introduce TypeScript to a real JavaScript codebase incrementally, without halting product work or annoying your entire team.
A framework for cataloging technical debt, scoring it by impact and risk, and scheduling paydown without stalling feature delivery.
Lessons from growing an engineering org at the fintech startup -- what breaks, what works, and why clarity beats process every time.
Most code reviews are theater. Here's how we fixed ours at the fintech startup and what actually made a difference.
Most technical interviews test the wrong things. After hiring engineers at the fintech startup, here's what I've learned actually predicts job performance.
What backend engineers actually need to know about ML in production -- from someone who builds NLP pipelines for financial news.
Reflections on standing up the fintech startup's platform team in 2017 — what worked, what didn't, and why treating infra like a product changed everything.
A two-number scoring system for tech debt that tells you what to fix now, what to schedule, and what to quietly accept.
Most code reviews are theater. Here's what actually makes them worth the time.
Two leadership tracks, one fork in the road. A breakdown of what engineering managers and tech leads actually do day-to-day, based on how we structured it at the fintech startup.
You can't afford a security team at a startup. But you can turn one motivated engineer per squad into a security champion — and that changes everything.
Nobody handed me a leadership mandate at the fintech startup. I had to earn it through credibility, clear communication, and doing the unglamorous work that moved things forward.
A personal look back at what mattered in 2016 -- Docker going mainstream, Kubernetes momentum, Go adoption, and lessons from building at Dropbyke and a fintech startup.
What a year of building an engineering team at Dropbyke taught me about hiring, trust, and the habits that actually matter.
How Go became the default backend language at Dropbyke and a fintech startup, what it replaced, and the honest tradeoffs we accepted along the way.
A production-grounded case for exhausting single-server headroom with pooling, replicas, and partitioning before taking on sharding complexity.
Security culture is not a training program or a tool purchase. It is a set of habits that leadership enforces through consistency, not speeches.
Too many developers treat the network as magic. It bites them in production every time.
A practical guide to evolving schemas without maintenance windows by keeping old and new code compatible at every step.
You cannot outpay Big Tech, but you can outshine it on impact, growth, autonomy, and clarity. This is how to hire great engineers with a startup offer in 2016.
Production incidents show where architecture bends and where it breaks. These lessons focus on designing for failure, limiting blast radius, and making recovery routine.
Most startups have no business running their own servers. The math is not close.
Continuous deployment is not a tooling problem. It is a discipline problem. We deploy the Dropbyke backend dozens of times a day because we built habits first and automation second.
A practical incident response playbook for small teams: define incidents, assign owners, contain fast, investigate calmly, and recover with clear communication.
Lessons from building the fintech startup's financial data API: the REST conventions that actually matter, the ones that don't, and why consistency beats cleverness every time.
A grounded look at PostgreSQL and MySQL as of April 2016, focusing on integrity, query power, and operational tradeoffs rather than benchmark hype.
DevOps is a cultural shift, not a job title. This post lays out a practical, 2016-era path to shared responsibility, fast feedback, and resilient delivery without hand-wavy promises.
A pragmatic look at technical debt in 2016: what it is, how it shows up, how to measure it, and how to make a business case for paying it down without stalling delivery.
Most teams adopt microservices too early and pay for complexity they don't need yet. A well-structured monolith is faster, simpler, and keeps your options open.