Engineering Reads — 2026-07-04#

The Big Idea#

As AI drives the marginal cost of writing code to zero, the core bottleneck of software engineering is shifting entirely from generation to validation. Organizations that fail to build rigorous, unified observability and fast feedback loops will find their systems rapidly collapsing under the entropy of machine-generated code.

Deep Reads#

New, faster NA · Brett Terpstra Brett Terpstra details the rewrite of na, a command-line todo manager for TaskPaper files, from Ruby to Rust. The core motivation was eliminating the interpreter boot latency that made Ruby poorly suited for prompt hooks executing on every directory change. The Rust port achieves behavioral parity with the original gem while providing near-instantaneous execution, proving that sometimes rewriting for performance is functionally transformative. It’s a compelling case study for CLI developers on how language startup costs directly impact user experience in shell environments. Engineers building developer tools should read this to understand when to graduate from scripting languages to compiled binaries.

Web Excursions for July 4th, 2026 · Brett Terpstra Terpstra curates a list of niche productivity tools for macOS and iOS, emphasizing focused, native applications over bloated platforms. The selections range from single-purpose utilities like Senqu for image compression to more involved UI experiments like PowerHouz, which wraps HomeKit automation in a sci-fi interface. He also highlights utilities that optimize developer workflows, such as Paste Switch for cycling through recent clipboard items and Notchkin for utilizing the display notch. While light on deep technical architecture, the roundup serves as a reminder of the thriving indie software ecosystem. Mac power users and front-end developers should read this for inspiration on building tightly scoped, highly polished utilities.

In Praise of “Normal” Engineers · Charity Majors Majors dismantles the “10x engineer” myth, arguing that the smallest unit of software delivery is the team, not the individual. True engineering excellence is achieved by building sociotechnical systems—like fast deploy pipelines and robust guardrails—that allow normal, workaday engineers to ship safely and quickly. Relying on heroics or recruiting exclusively “elite” talent creates brittle monocultures and single points of failure. By optimizing for cognitive limits and providing heavy instrumentation, organizations can abstract away process complexity so developers can focus purely on business logic. Engineering leaders should read this to shift their focus from talent acquisition to platform enablement and systemic resilience.

Thoughts on Motivation and My 40-Year Career · Charity Majors In this deeply personal reflection, Majors traces her trajectory from a sheltered fundamentalist upbringing to tech leadership, examining how her motivations evolved. She argues against the modern cynicism surrounding work, positioning the tech industry as a powerful vehicle for personal liberation, intellectual growth, and economic mobility. Transitioning from engineering to management and eventually founding a company forced her to reconcile rigid ideological purity with the pragmatic realities of building enduring institutions. The piece champions the radical act of being an “institutionalist”—building systems of value rather than just tearing them down. This is essential reading for mid-career technologists grappling with burnout, legacy, and the search for purpose in a corporate landscape.

How We Migrated the Parse API From Ruby to Golang (Resurrected) · Charity Majors Majors unearths a 2015 retrospective detailing Parse’s grueling API rewrite from Ruby on Rails to Golang to handle asynchronous scaling. The fundamental architectural flaw was Rails’ “one process per request” model, which bottlenecked wildly as traffic surged, whereas Go offered lightweight goroutines and excellent MongoDB driver support. The hardest technical challenge wasn’t the new language, but replicating the undocumented, magical behaviors of Rails middleware that clients had come to depend on. To achieve this, the team relied on live traffic shadowing and differential testing, comparing Go and Ruby responses field-by-field. Engineers planning massive legacy migrations should study this for its masterclass in safe, zero-downtime cutovers using dark traffic.

Are you an experienced software buyer? I could use some help. · Charity Majors While drafting the second edition of Observability Engineering, Majors issues a public call for advice on the mechanics of enterprise software procurement. She identifies “Observability Governance” as a critical new discipline, reflecting the industry’s shift from building bespoke tools to managing massive vendor deployments. The post outlines the difficulties of navigating proof-of-concepts, driving consensus across thousands of engineers, and knowing when to rip out an underperforming vendor. This brief inquiry highlights a crucial gap in engineering literature: the translation of deep technical requirements into strategic purchasing decisions. Staff engineers stepping into enterprise architecture roles should read this to understand the organizational complexities of buying over building.

Got opinions on observability? I could use your help (once more, with feeling) · Charity Majors Following up on her initial request, Majors argues that “vendor engineering” is among the highest-leverage work a Staff+ engineer can do, impacting thousands of developers for fractions of a penny. She solicits further community input on managing observability costs, executing large-scale tool migrations, and balancing tool consolidation versus tool proliferation. The piece questions the viability of the “three pillars” architecture, seeking to understand how massive enterprises manage cardinality and telemetry pipelines when locked into legacy paradigms. It’s a compelling call to action that frames procurement not as a bureaucratic chore, but as a core system design challenge. Senior individual contributors should read this to reframe how they approach external vendor strategy.

