Legible Work vs. Illegible Work: Navigating Impact and System Design

Sean Goedecke’s pragmatic approach to software engineering, as detailed in his conversation on the Overcommitted podcast, reveals a critical tension often overlooked in fast-paced tech environments: the conflict between immediate, measurable output and the slower, compounding benefits of truly robust design. Goedecke, a staff engineer at GitHub Copilot, argues that conventional metrics and processes often incentivize "legible" work--tasks easily tracked in systems like Jira--at the expense of "illegible" work, which involves deeper, more strategic thinking and problem-solving that yields significant long-term advantages. This conversation is essential for ambitious engineers, managers, and technical leaders who want to understand how to navigate organizational incentives, leverage AI effectively, and build systems that endure, rather than merely appear productive in the short term. It offers a framework for identifying and prioritizing the kind of impactful work that truly drives value, even when it’s difficult to quantify.

The Hidden Cost of Legibility: Why Jira Tickets Aren't the Path to Impact

The conventional wisdom in many tech organizations is that visible progress, often measured by the sheer volume of completed tickets in systems like Jira or GitHub issues, equates to high impact. Sean Goedecke challenges this directly, drawing a line between "legible" and "illegible" work. Legible work is easily tracked, quantifiable, and fits neatly into standard reporting structures. Illegible work, conversely, is often more strategic, involves deep thinking, navigating complex organizational dynamics, or tackling foundational problems that don't have immediate, easily demonstrable outputs.

Goedecke argues that while legible work might provide a sense of immediate productivity and can be a useful "coming-of-age ritual" for early-career engineers, it is rarely the path to significant, lasting impact at a large tech company. The danger lies in optimizing solely for legibility, which can lead to what he terms "resume-driven development"--making architectural or technical decisions not based on the best long-term solution, but on what looks impressive on a resume or promotion packet. This often results in systems that are complex, difficult to maintain, and ultimately hinder progress, even if the initial development phase generated impressive-looking metrics.

"Don't just go to the queue where work is assigned and do more of that work than anybody else. That can be a useful thing to do. I think that's like almost a coming-of-age ritual, I think, for early career engineers to just really flex their muscles and see how fast they can burn down the ticket queue. But that's not actually the way to have the most impact, even if that does kind of produce the most legible performance metrics."

This dynamic creates a subtle trap: engineers are incentivized to produce work that is easy to report but may not be strategically sound. The true impact, Goedecke suggests, often comes from investing time in understanding the broader system, identifying potential pitfalls, and making nuanced decisions that might not be immediately obvious or easily quantifiable. Teams that excel at this "illegible" work often appear to "ship a lot of things" and "get the most important projects" not by magic, but by strategically allocating effort beyond the visible ticket queue. The implication is that organizations and individuals who fail to recognize and cultivate this illegible work risk building brittle systems and missing opportunities for genuine innovation.

Pure vs. Impure Engineering: The Trade-offs in a Demanding Landscape

Goedecke introduces a compelling dichotomy: "pure" versus "impure" engineering. Pure engineering, exemplified by art or research, involves work with clearly defined goals, measurable constraints (often performance-related), and the ability to whiteboard and diagram solutions without constant external input. The core C library for GitHub's Markdown pipeline is a prime example, where efficiency is paramount and the problem space is well-defined. Open-source library development also often falls into this category, where the interface is stable and internal technical command is the focus.

Impure engineering, on the other hand, is characterized by constant adaptation to evolving product requirements, significant interaction with stakeholders, and a less defined problem space. Copilot's billing and access systems, with their dynamic product concerns, exemplify this. Game development, particularly engine development, leans heavily towards pure engineering due to its focus on technical design and optimization. SaaS development, however, is often inherently impure, requiring continuous adaptation.

The critical downstream effect of this distinction is how it impacts decision-making, particularly concerning AI adoption and hiring. Goedecke posits that AI is currently more beneficial for impure engineering. This is because impure engineers often work in unfamiliar systems, and AI can quickly provide context or reach an 80% solution. Pure engineers, who typically possess deep, long-term familiarity with their specialized domains, may find AI less helpful because their problems are conceptual and internal, not based on searching for unfamiliar code or APIs.

