The world needs artisanal programmers like it needs artisanal attorneys. See: https://www.mcsweeneys.net/articles/i-am-an-artisanal-attorn...
How is an artisanal attorney different from any other attorney? Like other artisans, I pay close attention to my ingredients and process; I am intimately involved in all stages of creation. Other attorneys print their documents on paper they buy in mass-produced boxes, tens of thousands of sheets at a time, using ink that mechanically jets onto the page. I make my own paper by hand,...
If you are new to programming, this is a mostly ridiculous notion which plays to your vanity. While admiring your reflection, be careful not to fall, face first, in the pool.
Now, how do I know? Because this isn't the first time I've encountered this idea. Jonathan Blow, in his own way, has been making the same silly argument for years. As I've said before -- his frame of "programmers were real men once" makes each video/rant seem both one note and self aggrandizing.
For him, it seems to be a marketing exercise, but also an intellectual muddle, which with one breath tells you to romantically forget this is an engineering discipline, with economics and tradeoffs and constraints and compromises, and with the next, which actually helpfully(!), tells you about physical constraints of the machine. See: https://en.wikipedia.org/wiki/Data-oriented_design
The problem as I see it is that Blow and Muratori are half right about most things. They're almost always right about the particulars of programming (strict OOP patterns and "Clean Code" aren't great for performance). It's their frame that "civilization is in decline" (or "programmers were real men once" as here) that is wrong/catastrophic. Civilization simply has different priorities than game engine priorities (performance is a constraint, but not the primary constraint of most software).
It is a common refrain that performance and security are poor because they are not priorities. The corollary being that the only reason things are slow and insecure is because we do not try to make them fast and secure due to incentives. If the industry were incentivized, then wham-bam secure and fast. Right now.
That is wrong. The incentives against fast and secure have been going for so long that the institutional knowledge, if it even existed previously, is not present. Programmers have spent their entire careers not knowing how to make things fast or secure. They do not know how to make things fast or secure, right now, even if the incentives changed. Making things slow is not a tradeoff or a choice as they do not even know (right now) how to do the alternative.
Yes, if the incentives changed then the industry as a whole could relearn how to do things over years and decades. The individuals who adapt and learn the new techniques that are now incentivized would thrive and come to dominate the industry. But, it is a relearning process, not a overnight thing.
This is analogous to the loss of manufacturing expertise in the US due to offshoring and then the process of onshoring. You must rebuild the knowledge and experience. Except it is even worse in this case because you can not even bring the offshore experts to re-teach you what you have forgotten. You have to learn from the scraps of forgotten lore and rediscover and reinvent what was lost.
This is more like the loss of knowledge involved in making the Saturn V rocket. Sure, we could make a new Moon rocket if the incentives aligned, hell, we could probably make a better one with modern technology, but we can not do that right now. We must relearn and retool to achieve that.
That is the problem they are seeing, whether they actually realize what is happening or not, and it is a serious problem if we need to make a sudden course correction to achieve these goals if they suddenly become incentivized (*cough* security *cough*). If we decide to change when we need it right now, then we are in for a rough few years to decades.
I think I broadly agree.
I'd say -- I'm not sure we ever really knew how to be fast and secure. I think our problems re: memory safety and remote exploits, etc., are pretty relatively new.
I'd also say that this yearning for a forgotten yesterday is somewhat understandable, though mostly weird, a kind of tech revanchism.
My problem with Blow, et. al. is probably that they don't frame these as simply cultural differences or matters of priorities, whether or not, if the culture shifted, results could be achieved immediately or otherwise. Instead it is always a great big catastrophe.
Seriously -- I think he does it because it sells more games if the games are produced by some mercurial genius, by the Last Keeper of the Flame.
Here is a call from the pre-crowdstrike era:
https://cacm.acm.org/practice/the-software-industry-is-still...
Which is a follow-on to an article from 2011:
https://cacm.acm.org/practice/the-software-industry-is-the-p...
There are some in specialized areas, perhaps even inside a specialized area there are a few firms that are known to be at the top, and find creative solutions to problems. They aren't all Law-and-Order.
Same with accountants. Sure, it's all number crunching. But then why do some become the top business leaders, the CEO's. Maybe because in that field, being a top artisan and able to play with financial instruments, allows you to build a business. (and I'm playing devils advocate for the small percentage of accountants/business that are actually trying to build something, not just playing with money to bilk people)
Not in the way there are artisanal bread-makers. See the linked article.
> There are some in specialized areas
Let's presume the following definition:
artisanal: (of a product, especially food or drink) made in a traditional or non-mechanized way.
oh, well. I just checked all 7 old and new wonders of the world and all of them needed engineers. I don't think being an engineering discipline limits software in any way related to what can be achieved with it.
I don't either. I think programming can be art, etc.
My issue here is that I don't think favoring artisanal methods are part of the appeal of software. We are much more interested in what software does.
For instance, it might be useful to know x86_64 vector assembly. It might make your program run faster. It might even be necessary for you to know it for your program to work correctly. What I am saying is -- if a higher level construct exists, like C, C++, or Rust, which can produce an equivalent program, but you choose to write your entire program in x86_64 assembly, because that is/was the artisanal way, that's mostly unimportant/irrelevant to the user, except as an oddity.
An engineer's job isn't to build something perfect or beautiful, it's to build something that's just good enough for its intended use case. Lots of software engineers forget that.
I wrote a little bit about it here: https://jairojair.com/articles/coding-just-for-fun/
I think this is true only if "artisan" means whatever you want it to mean. Here, you seem to think it means "made by one person." But, here, my definition, and the definition of the article, is "making software using the old methods."
artisanal: (of a product, especially food or drink) made in a traditional or non-mechanized way.took off my shoes, does that count?
https://www.scandinaviastandard.com/this-is-why-that-sofa-is...
The nature of software is that every piece of it can be mass produced (copied and distributed) once the first piece is finished. All the 'artisan' effort goes into making that first copy.
For instance I have some lovingly crafted bash scripts, that feel somewhat artisan. They keep my home server humming along, applying updates, making regular backups, and reporting status. The scrips are very tailored to my use and would not easily integrate elsewhere.
I could have used off the shelf software for much of this (ala "IKEA"), I'm sure, but I am a tinkerer, hobbyist, and, if I flatter myself, an artisan.
And then there’s Italian craftsmanship https://artemest.com/
I can't remember the name of the author but there was an interesting article about this, I think from some college or university in New York, talking about some examples of software that was set up at specific locations on the campus for specific purposes, and explaining how they wouldn't have worked as an online global thing.
Edit: Here it is!
https://web.archive.org/web/20040411012949/http://www.shirky...
That article rings very differently to me because of the tooling I've developed. With the ability to break apart programs into object files and reusing them to make new programs, I can do the latter. In a sense, using both pristine source code and second-hand binary code to make programs is as artisanal as software development can get.
So, libraries?
Putting it another way, you can make libraries out of a program with this technique.
I really didn't think many people would see this post, thank you for the comments and discussion.
The central idea is that technology is cyclical, new tools will emerge and the way we work will change.
However, in my view, using tools doesn't make you less or more of a craftsman; creating something different from mass production does.
In a world where everything is very similar, websites are copies of each other, every new startup has the same color palette, creating something with small flaws, but different, is a distinguishing factor.
Perfection lies in imperfection.
Keep coding!
And in interviews, no one wants a Software Artisan. The cynic in me says that it’s because people want the job security of the typical bullshit position and don’t want anyone upsetting that.
Until that mindset changes, the disasters will keep coming.
Achieving true "replaceable people" is a major task. I have seen it done (properly), and suspect most folks on this board would be aghast at the compromises that need to be made. I didn't like it.
I managed a team of extremely experienced C++ engineers that were really hard to replace, so I did my best to keep them on board.
As to "artisan"? I don't really care what I'm called. I like coding, and I like writing really good UX.
If they hire an artisan it’s just going to be frustrating for everyone involved. The business will pay more than the value received and wonder wtf and the artisan will be bored out of their mind looking for fun projects to do.
I would argue that software would be improved if it was approached in the same engineering fashion as a civic or corolla, what we have now is the engineering effort of a Ferrari with all the warts that entails but released to the mass-market. Ferrari can't invest the engineering effort to release as polished of a product as Honda or Toyota, but that's fine since it's a niche vehicle and the buyers accept the tradeoffs since nobody uses one as a daily commuter anyway. But a small team of software developers can release an under-designed product to market and that software is available nearly instantly worldwide with little limits. Making 1M physical items is far more difficult than having 1M users of a program.
And I shouldn’t be falling for it myself.
At a previous job, probably fifteen years ago, we were replacing one bit of niche software (the company was gone, it was unsupported, and it had some very antiquated methods of ingestion, like faxes) with another, mostly similar bit of software. Continuity was desired.
Different philosophies went into structuring the two databases, so it was like lifting a vast set of webs made by social spiders from one tree and placing it on another, just for the data import. I interviewed various people who were in different roles as to how they they used the old system. I checked the databases to see what they did not tell me about how they actually used the system. I scoured over the incoming data feed sources and made robust ingestion processes, validating and correcting and logging. Knowing the vagaries of software vendors, I wrote bits to detect changes made by vendors to the database structure, or at least the portions I cared about, and whine when those occurred. I grokked how the several different roles people had in interactions with the system led to differing needs and desires, incorporating as much of how things "used to work."
The eventual juggernaut which resulted was something of a force of nature, a compilation of my best thoughts on my best days, outperforming me. It would tell you if a new type of data appeared which had not been announced, whom to ask about this data, and where to put it. It functioned for a decade of my oversight, occasionally murmuring that it wanted this or that, but without changes to the code.
That was the artisinal bit to me, that it was carved to fit some very exacting spaces, such that you hardly knew it was present. Yes, it took extra time. Yeah, it was just me. But the fit was tight and the finish was smooth.
(Naturally, some bright spark got a touch of the New Broom Syndrome and blew it and all of the documentation away after I left, I am told that there are continual complaints about the system now. Sadly, with even minimal prompting, the various tiny details arose from memory, prompted by the SMS messages.)
I think 10 years ago I cared a lot about this whole software artisan thing, nowadays I’m happy when stuff gets to prod on time and doesn’t cause large scale incidents. I wish I could have these problems and spend time discussing what the best architecture is or what class design is the best
The author here has the right idea, and the correct historical context to back it up.
Generative AI will 10x (at least) the number of people that program computers, but that programming will look different than it does today.
Gone are the semicolons and curly braces we’re so used to, just like BEQ and JMP before them.
Truly gone? No, the next Rollercoaster Tycoon has yet to be built :)
Some people like old cars, others prefer Teslas, and that's perfectly fine.
The world will change, and that's not a bad thing.
One of the recurring trends thats cropped up is so called barefoot developers, folks just cobbling together some kind of task not for big industrial software with millions or even dozens of users, but just because it makes their lives or a small group of people's lives better.
Maggie Appleton recently followed up with a post saying that these are the folks ML/LLMs might best be able to help. To get them their stuff. https://news.ycombinator.com/item?id=40633029 https://maggieappleton.com/home-cooked-software
But I also have this feeling, that almost all the webdev we do is artisanal handcraft as is. We hand author endpoint after endpoint for our objects even though there's this high degree of similarity across endpoints; authorize/validate the request, do the thing in the db, return it to the user.
Part of me is sick as shit of just how artisanal software is; it stinks like rot that we keep cranking out more piles of code for each entity & as we intricate/complicate/embellish each entity/resource. We so rarely have broader high level systems where we've escaped from hand crafting web server middle tier glorified-translators of a very basic 3-tirr client-server-db architecture.
I just want companies to pay me to tell them how much less they could do, if they let me PoC their system in something ordered & higher order, such as Hasura. Like CORBA, the UML world also has great scorn as unmaintainable, but again it's like, those folks felt on to something amazing & mighty & we have immense unsurvivor anti-bias, we are pat & confident that this tower of babel built too high & all future towers too will fall & that the effort is folly.
But man, the chaos & lines of code we have been creating as an industry is just so unnecessary & so out of control.
Yes I’ve coded permission systems a hundred times. But here it’s wired to the app we integrate with, and here it’s wired with groups. Here it’s by document, here it’s by space. A thousand hoops, never the same exact logic. Like a thousand humans, never the same identical one. We humans can see the same parts and easily designate “a human”, but this pattern recognition ignores a lot of important details. And those details are what makes IT accurate and reproducible, which has been the trait we’ve liked about it.
Since 1970, have we misled ourselves in believing we were repeating the same patterns, while in fact, every program really was different?
It's a nice "label" but it's a bit murky what it means the farther away from machine code (the raw materials) you get. Are you an artisan if you use an IDE?
I do enjoy the sentiment however.
So an artisan program would involve many hardcoded variables relevant for a specific user, and hard links that connects files for a specific users computer.
Basically one that has as little abstraction as possible. The end product would look like a script.
But I go further - software is a form of literacy, and everyone should learn to code, just as at some point we thought “hey laws are written down, novels are great, policy manuals and international letters help, let’s teach the peasents to read” and all of a sudden we have working class people going to university and discovering things like Relativity and Covid vaccines.
Software is literacy and we will all benefit when we can run / examine our society through it.
Book to follow
Why though? I've read a lot of people saying _everyone should know how to code_ but why? I don't see the same trend for example with physics, maths or music, which are arguably a form of literacy too. As cool as it may seem on paper, I can imagine everyone being able to write papers on topological quantum field theory, studying homotopy type theory as a hobby and shipping react to-do apps while playing Beethoven's Hammerklavier sonata.
One day we hope there will be sufficient wealth created in society, and distributed fairly so that toil is eliminated and all humans can choose to work - at which point what the hell is everyone going to do other than sit around and play guitar