Stop Pretending Your Code Is a Stradivarius
Most code isn’t crafted for the symphony—so why are you still carving it by hand?
Hi everyone,
Thank you for reading Great CTOs Focus on Outcomes. I publish weekly and have an archive of over 150 posts, each packed with valuable insights on various topics relevant to CTOs and the issues they face, distilled from my career experience.
I strive to make each post a helpful resource on the topic it focuses on so that when a CTO has a need, they can reference an atomic nugget of insight. To this end, I regularly revisit and refine posts, ensuring you always receive the best and most up-to-date information with the most clarity.
If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.Some developers resist AI-assisted coding tools because they "prefer to code by hand." It’s a familiar refrain—often rooted in pride, sometimes in perfectionism, and occasionally in a romantic idea of the developer as artisan.
But let’s get real: if your software is IKEA-level functional, stop pretending you're shaping tonewood with a fingerplane.
The Stradivarius metaphor is seductive. A single luthier, guided by touch and instinct, carves resonant beauty into every curve of a violin. That’s admirable craftsmanship. But in software, most of us aren’t making symphonies—we’re building support systems, admin dashboards, and payment integrations.
Precision matters, yes—but not everywhere, and not all the time. Knowing where to be exacting is part of the craft.
What AI Can (and Should) Do for You
AI isn’t about replacing you. It’s about removing the friction from the routine. Boilerplate, scaffolding, doc generation, test stubs—these aren’t the bits that define your engineering legacy. They’re the IKEA instructions. Automate them.
The fingerplane moments—those are still yours. Architecture decisions. Tradeoffs. Security considerations. Domain modelling. Elegant error handling. That’s where you earn your keep.
Let go of the romanticism. Embrace the tools. Then reinvest your time in the parts of engineering that actually require your creativity.
How do you define where “craftsmanship” truly matters in your codebase—and where it becomes counterproductive? How can leaders model the adoption of pragmatic tools without devaluing engineering pride or quality? Share your perspectives in the comments.
If you enjoyed this publication, please help others find us and benefit from the insights.