How many pillars of observability can you fit on the head of a pin? · Charity Majors Majors fiercely attacks the “three pillars” (metrics, logs, traces) model of observability, labeling it a marketing fabrication designed to sell isolated, siloed databases. Technically, she argues that siloing signal types requires massive data duplication and forces engineers to “bunny-hop” across disjointed UIs using manually correlated IDs. Instead, she advocates for an “o11y 2.0” unified storage model utilizing arbitrarily wide, structured events in a columnar store. By capturing everything in a single rich context, backend systems can derive metrics and traces on the fly, allowing developers to seamlessly zoom in from high-level SLOs to raw system calls. Platform architects should read this to understand the catastrophic cost and cognitive overhead of decoupling telemetry data.

From Cloudwashing to O11ywashing · Charity Majors Drawing a parallel to the “cloudwashing” of the late 2000s, Majors calls out legacy monitoring vendors for slapping an “observability” label on tools incapable of solving modern systems problems. She argues that true observability is not merely tracking whether a system is up or down, but rather measuring the quality of service from every individual customer’s perspective. Because traditional multi-pillar tools fail to unify application, business, and system telemetry, executives are mistakenly concluding that off-the-shelf observability is inadequate and attempting to build custom internal solutions. The post serves as a warning about the dilution of technical terminology and its impact on strategic purchasing. Technical leaders should read this to ensure their telemetry investments are actually solving the right diagnostic problems.

Moving from WordPress to Substack · Charity Majors After ten years, Majors announces her departure from WordPress to Substack, citing the excessive friction involved in publishing on the older platform. The move is driven by a desire to share lessons learned while writing the second edition of her book, without being hindered by heavy CMS workflows. She notes that the center of gravity for long-form technical writing has largely shifted to Substack, making it the practical choice for audience engagement. Though brief, the post highlights how authoring friction dictates content output. Tech writers and developer advocates should note how even minor platform friction can stifle consistent technical communication.

Hello World · Charity Majors Facing backlash over Substack’s moderation controversies, Majors defends her choice to stay, prioritizing her core job of engaging with the tech mainstream over platform purism. She explains that the industry is changing rapidly, and maintaining an active feedback loop with the community requires a low-friction publishing tool. To mitigate ethical concerns, she operates without a paywall, encourages RSS consumption, and refuses to monetize her presence on the platform. Her pragmatic stance reflects the messy reality of relying on compromised infrastructure to achieve broader engineering and educational goals. Engineers struggling with the ethical implications of the tools they use should read this for a lesson in pragmatic boundary-setting.

2025 was for AI what 2010 was for cloud · Charity Majors Reflecting on the early days of AWS, Majors draws a direct historical analogy between the cloud transition of 2010 and the AI shift in 2025. Just as cloud computing moved from experimental shadow IT to the undeniable foundation of mainstream engineering, generative AI has crossed the chasm from novelty to indispensable developer tooling. While she acknowledges the existence of a hype bubble, she warns cynics—particularly SREs—that focusing purely on the froth ignores the underlying, structural value being created. Operators must engage with AI now to maintain relevance and properly engineer its integration. Technologists who dismiss AI as a passing fad must read this to recalibrate their risk assessments.

On Friday Deploys: Sometimes that Puppy Needs Murdering · Charity Majors Majors revisits her famous anti-deploy-freeze stance, clarifying that Friday deploy freezes are a practical hack for teams lacking the observability required to ship confidently. If a team cannot instantly detect when new code harms users, halting deployments before weekends or holidays is a rational survival mechanism. However, the fatal flaw in most freezes is allowing developers to continue merging code, which builds up a massive, risky backlog of untested changes. She advises that if you must freeze deploys, you must freeze merges—otherwise, you are just batching up grenades for January. Release engineers and engineering managers should read this to decouple the mechanics of continuous deployment from the safety of code integration.

Bring Back Ops Pride · Charity Majors Majors fiercely defends the discipline of Operations against the industry trend of rebranding it to avoid the stigma of “toil”. The divide between Dev and Ops is not about who writes code—everyone codes—but a fundamental separation of concerns: Devs focus on revenue-generating product features, while Ops absorbs the complex, high-risk infrastructure problems. She argues that infrastructure engineering is often much harder than product engineering precisely because its goal is to abstract away complexity and spare cognitive bandwidth. Pretending that “Devs should own everything” spreads focus too thin and ignores the reality that Ops requires a completely different relationship with cost, risk, and efficiency. SREs and platform engineers should read this to reclaim the dignity and strategic importance of the operational domain.

Martin Fowler told me the second edition should be shorter (it’s twice as long) · Charity Majors Majors outlines the exhaustive rewrite of Observability Engineering, noting that the landscape shifted so violently since 2018 that the new edition is twice the length of the original. The first edition suffered because the definition of observability was still heavily contested; today, the triumph of OpenTelemetry and the realities of AI-native development demand a new baseline. The new volume features heavy contributions from industry experts covering telemetry pipelines, CI/CD instrumentation, and migrating away from threshold alerts. Notably, it targets a much broader audience, providing tailored guidance not just for individual contributors, but for platform and governance teams. Engineers working in observability spaces should track this book to understand the formalized, post-AI state of the art.

