Hacker News Reader

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

You have again, only offered examples of things that 'are not' artisan, and offered no definition or real argument against the sentiment of the article. No argument for what is artisan, and why it does not apply.

I'd say you have instead backed yourself into a corner where nothing is artisan, that the term can't be applied to any field at all.

If it is purely "the artifact is still what is most important, by a mile", then of course there are many that would include iPhones, an algorithm, a mathematical proof,... etc...

If an artisan can only be judged by their products, then any trash that is popularly agreed upon as 'artisanal' can make the producers an 'artisan'. It is all 'in the eye of the beholder'.

Thanks for the intellectual charity. I'll buy a coffee with it for what it is worth.

Edit: To stretch this further, if 'artisanal' using a 'traditional' or 'non-mechanist' methods, then since programming is now many decades old, I could say ::

"Well son, I'm programming in VBScript, like my father did, and his father before him. In the traditional manner of a dying generation. I don't dig these new fangled editors with their 'code completion', leave VSCode to the kids. I do things the old way and it works and my customers love it".

> You have again, only offered examples of things that 'are not' artisan,

That's simply not true. I said:

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

And went on to explain how a writer might be an "artisan".

> and offered no definition or real argument against the sentiment of the article.

That's because I do agree that some of the sentiments of the article are good, but I also disagree that muddling such good sentiments with the wrong word, "artisan", is good. I said "enjoy the process, ... , improve yourself, learn new things" isn't "artisan" because there is no definition of "artisan" which encompasses those things. An Oxford don might also enjoy the process, improve him/herself, and learn new things. He/she may be in a what we now consider a "skilled" profession (though significantly not a "trade"), but he/she never was and is not now an "artisan". See: https://www.oed.com/search/dictionary/?scope=Entries&q=artis... and https://www.oed.com/search/dictionary/?scope=Entries&q=artis...

> No argument for what is artisan, and why it does not apply.

Again, no, I don't need to make an argument for what definition applies when I've ceded the ground that any one definition is better than another.

> If an artisan can only be judged by their products, then any trash that is popularly agreed upon as 'artisanal' can make the producers an 'artisan'.

I'm pretty sure you've completely misunderstood me here. Please reread my comment (or see the double quoted section above). My argument was precisely the opposite. Programmers, and attorneys are NOT artisans because what matters most is their product, whereas bakers and cobblers MIGHT BE artisans because their process MAY contribute to our use and enjoyment of the product.

> Edit: To stretch this further, if 'artisanal' using a 'traditional' or 'non-mechanist' methods, then since programming is now many decades old, I could say ::

Yes! Exactly. This is why this notion is ridiculous.

I think we have stumbled into the age old debate over what is 'art'. And there is no answer.

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?

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

True, I think I really skipped that quote. I disagree with this part and think it doesn't link very well with the conclusion or with software artisans. Not sure if I mixed it up or the author :)

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?