To me, “artisanal” means one / very few experts carefully crafted a custom product to their own exacting standards, driven by their internal need for perfection rather than guided by a spec sheet / quality level specified externally.

There are definitely hackers who do this.

Why? Who is responsible for making it look good? fast? resilient? The architect? In software development the engineer can be the architect, the decorator, the user. AI will unleash the age of artisan software - which already exists, so many great free software developers came before us but now it will spread like a "plague". It has the potential to disrupt SaaS as we know it today.

The incentives in their industry support performance. They look around confused at the rest of the world with different incentives. And they keep running into people who say: “We can make it fast if it is incentivized” and then do a amateurish job, despite seeming to be professionals, because they lack the institutional knowledge that is commonplace in the games industry. They are amateurs (in this field) due to long-term societal incentives despite having all the other trappings of competence. It is like being Chinese and seeing a regular grown adult being unable to use chopsticks; jarring and bizarre if you lack the context that they do not use chopsticks in their home country.

It also leads to what, from their perspective, are incongruous tradeoffs. They see a 10x speedup that would take a month to implement. The developers say that is a worthy tradeoff, but they do not do it, why? Well, they lack the institutional knowledge. To reinvent all of the knowledge and technologies that would make that 10x speedup take a month would take 5 years assuming they even recognized the opportunity. 5 years for a 10x speedup is not worth it, but 1 month is; it is the researched tech tree that makes the difference and allows worthy tradeoffs to be implemented efficiently. Losing tech and knowledge leads to losing the ability to even make those tradeoffs.

As an example, I'm developing an IDE from the ground up. The current conventional approach would be to fork VSCode, a bloated, slow, over-engineered, ultra-complex Electron app reliant on Microsoft's standards.

Alternatively, I can code it artisanally, which will likely result in something worse in many ways and break in unexpected ways. But for my specific use case, it provides a much better user experience than taking the assembly-line approach to software development. The chances of this project failing are much higher using this customized approach than if I used the assembly-line method, but it doesn't matter to me - coding it this way is already so much more fun.

This seems like we are instead discussing a narrow definition of 'artisanal'.

Where I was taking more broad definition of someone at the top of their 'craft', an expert with deep knowledge of a specialized area.

I agree completely that it's not trivial and comes with its own trade-offs and side-effects, but when you achieve a good chunk of it, it brings a lot of flexibility, stability and peace of mind for everyone involved.

You can put more people on some task because it's not something only one person can do. You won't nose-dive when somebody leaves. And developers know that they can go on vacation and don't need to worry about what's going to happen to the rest of the team (I know that not everyone thinks like that, but in my experience enough people do).

Okay, but you seem to be ignoring the first half of the article. You know the part that tells us it is a great big joke:

"Real Programmers wrote in machine code. Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly."

No, I'm reading critically. Just because an article does not readily offer up a definition, it does not mean it isn't working with one.

However, I'll try to be intellectually charitable, here, and say it's plausible a reader could feel the article unhelpfully conflates many definitions of "artisan". Unfortunately, all such definitions don't make much sense in the context of programming. What's wrong is not the concluding sentiment of "enjoy the process, ... , improve yourself, learn new things", it's that "artisan", even in its many definitions, doesn't touch upon those noble sentiments. Attorneys and programmers simply aren't artisans, even if they enjoy their process, and improving themselves, and learning new things, and your insistence to the contrary is self-aggrandizement.

That isn't to say I would limit "artisanal" to the physical crafts. I might extend it to any endeavor where the process is part of our use of the product. Like -- I may know this or that writer drinks 20 year old Scotch, and smokes only three cigars a day, while he types at exactly 45 words per minute on his decades old Smith Corona. I can understand being romantically engaged by that process.

However, while this kind of process might be important to our enjoyment of that literature, is is almost entirely unimportant to our use of software, because the artifact is still what is most important, by a mile. I couldn't care less whether a game designer copied a method from Boost or wrote it from scratch him/herself, just as, I couldn't care less whether my attorney saw the face of God after smelling the dust mites in the Westlaw Reporters at the law library. The romance of the "artisan" is almost entirely incoherent in this context.

It's why "I am an Artisanal Attorney (because I make my own paper and write briefs with a quill)" is so funny. Do me a favor and try to write your own. "I am an Artisanal Programmer (because I do all my Objective C programming on a NeXTcube)..."

