Hacker News new | ask | show | jobs
by mustache_kimono 642 days ago
I'm going to be a little negative, so please bare with me.

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,...
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).

6 comments

“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.

Having seen some of their talks, I do not think they realize the underlying problem and understand its manifestation. They just see that their “fellows” churn out slow software without even understanding how to make things fast due to tradeoffs that society has made on their behalf that left their fellows with no knowledge of performance optimization. They feel a sense of wrongness that things are so different across the aisle, but can not put their finger on it precisely.

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.

I can think of 50 things which would make the project I'm on faster, better and more secure but the business is not particularly interested in them right now.

The business wants its stated requirements met (plus a short list of key non-functionals) while minimising cost. Performance is not even specified. I don't think there's any "lost knowledge" involved in this particular case, they just don't want to pay me to make it better than it needs to be.

Doing my job well means minimising the time (and by implication the attention and effort) I put in to the software.

This seems quite directly opposed to the artisanal ethos.

An artisan was historically a guy working for himself in a small market shop, carving at a chair or sewing leather shoes. The masons tasked to build the castle walls were not "artisans" so there we could see the same focus on efficiency - although a bit of beauty had still its place here and there. My point? Today we don't have those artisan shops, just expectations from regular masons to carve gargoyles at every wall corner.
Changing the incentives still sounds like it might be a good first step.

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...

But aren't there artisanal attorney's?

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)

> But aren't there artisanal attorney's?

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.
I guess by this argument, writes/authors also cannot be 'artisanal'?

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.

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

Perhaps see the article. This is the definition which is most like the definition it uses.

"Perhaps see the article"

Are you joking, it was 2 paragraphs. And did not offer any definition.

You are reading into it you're own internal monologue, and thinking the article stated more than it did.

So if we go by the article using example of 'making a table', you could say writers/authors/accountants would NOT be artisans. Since they are not physically crafting something.

or

If it is more about "enjoy the process, ... , improve yourself, learn new things", then it is very much more general and includes many fields.

> You are reading into it you're own internal monologue, and thinking the article stated more than it did.

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)..."

> this is an engineering discipline

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.

Got it. I don't think writing in x86_64 is any more artisanal than Python or JavaScript. It's actually quite easy to make the distinction. Assembled software - using multiple libraries in place of crafting (almost) every piece of it - is the opposite of artisanal software. You can have that with assembly, C/C++, Java, or JavaScript.

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.

> Assembled software - using multiple libraries in place of crafting (almost) every piece of it - is the opposite of artisanal software.

> 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.

I am sympathetic to this way of thinking about "artisanal". I guess for me it has so much baggage re: food, I don't think of it this way. I'd perhaps call that/your way the "DIY way", because you're right -- it is sometimes appealing and advantageous, even if I'm not certain that's what the article intended.

> even if I'm not certain that's what the article intended.

I have the impression that was exactly the intention of the article:

  > In the coming years, we’ll see more and more people making software like someone building a table in their backyard or garage, they’ll enjoy the process and add their own personal touch.
  > If you love coding the way we do it now, keep at it! enjoy every moment, improve yourself, learn new things, keep coding!
> > I don't think writing in x86_64 is any more artisanal than Python or JavaScript. > I have the impression that was exactly the intention of the article:

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."

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.

> 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.

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.

Sometimes is ok write code just for fun.

https://jairojair.com/articles/coding-just-for-fun/

Yes! Sometimes people put focus on right or wrong and forget to enjoy the process.

I wrote a little bit about it here: https://jairojair.com/articles/coding-just-for-fun/

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.
Ah, I guess you’re right.

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.

> I'm going to be a little negative, so please bare with me.

took off my shoes, does that count?