> The last point I want to make is I feel like it's been forever since I had a conversation about craftsmanship on the job. It's possible I have just found myself in the wrong places time and time again.<p>I can relate with the OP, not in terms of craftsmanship but criticality of things during the development process and operations.<p>When I worked in finance (algo trading), I was amazed at how we had so many controls and guard rails we had to ship something, that during the time was almost impossible to go south because if we knew that if something went off our company would be burst more or less like Knight Capital.<p>Fast forward to working in some SaaS, I always struggled to understand how things were so low impact/critical/important and how those things happened almost every second. Was hard to believe that some folks on the fund using VBA and excel spreadsheets were way more careful coding than allegedly professional software engineers. After some point in time, I just felt sloppy the whole process.<p>With time comes maturity and you start to realize that each company has some kind of meta-culture around how things are done and you end up adapting yourself; but is not an easy process. Another thing that I noticed is that your early experience in SWE or experiences that you're operating in hyper critical industry or a world-class environment creates a massive imprinting that you carry along your entire career.
As with everything else, it's all about incentives. If well-crafted software made more money, then all we'd have would be craftsmanship. But it doesn't.<p>There is plenty of software which has to be reliable and without surprises, and that is where you will find craftsmanship. Except that doesn't usually make as much money as "big tech", so it won't pay as much and that is the problem. People want to have their cake and eat it too - spend countless hours on problems that tickle their intellectual curiosity and sense of achievement, while also being paid handsomely.
On a wider scale, this is Scott Alexander's Moloch -- people who ship an Electron app now would outcompete people who would spend and 3x more on writing native clients for each platform in 3 different languages, and 3x as long to polish the codebase.
0. We need this done yesterday.<p>1. Moving targets. As the code becomes usable it becomes clear what is really needed doing and how it should be done. And it's certainly not what was defined at the start of the project.<p>2. So the prototype/PoC works, thank you! - "job done" - more than good enough. No time to go refactor for the many little "todos" in the code that say " this code needs to be revisited because ..." as the next project "needed yesterday" is already here...<p>Craftmanship is for academics and people that don't work in the real world because it needs time, lots of it.
It is also true that a clunky and inelegant piece of code that does its job is infinitely better than a pristinely written code that solves a slightly wrong problem.<p>So iterating quickly and being agile is bad for the code quality, but it is probably good for finding exactly what is the right problem to solve.
> Unfortunately, "impact" is almost always measured by what features you shipped rather than considering the impact your code had on the long-term maintainability of the codebase.<p>I've been trying to communicate this with absolutely no luck at all. Just coding is not considered "impact", meanwhile there are a ton of bugs and features take ridiculously long to complete. I believe this is major misunderstanding or lack of knowledge as to how software should work, thinking it's analogous to building hardware where you need more and more people to scale productivity.
The absence or presence of craftsmanship is primarily a differentiator in which sandboxes you get to play.<p>You simply cannot build e.g. a viable dbms without at least a modicum of software craftsmanship. If you attempt such a thing with the shovelware mindset of most user-facing applications, it will simply never come together.
I serve as tech lead on a team of five people - each with wildly varying levels of experience. Those five people are spread out across two entirely separate projects. Tell me - how does one foster craftsmanship in that environment?
Actual crafts, as in hand crafts are either wildly expensive or imported from the 3rd world. You can make them yourself, but then it's probably expensive not just in equipment but in time.<p>With software craftsmanship, I think there are the same options.<p>I don't think anyone forgot, so much as craftsmanship of all kinds got more expensive if you want it done here.<p>And the money seems to matter to a lot of people more than ideal quality does. Far fewer people buy a (reasonably-priced if expensive) hand-made table from Amish craftsmen than buy (overpriced but cheap) Ikea garbage.
> "impact" is almost always measured by what features you shipped rather than considering the impact your code had on the long-term maintainability of the codebase<p>A new feature = an increment in major version of your product, for example v1.0 -> v2.0<p>Bug fixing and other maintenance work = an increment in minor version, for example v1.0 - v1.1<p>No matter how many bug fixes or perf improvement you did, v1.999999 is always less than v2.0. It's a pretty sad fact.
It’s hard to fathom how much information technology is still in its infancy. Probably, one day, people will simply pay for software, and in that universe craftsmanship matters. Until then, the current conditions are largely collateral damage of adtech and SaSS.<p>Still, it’ll pass. Software is just hard, and business is even harder. Eventually people who are good at both will win, but it takes time to sort itself out.
Every project you goto, its allready a catastrophe.
No tests, patchy expectations, strange visionary gurus with even stranger requirements, which of course change all the time and make no sense.
No money for a rewrite, eternally add oriels to it.
Frameworks, that are either old - but reliable, or new and ever changing.
Wish, you could join companies and refuse to participate in old projects.
Is this not simply because software is no longer art, but commerce?<p>If you're making something for someone else, your soul isn't in it. So who cares?
I always tell new developers, take pride in your work, and take the time to do it right, because your manager will not care at all about the quality, but it'll bite you in the ass if you don't. The only person who is going to care about craftsmanship of your code is you.
Agile (TM) is orthogonal here. If you have too much work, you have too much work.<p>If anything, agile at least makes it possible to revisit parts of the software and fix them at anytime. No need to be in the same requirements/design/implement/test phase to work on something.
According to my job title I'm a software engineer; but I've always regarded myself as a craftsman, writing bespoke handcrafted software. I am also (as the OP suggests) a few years from retirement.
Atlassian is responsible for putting the guns in the hands of incompetent micromanagers, for whom the likes are Jira are the wet dreams they can only fantasise about in their alternate reality.
Github deserves a lot of the blame here.<p>Teletubby-candy-crush blingware UI blended with manipulative social upvote features does not engender Göedel-level greatness.