* (excluding languages that compile to an IL like C# of course, but decompiling C# is trivial)

In my experience, this is highly subjective.

One of my employees was probably the best coder I’ve ever known. His code was well-structured, well-documented, clever, efficient, bug-free, and a total bitch to comprehend. He would regularly produce miraculous results. We worked together for almost 27 years.

I guarantee that a lot of folks here would call him a “bad coder,” because they would have difficulty easily understanding his code.

I find that when people talk about “good,” they emphasize traits that they, themselves, have, and disparage traits that they don’t have.

In the aggregate, results matter, and “results” are more than just getting today’s goals accomplished. It would be nice if that were the only concern.

For example, I ran a shop, where we maintained a huge legacy codebase of C++ image processing code. We had to maintain it, ourselves, as well as train others to work on it. This meant good documentation, good code structure, and good foundational substrate.

Introducing new coders to our codebase meant immersive training. Japan regularly sent folks over for months, to learn our code. These were top talent. Just about every one of our Japanese engineers had at least a Master’s degree in Engineering. It was a marquee corporation, and employed top-shelf engineers.

That’s quite different from hiring bootcamp-trained JS programmers, and expecting them to maintain Swift code. I know many people that insist that “any good engineer” can learn any language in a couple of weeks.

I’ve been at this game for a while, and have worked in quite a few languages. I’m smarter than the average bear, and have made fearful messes, because I didn’t understand the tools completely.

I have found that I can learn about 75% of a language quite quickly.

That other 25%, though, could take years, and languages seldom stay static, so I’m constantly catching up on the latest stuff. It also includes style, which is often an artifact of understanding how to use the language properly.

Also, learning a language is only part of it, as the APIs and SDKs are even more important. Learning those can be difficult, and I have often had to throw away years of work, when an SDK is swapped out. I’ve been writing Apple software since 1986, so I’ve had to do that a number of times. My first Apple code was in procedural Pascal and 68000 ASM. Adobe Photoshop is probably one of the oldest codebases still in use, and it started off as object Pascal, using MacApp 0.9 beta.

Tom Knoll was definitely top-shelf, and I was tasked with adapting some of his code for use in a different context, back in the 1990s. It wasn’t easy, but I did it, and learned to be a better coder, as a result.

Over the years, I have changed my opinions and points of view; frequently by screwing up, and also, by taking the time to understand code -and not just code, but also the reasoning-, of talented predecessors.

I remember once, hearing someone say “That ‘cruft’ you’re complaining about, is what I call ‘bug fixes.’”

I love coding, because I’m constantly challenged and humbled. I stand on the shoulders of giants, and am grateful for their example.

Indeed, it depends what the API boundary is for the selection to be exported.

If it's the whole program without some well-known libraries (like the C runtime library for a statically linked executable or the Psy-Q SDK for a PlayStation video game), then the API boundary is trivial in the sense that it's a documented one. The hard part is actually figuring where those libraries are so that you can cut them out of your selection while exporting.

If it's a particular subset internal to the program then it's trickier because you don't have that (but if you know you want to export it, then you must already know something about it). Traditional reverse-engineering techniques do apply here, it's just that you only care about the ABI boundary instead of the whole implementation, so it's usually less work to figure out.

However, if you get it wrong then the toolchain will usually not detect it and you'll have some very exotic undefined behavior on your hands when you try to run your Frankensteinized program. Troubleshooting these issues can be very tricky because my tooling doesn't generate debugging symbols, so the debugging experience is atrocious.

I've always managed to muddle through so far, but one really nasty case did take me a couple of weekends to track down (don't cut across a variable when you're exporting because you'll truncate it, which can lead among other things to corrupting whatever was laid out next in memory at runtime when the original delinked code tries to write to it).

I might like to think of programmers as 'craftsman' that can reach some height of achievement/skill to be deemed as 'artisans' in their 'craft'. Maybe like a Dijkstra, or even a John Carmack/Doom.

But to your argument I think. There must be some 'physical' product. So there are some programmers or even accountants that have reached some heights of understanding their craft but their product does not count because it is too ephemeral. There is a necessary quality of a 'repeatable' physical process and forming a physical product to count as 'artisanal'.

A lot of programmers are crap or mid. Just like the woodworker, or chef, that could be great, but most of them are mid or crap.

I'm sure there are a lot of people that shop at Hobby Lobby, that thing of themselves as artisans. But are mostly not.

So you need some combination of a process and also some general agreement of the admirers of the product.

I just fall on the other side of this gray shady line, that programmers and writers, do generally produce something, a product, and they practice to become experts at it. They also have a process that contributes to the product.

Even if like 99% of Chefs, 99% of programmers are crap, with no process and crappy products. They both are producing products, and the best ones have some process.

"Perhaps it is undeserved, because you don't seem to be reading what I wrote."

On this point, I think there is also some bias. You think your points are clear, but frequently people think they are clear because they have their own internal perspective that makes what they write seem clear to themselves. But are not really quite getting it out onto paper. If your points aren't landing, maybe at some point it is not the readers fault for not grasping them. I really have tried to follow yours, and don't think we are even disagreeing that much.

If I was to be intellectually charitable, I think this is probably a case of a very contentious subject that has been argued for a few thousand years, and we jumped into an internet argument in the middle, with very different backgrounds, that can't be resolved.

What is art? Programming isn't the only time this argument has happened when a new medium/technology came into existence. Is photography art? Many think not, many think it is. Can you have an artisanal photographer? Is a portrait painter an artist, but not a portrait photographer? What about metal working, welding, you would say yes? Or Poets, you would say no?