"If you're an open-source dev, right, and you've been working on the same, let's say, graphics library for like 20 years, you're not going to need [AI] at all because you know where everything is, and you know how everything works, and your problems are all kind of conceptual."

This has significant implications for hiring and team composition. Elite "pure" engineers, while technically brilliant, may not possess the skills needed to navigate the complex, multi-system environments of large tech companies, which are often dominated by impure engineering challenges. The ability to understand and navigate vast, interacting codebases and cross-cutting features is paramount, and this is a skill developed through experience in impure environments, not necessarily through optimizing a single component to its absolute limit. Companies that fail to recognize this distinction risk hiring individuals whose pure engineering prowess doesn't translate to the systemic challenges they face, leading to missed opportunities and misaligned talent.

System Design as a Durable Skill in the Age of AI

As AI tools become increasingly adept at generating code, the fundamental importance of system design only grows, according to Goedecke. He argues that the core primitives of system design--web servers, queues, requests, caches--are enduring concepts that will remain relevant for the foreseeable future. In fact, the rise of AI makes these skills more critical, not less.

The reasoning is systemic: while AI can write code, it requires human oversight to ensure the overall system design is sound, coherent, and aligned with business goals. Engineers who can grasp the "broad picture" and sanity-check AI-generated solutions will be invaluable. They will be the guardians who can identify when an AI's suggestion is "completely nuts or completely out of step with the way the system's actually supposed to work."

This perspective challenges the notion that AI will render traditional engineering skills obsolete. Instead, it suggests a shift in focus. The ability to architect robust, scalable, and maintainable systems--understanding how queues prevent cascading failures, how caches improve performance, and how different components interact--becomes the differentiator. This is not just about knowing the primitives, but understanding their trade-offs and how they fit together to form a cohesive whole.

"If there's a role in the next 15 years for engineers, if AIs get so good that they're writing all the code, that role will be as people who are guardians of the system design and people who are familiar enough with the kind of broad pictures to catch the cases where the model is suggesting something that's completely nuts or completely out of step with the way the system's actually supposed to work."

The consequence of neglecting system design fundamentals in favor of simply prompting AI for code is the creation of systems that may function in isolation but are difficult to integrate, scale, or debug. It creates a dependency on the AI without the underlying understanding to guide or correct it, potentially leading to the very complexity that good system design aims to avoid. This highlights a delayed payoff: investing time in system design now builds a foundation that is resilient to technological shifts and enables more effective collaboration with AI tools in the future.

Key Action Items

• Prioritize Understanding Over Output: For early- to mid-career engineers, consciously allocate time to understanding system architecture and underlying principles, even if it means a slower pace on immediate ticket completion. This is a longer-term investment in strategic impact.
• Embrace "Illegible" Work: Actively seek opportunities to engage in tasks that require strategic thinking, cross-team collaboration, and problem-solving beyond the standard Jira queue. This could involve proactively identifying architectural improvements or facilitating difficult conversations. This pays off in 12-18 months through increased influence and project ownership.
• Develop System Design Fundamentals: Focus on mastering core concepts like web servers, queues, caches, and databases. Understand their trade-offs and how they interact. This is an immediate need that builds durable advantage over your career.
• Be a "Guardian" of AI-Generated Code: When using AI tools, treat their output as a suggestion. Critically evaluate its fit within the broader system architecture and ensure it aligns with long-term maintainability and scalability goals. This requires immediate diligence.
• Seek Diverse Engineering Experiences: If possible, aim for exposure to both "pure" and "impure" engineering environments to develop a well-rounded perspective on problem-solving and system complexity. This builds adaptability over several years.
• Challenge Legibility Metrics: As a manager or senior engineer, advocate for recognizing and valuing "illegible" contributions that drive strategic outcomes, even if they don't fit neatly into standard metrics. This fosters a culture of deeper impact and requires ongoing effort.
• Practice Deliberate Code Writing: For junior engineers, intentionally write significant portions of code manually before relying heavily on AI tools. This builds fundamental coding skills and the intuition needed to effectively guide AI later. This is an immediate action for long-term benefit.