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,...
This article is so similar to this satire I couldn't believe so many commenters were taking it so seriously.
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).
“Civilization in decline” is overstating the problem.
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.
> It is a common refrain that performance and security are poor because they are not priorities.
> We must relearn and retool to achieve that. That is the problem they are seeing, whether they actually realize what is happening or not.
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.
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.
I am saying -- there is no attorney marketing their unique skill with the Smith Corona Galaxie or with a quill. Instead, you probably want them to write a brief for you and don't particularly care how they physically do it.
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 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.
Sure but demand for world wonders is low. Demand for basic cookie-cutter houses is very high.
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.
Software is somewhat unique because the design, execution, and mass distribution can all be one step. So you really can be a software artisan, though the world needs the mass production kind of software too.
> So you really can be a software artisan, though the world needs the mass production kind of software too.
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.
I'm not sure building furnace is a good metaphor for crafting good software.
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.
That's a pretty narrow view of software too. The nature of building software systems is not always towards being able to mass-produce them. What would be the point of copying and distributing 10K copies of my script that runs migrations for one legacy database in a very specific way?
I have written a lot of software for myself or some close associates that is really only for our purposes (or sometimes just for our amusement). Certainly I could trivially distribute the software to whomever I wished, but it wouldn't be useful, appreciate it, or perhaps even run outside of the environment I wrote it for.
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.
Are you referring to that article about software that serves a small local community?
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.
My 10,000 hours are well behind me and I build web apps a bit like this. Previous jobs are like a shed full of parts that will get 60% of the way there, and the rest is making a couple of custom parts and a lot of fettling. Sometimes I build a table from scratch just to remind myself I can.
Artisans can make objects out of raw material, but they can also take apart objects to reclaim raw material. Software engineering tends to only ever do the former, because traditional toolchains are a one-way street from source code to assembly code to object files to programs.
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.
No, it's actually ripping out bits from an executable and turning them into relocatable object files. The technical term I've come up with for this is delinking, although the decompilation community calls it binary splitting.
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.
I have attempted, in vain, to bring this kind of thinking into the companies and teams that I have worked with. They don’t want it.
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.
The problem with hiring artisans is that most companies need a Honda Civic not an Enzo Ferrari.
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.
One thing where that analogy breaks down is that a Honda civic is more highly engineered and a more refined product than a Ferrari. The Ferrari makes all sorts of sacrifices for performance and styling, sacrifices such as manufacturability, cost, and reliability. We tend to forget or underestimate the sheer work that Honda engineers spend making a car that is fuel efficient, crashworthy, long-term reliable, and affordable. A civic certainly isn't as sexy as a Ferrari, but stepping back and thinking about the sheer amount of human effort that went into making such a good machine at such a reasonable (compared to a Ferrari) price is astounding.
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.
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 might just be at a very different environment but the usual basic software discussions (class design, database modeling, architecture) are mostly irrelevant as there’s always some premade thing I can use to do the job and most of my time is either making sure requirements are clear of that the teams are aligned on their deliveries.
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
Readit News
The world needs artisanal programmers like it needs artisanal attorneys. See: https://www.mcsweeneys.net/articles/i-am-an-artisanal-attorn...
This article is so similar to this satire I couldn't believe so many commenters were taking it so seriously.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:
I am saying -- there is no attorney marketing their unique skill with the Smith Corona Galaxie or with a quill. Instead, you probably want them to write a brief for you and don't particularly care how they physically do it.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."
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.
Deleted Comment
And then there’s Italian craftsmanship https://artemest.com/
https://laravel.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