Digital Powertools
Make your tools easier, faster and better
Celebrating software craftsmanship
Have you ever thought about craftsmanship when you think of software development? Like really sit down and think and philosophize about what craftsmanship in software development means? To be honest, I never really did until last Sunday. And it was triggered by this post on 𝕏:
"Dang, my computer’s running slow."
— Dell (@Dell) May 30, 2025
–me, with 47 tabs open, 12 apps running simultaneously, and a podcast minimized in the background.
The post by Dell sparked a bunch of commentary from developers like Ryan Fleury and Casey Muratori. Their posts are seeping with disappointment at the current state of the software industry. Nobody really cares about writing "good" software anymore, as long as it somewhat works. Developers don't take pride in making something great and, as Casey nicely summarizes, there's often an anti-craftsmanship culture that ridicules people who want to make great software. And they're not wrong. Just look at all the hype around "vibe coding." If you listen to some of the hype-bro's out there, you'd almost think you're retarded if you still look at any actual code at all in this day and age.
Software craftsmanship
So what does craftsmanship look like in software? Let's back up for a minute and have a look at the general definition of craftsmanship according to the Cambridge Dictionary: skill at making things. Well, that's not giving us much to work with. Though for a lot of people, the term craftsmanship comes with a lot of positive connotations about the craftsperson and the quality of the creation. The Shopify blog has this to say about craftsmanship: (emphasis mine)
Craftsmanship refers to the skill, artistry, and meticulous work involved in creating things, frequently by hand. The term often speaks to the precision, expertise, and care employed by the maker. In that way, it can differentiate a high-quality artisanal product from indistinguishable mass-produced goods.The Illinois State Board of Education has a whole document about craftsmanship: (again, emphasis mine)
Terms associated with high-quality craftsmanship include artistry creativity, dexterity, expertise, imagination, ingenuity, and skill. Craftspeople are highly skilled in a craft or an art in which the work exhibits quality and great attention to detail.
I could add more references, but they all echo the same basic properties. Craftsmanship involves skill and expertise, high quality, attention to detail, and artistry and creativity.
- Skill and expertise
-
Craftspeople have a good understanding of the tools and materials that they are working with. There are
tracksaws, bandsaws, tablesaws, mitersaws and handsaws, skilled woodworkers know how each of these saws
works and what they are capable of, what cuts they can absolutely not do. As the woodworker gets more
skilled, they can get a certain saw to make cuts using jigs that would otherwise be at best inaccurate
or at worst, even dangerous.
Being a skilled software developer means you know the strengths and limitations of the languages and frameworks that you work with. It means you need to realize that web technologies are not as great of a fit for a real-time pair-programming tool as native Swift and raw UDP are. Or that Rust is a stronger language for embedded applications and Go for network services. A skilled developer, like a skilled woodworker, can get their tools to do pretty much anything. You can make a webserver in Rust, a realtime MMORPG in JavaScript or embed a Go binary inside a Bun application. The really skilled experts know when it's time to stop torturing their favorite tool and reach for a more appropriate language or framework. - High quality
-
Put an Ikea desk and a
Blacktail Studio desk
side by side, you'll know in a single look which desk is the high-quality one. Add a Foureyes Furniture
desk and a random person in the street might not be able to tell which one of the latter two is the
higher quality one. Even expert woodworkers would have to see both pieces in real life to tell which one
is the best.
The same thing is true for software. It's easy to distinguish between a high- and low-quality application. Everyone gets frustrated by the sites that are slow and make your browser freeze. From the outside, as with pictures of furniture, there's only so much you can say about the quality of a product. It's good or bad based only on the interactions that you have with it. Just like wood can bow and crack over time because of the table was constructed, applications can start to break as they accumulate more usage. Expert woodworkers can often predict these failures by looking at joints and grain direction. Expert software developers can predict the failures by looking at the code.
As your skill and expertise grow, you also become more capable of determining the quality of code. Oh boy, yes, there's skill involved there. Because despite all the attempts at creating a definition of "great code," nobody has succeeded in creating an objective definition that everyone agrees on. They're all based on subjective properties like readability, maintainability and testability. Even some decade old attempts, like Uncle Bob's "Clean Code", still spark debates to this day. Some people don't care about 300-line functions or deep nesting of if statements. Others get an awkward twitch in their eye as they look at a file that contains more than one class. What good is 100% unit test coverage if the tests are so tied to the implementation instead of behavior that they break on every tiny change? Practices which are considered idiomatic in one language, are a terrible code smell in others. As your own skills improve, you'll get better at recognizing what high quality looks like for your stack. And you'll get better at making sure your own output is of that same high quality. - Attention to detail
-
But high quality doesn't come for free, even if you know how to achieve it. It takes a painstaking
effort called "attention to detail." Where others cop out with "it's good enough," the real craftspeople
keep pushing with low-effort changes that make a big difference. The novice just screws the table
together. The skilled woodworker will cover the screw with any wood plug. The craftsman will make sure
the color and grain direction of the plug matches with the surrounding wood to make it near invisible.
The craftsman will round over the corners of the desk top and add self-leveling feed to avoid
wobbling.
As you build software, look for those small code changes that make a big difference. A novice may retrieve all items in a table and do sorting, filtering, and pagination on the client side. A skilled developer will make sure those parameters are passed on to the database layer to limit the amount of data that needs to be transferred. The craftsman will make sure new UI elements look and behave consistent with the existing elements. The craftsman thinks about the impact of chaining a bunch map, filter and reduce calls on a large dataset instead of using a single for loop to achieve the same result. - Artistry and creativity
- I was afraid my woodworking analogies would start to break down here. It's quite obvious that artistry and creativity play a role in woodworking craftsmanship. The designs, techniques, choice of wood, you name it... There is a bunch of freedom in woodworking projects where a builder can make their creative mark. It turns out the same is true for software development. We can craft an intricate, well-thought-out design for our application architecture and codebase just as a woodworker can design a unique, three-legged chair. We can explore new techniques to organize our data in a way that enables completely new functionality. We can build using the database species of our choice or go out to write our own database like a woodworker who cuts down his own trees. Just like wood takes a long time to dry, writing our own database will take a long time. But that time is a worthy sacrifice for the creativity that we get in return.
Craftspeople versus Artisans
While hunting for a definition of what craftsmanship means, I came across a quote by Imran Haider that I want to address before we move on the anti-craftsmanship culture:
Another misconception about craftsmanship is about the use of technology. Like if it’s not created by hand then it’s not craftsmanship. Craftsmanship is not doing everything by hand. It’s about doing what’s best regardless of how it is done. It’s about making sure that craft is aesthetically beautiful, performs what it was designed for and every detail that went into making it was carefully attended.
And in this world full of Generative AI, that message feels like it's worth reiterating. Craftsmanship and artisanship are two closely related but still different concepts. Being a craftsperson doesn't mean you have to do everything by hand and can't use tools that make your life a little easier, make you work a little faster. Go use your power tools to cut that dovetail joint if it allows you to create drawers that you can be proud of. Go use a laser engraver to burn your intricate drawings into wood if hand burning them would screw up the end-result. Go use digital power tools like AI to build that perfect app that you've always dreamt of.
The Anti-Craftsmanship Culture
As I was writing the "artistry and creativity" section above, I realized that we, as the software industry, have been squeezing artistry and creativity out of our craft for years. All across the stack, for better or worse, we've standardized on a limited set of solutions. Communication? Yeah, besides some old protocols that refuse to die, the default is HTTP. Frontend development? Is there anything else than React? Speaking about React, some people would be more than happy to standardize all development on JavaScript as "the One True Language." Those database species that you can choose? Our stock is currently limited to mostly MySQL and PostgreSQL. If you're lucky, you might find an MS SQL Server if you live on the Microsoft side of the world or a stray SQLite if you wander off into the woods.
If you dare to do something outside of those de facto standards, you get weird looks at best. But if you choose a different path in a business context, your professional judgment will be put into question. Because in business, these concepts are like buying from IBM; they are the safe choice, nobody ever got fired for it. There are plenty of people who know these technologies, making hiring and skill evaluation a lot easier. Once hired, it makes onboarding them and getting them productive a lot faster. The original developer is no longer a single point of failure for the success of the business.
When I joined the workforce in 2010, the founders of that company had written some fairly low-level code like a Java HTTP Thread Pool and a database connection pool. Around the same time I joined, the founders with an academic background hired a freelancer with more experience in the professional world. The first thing that person did? They ripped out the custom pool implementations and ported everything to the Java EE ecosystem with an application server and "Enterprise Java Beans." That was less custom code we had to learn and maintain. The custom build scripts were translated into Maven build files. More standardized, less custom code, less mental overhead, lower risk. But also a less creative solution and less opportunity to improve my skills. The technical side of my professional life was now "trapped" in the Java EE framework that provided just about everything. No need to upskill and dive into lowlevel build systems. No need to find creative pooling solutions. It was all there. My focus was on wrangling the business logic into the structure of the framework.
And understandably so. The goal of a business is to make money, preferably enough of it to avoid running out. Standing on the shoulders of the giants who came before us, is what allowed the software industry to deliver so much customer value in ever shorter timeframes. Just like actual builders don't need to reinvent the steel beam for every building, the software industry doesn't need to reinvent the full stack for every application.
But it often feels like we're abusing the standards and established patterns as an excuse to stop learning, to stop investing in creative solutions and to stop innovating. "Why would you invent your own protocol for that hobby project, just use HTTP?" "Why should I learn a new language for server programming? I already know JS and it's fast." "Yeah, we need the background requests to keep the visible data fresh, but we can't pause them if the tab goes out of focus, so we just keep them going. Ten requests per hour shouldn't hurt our servers anyway." "Yeah, we need all these build tools, duh. We need to do tree shaking, inlining, transpiling and minimizing. We're not shipping hundreds of megabytes to the browser." "Why build another backend framework? There's Laravel and Rails and Django and... You could already have shipped your app by now if you used one of those!" "Yeah, we're not using grpc and protobuf; JS doesn't really support them all that well. But we've built tRPC instead to provide typesafe communication over the network!"
And yeah, I realize that last example cuts both ways, and I'm falling into the anti-craftsmanship culture trap as well. We have to applaud them for creating a nice, creative solution to a problem within their constraints. They could have stayed with the plain fetch api and JSON, but they choose to level up the surrounding ecosystem. On the other hand, instead of being open to learning new existing skills and technologies that might be better suited for server development, they hold on to TS so hard that they'd rather reinvent a less efficient wheel. And in doing so, they're taking away incentives for others to go and learn new technologies and concepts. They are putting another layer of abstraction on top that takes away the incentives to think about the code and its effects. As with React Server Functions, it's no longer clear when a network request happens. It looks and quacks just the same as a client-side function, so... it must be a client-side function? But it does a request that can be slow, can fail, and definitely needs to be secured on the server side like any other route. I've tried asking ChatGPT for a tRPC client and server. It won't include any authentication unless you explicitly ask for it. And who explicitly asks for that? The senior developers who know what they're doing.
With all the services, frameworks and libraries that are available today, it really feels like we're pulling the ladder up behind us. Even to the point where making a web application is barely anything more than duct-taping together a bunch of external services, build and managed by other people. We no longer know and teach what happens under the hood, even though a lot of the technology is free and open to run on your own. We run our services on Vercel, Heroku,... no server management required. Who knew you could just set up your own webserver? 😱 We connect to database services like Neon and SupaBase. Who knew you could just set up your own database server? 😱 And when someone does exactly those things, they get mocked. Just look at what people tell Pieter Levels when he tweets about setting up his own email server (yes, you can!). Or how they react when DHH talks about 37signals' move away from AWS to their own servers, managed by their own team. Most of the people think you can't do that. That there's no way you can manage all of that on your own or with a small team.
Rather than showering them with disbelief or mocking them for their learning trajectory, try some introspection. Maybe it would be interesting to try and manage your own database or email service. Running your own infrastructure might not be as costly or challenging as you thought it would be. Maybe getting rid of those 10 extra remote requests per user per hour is worth the effort to get to a high-quality product. Craftsmanship doesn't lie in the tools you use or don't use. True craftsmanship is found in the ability to recognize what a high-quality product looks like, in the ability to figure out how you can achieve it and in the intrinsic drive to achieve that level of quality.
If you got this far. Thank you so much for pushing through this meandering rant :D Now please go out there and celebrate the work and effort our fellow craftsman developer put into their application.