Software Craft as Plumbing and Art

System-level software skill

The most talented software engineers in my life share a few common traits. They:

• Work efficiently across systems with wildly different abstraction patterns.

• Build systems that accelerate product development.

• Derive real satisfaction from understanding how these systems work.

This is a system-oriented view of engineering skill. And it explains much of the skill variance I’ve observed over the years. But it neglects the role of software craftsmanship. The idea of craft resonates with me, too, so I’d like to clarify what I mean by craft and connect it to this system-level perspective.

Software craftsmanship

Off the top of my head, craftsmanship is an ever-shifting balance between plumbing and art. I am not a plumber, so I’ll clarify that by plumbing I mean:

• Unglamorous but essential assembly work.

• Working almost entirely within systems built by others.

• Fitting odd pieces together at the right connection points.

Art— well, that’s more difficult to define. My take is mostly informed by playing jazz with others. A few relevant qualities include:

• Being creative within a set of well-chosen, supportive constraints.

• Expressing new ideas in a way that deeply resonates with others.

• Aspiring to some aesthetic, rejecting ideas that don’t meet it.

People believe that plumbing skills will be less important with AI. There is an increasing emphasis on the role of aesthetic or “taste”. But I think the most skilled engineers will be the ones who can quickly switch and balance between the two modes.

Now, how does this relate to a systems-oriented view?

Working efficiently within multiple systems

Take a real example: suppose you’re implementing Python asyncio request-level isolation of Google service account credentials, so that each request only accesses the user’s own GCS bucket.

You’re now juggling two very different systems: Python’s concurrency model and Google IAM. You don’t need a deep understanding of either to get started—you can get far by reading about contextvars and service account impersonation. But just acquiring an OAuth access token involves a bunch of plumbing. And doing that well benefits from a partial understanding of the underlying abstractions.

There’s also aesthetic judgment involved: how do you neatly swap credentials? Do you use a repository pattern to locate the right service account? Your team’s design preferences—maybe they use domain-driven design—impose some constraints. But ultimately, ambiguity remains. And resolving it well involves creativity.

So, a balance between plumbing and art emerges when the engineer writes code to solve a task constrained by multiple internal and external systems.

Building systems that accelerate product development

Great engineers have a gut sense for how the structure of a codebase affects iteration speed. They design abstractions that resonate with team norms and workflows, enabling faster feature development. They identify technical debt, assess its trade-offs, and decide when to repay it. They know when it’s worth hacking across systems to validate a product idea.

Underlying this is creativity under constraint. That intuition helps them choose and adapt the right constraints (like design patterns) to fit their team and product context. Aesthetic alignment matters: domain-driven design might be great for backend folks, but bad for ML researchers.

But these systems still have to be correct and performant. You’re always bumping up against past design choices and the quirks of external APIs. Time is limited, so you cut corners, hide the mess, and keep moving. You step through debuggers. You dissect stack traces. That’s plumbing.

Satisfaction from understanding a system

In guitar, there’s a concept called fretboard fluency: the ability to see and use notes, chord shapes, and patterns anywhere on the neck in real time. It supports improvisation and composition. You can build fluency without ever learning modal harmony, but for some musicians, theory helps make sense of the instrument. They find the structure beautiful, and it shapes the music they make.

Software can be like that, too. Many engineers love building mental models of concepts like networking, filesystems, or concurrency, and gradually refining them over time. For some, these models are just practical tools. But others take joy in the learning itself. And that joy accelerates mastery. So it makes sense that the engineers with the best understanding often enjoy the learning process.

Why is this perspective valuable?

Personally, I’ve gravitated toward a systems view of programming skill for a while. But it didn’t always feel connected to why I chose to be a programmer.

Reflecting on these connections has brought more joy to my work. I’ve always found value in both the artistic and plumbing-like aspects of programming. I remember being a teenager, excited and frustrated, digging through Objective-C Cocos2d documentation to build a game I’d fully imagined.

Now I can more clearly connect that feeling to a desire to deepen my craft. And I have a new lens for learning from engineers I admire: by observing how they shift between plumbing and art.