Engineering craft

Craft in software engineering is not a single skill but a posture: the habit of caring about how something is built, not just whether it ships. Several threads run through the sources here, and they reinforce each other in ways that are worth naming directly.

The most direct argument for craft is the one about ownership cost. Yusuf Aytas notes that AI has lowered the cost of producing code but not the cost of living with it — taste and judgment remain necessary because LLMs generate polished technical debt faster than any individual ever could. Abednego Gomes pushes this further, arguing that shipping AI-generated code without review is incompatible with safety-critical systems and causes measurable skill atrophy over time. Both pieces frame craft not as aesthetic preference but as risk management.

Good design principles are a recurring vehicle for that risk management. Kobi Hari argues that Angular components bloated with dozens of inputs should be refactored into composites so each concern stays encapsulated and APIs remain clean. Go Monk makes a complementary point: deep modules — small interfaces hiding large implementations — reduce complexity for both humans and LLMs. Henrique Teixeira corrects a common misreading of the Single Responsibility Principle, showing that over-granularizing classes violates the cognitive simplicity SRP is meant to provide. Dominik TkDodo extends the organizing-by-cohesion argument to file structure, advocating domain verticals over horizontal technical layers.

Craft at the system level means knowing which improvements actually matter. Colin Breck describes how attention thresholds, discrete capacity increments, and pipeline backpressure make even order-of-magnitude speedups irrelevant in practice. Arthur Pastel shows the flip side: when the bottleneck is real, systematic optimization — replacing float arithmetic with integer accumulators and costly division with reciprocal multiplication — yields a 5.9x speedup. Both pieces together illustrate the judgment call at the center of craft: knowing when to optimize and when not to bother.

Tooling fluency is part of craft too. Christian Hofstede-Kuhn catalogs Readline bindings, history search, and script safety flags that reduce friction at the shell. Ally Piechowski demonstrates how five git log commands can map codebase risk before reading a single file. Ben Gesoff offers a Jujutsu workflow for reviewing large changes that trades cognitive overhead for progress persisted in version control.

Craft includes knowing what to trust. lab174 traces YAML’s Norway problem — a type-coercion bug where NO parses as false — through spec versions and shows that popular libraries still exhibit the issue a decade after the fix landed, a reminder that specification correctness and implementation reality diverge. Anton Zaides distills production-incident lessons into rules like rolling back before debugging and treating every external dependency as a future outage.

Finally, craft extends to how engineers transmit and communicate what they know. cekrem draws on Polanyi’s philosophy of tacit knowledge to argue that the most valuable engineering expertise — pattern recognition, design intuition, unwritten conventions — is structurally inaccessible to AI tools and can only be passed on through apprenticeship. Tuhin Nair identifies a parallel gap in communication: senior developers frame problems as complexity management while the rest of the organization thinks in terms of uncertainty reduction, and bridging that gap is itself a craft skill. Fagner Brack makes the point from the hiring side: algorithm interviews test a narrow, trainable skill that weakly correlates with production performance, where real craft means reading tradeoffs and shipping incrementally against messy, unbounded inputs.