First I wrote the wrong book, then I wrote the right book · Charity Majors After suffering severe writer’s block, Majors realized her draft on observability governance focused on tactical implementation when the actual industry crisis was a lack of strategic alignment. Feedback from readers revealed that even highly skilled teams are trapped by executives who fundamentally misunderstand observability, viewing it as a cost center rather than the feedback loop that enables learning and AI adoption. She scrapped six weeks of work to write a new section aimed directly at decision-makers, emphasizing systems thinking, organizational shifts, and the business case for observability. This piece illustrates the critical difference between solving a technical problem and solving a sociotechnical alignment issue. Engineering leaders should read this to ensure they share a coherent operational vocabulary with their executives.

My (hypothetical) SRECon26 keynote · Charity Majors Majors contrasts her 2025 keynote, which urged SREs to cautiously wrangle AI as a chaotic integration, with the reality of 2026: AI agents are now the foundational drivers of software development. She admits that her earlier skepticism missed the exponential leap in code generation capabilities, and urges operators to abandon reflexive antagonism. The new mandate for SREs is to dive into the frontier, utilizing their outcome-oriented mindset to build the guardrails that AI systems desperately need. Because AI amplifies both capabilities and dysfunctions, the industry needs pragmatists who understand resilience to govern these tools. Infrastructure engineers must read this to pivot their careers from rejecting AI to systematically securing it.

Your Data Is Made Powerful By Context (so stop destroying it already) · Charity Majors Majors explains the mathematical imperative behind wide, structured events: the value of telemetry data increases combinatorially with every added attribute. The legacy “three pillars” model destroys this value by separating metrics, logs, and traces, thereby tearing the relational fabric necessary for precision debugging. This loss of context is fatal in the era of AI-SRE agents, which require raw, highly dimensional telemetry to reason about complex, noisy production environments without human intuition bridging the gaps. True validation of microscopic anomalies—like an N+1 query introduced to a tiny fraction of traffic—demands precision tooling that only unified storage provides. Systems architects must read this to understand why legacy monitoring silos are fundamentally incompatible with agentic development.

AI enthusiasts are in a race against time, AI skeptics are in a race against entropy · Charity Majors Addressing the polarization over AI, Majors highlights that both the enthusiasts seeing 3x productivity gains and the skeptics drowning in unmaintainable slop are entirely correct. The breakdown occurs because the benefits and the costs are experienced by two different groups who lack a shared feedback loop. She insists that teams must mend this divide by engineering the solution together: defining the exact prerequisites—better evals, robust feature flags, deterministic observability—required to safely deploy AI-generated code. High-performing organizations like Fin have achieved massive output leaps not by abandoning rigor, but because they already possessed exceptional discipline and fast feedback cycles. Engineering managers should read this to transform AI culture wars into actionable technical roadmaps.

AI demands more engineering discipline. Not less · Charity Majors With AI capable of generating code practically for free, the fundamental economics of software have inverted, shifting code from a precious asset to a disposable “materialized view of understanding”. Majors argues that because code generation is no longer the bottleneck, validation—through characterization tests, traffic splitters, and production observability—becomes the paramount engineering challenge. Human brains are terrible at validation; thus, we must build automated, deterministic feedback loops to safely manage the non-deterministic output of LLMs. Ultimately, AI does not eliminate the need for engineering; it relocates the rigor from writing lines of code to defining specifications and observing outcomes. Software architects should read this to prepare for a future where immutable application architecture mirrors the evolution of immutable infrastructure.

Is it ethical to use AI? · Charity Majors Addressing the ethical backlash against AI, Majors rejects fundamentalist purism, arguing that unilateral disarmament is both ineffective and irresponsible. While acknowledging severe harms—from exploited labor and scraped training data to environmental costs and the erosion of truth—she insists that technologists have a moral duty to engage with and govern these tools. Technology is a tool, and we learn to mitigate its harms not by avoidance, but by utilizing our skills to build better guardrails and “make it boring”. Real change comes from mucking in to build accountable systems, rather than performing moral superiority by logging off. Technologists paralyzed by the ethical compromises of modern tooling should read this for a pragmatic framework on driving change from within.

In defense of AI mandates · Charity Majors Majors defends top-down technology mandates not as tyrannical edicts, but as essential mechanisms for funding organizational change. When leadership mandates AI adoption, they are explicitly providing air cover for the inevitable drop in short-term velocity, signaling that missed deadlines are an acceptable tradeoff for upskilling. Without a formal mandate, leaders effectively demand that employees learn new paradigms in their spare time, creating immense stress and exposing cowardice in management. If a technology is truly an existential priority, the business must align its strategy, roadmaps, and expectations accordingly. Executives and directors should read this to understand that a mandate is a commitment of resources, not just a demand for results.

Connecting Thread#

Across all these pieces, whether discussing the shift from Ruby to Rust, the migration from legacy monitoring to unified observability, or the leap from manual coding to AI agents, a singular reality emerges: velocity without visibility is a death spiral. True engineering velocity is unlocked not by simply writing code faster, but by building the operational infrastructure, rigorous validation systems, and aligned sociotechnical cultures required to confidently absorb rapid change.