> no, we shouldn't be assassinating people.

"I've never wished a man dead, but I have read some obituaries with great pleasure"

Yes, I meant something else, and of course I'm not advocating for hard to understand code. However, as the sibling comment suggests, what's obscure or hard is relative.

The problem with indiscriminate application of "code has to be easy to understand" is that it can be used to make pretty much anything, including most features of your language, off limits. After all, a junior developer may not be familiar with any given feature. Thus, we can establish no reasonable lower bound on allowed complexity using such a guideline.

Conversely, what’s too simple or too difficult is very specific to the person. Somebody who’s coming to a junior developer role from a data science background might have no problem reading 200 lines of SQL. Somebody with FP background might find data transformation pipelines simple to understand but class hierarchies difficult, and so on. So the "easy to understand for anyone" guideline proves less than useful for establishing an upper bound on allowed complexity as well.

Therefore, I find that it’s more useful to talk about a lower and upper bound of what’s required and acceptable. There are things we should reasonably expect a person working on the project to know or learn (such as most language features, basic framework features, how to manipulate data, how to debug etc.) regardless of seniority. On the other hand, we don’t want to have code that’s only understood by one or two people on the team, so perhaps we say that advanced metaprogramming or category theory concepts should be applied very sparingly.

Once that competency band is established, we can work to bring everyone into the band (by providing training and support) rather than trying to stretch the band downwards to suit everyone regardless of experience.

It's the exact same benefit as having your own car. It's a common reason people have to avoid shared transit.

I found it really funny. It's obviously probably useless for actual medieval music[0] but I think it can find it's users in bardcore or dungeon synth circles.

You can definitely recreate this just by collecting appropriate VSTs and sample libraries, even probably by just loading some "medieval samples" to some groovebox.

But if I got this second hand on cheap price I would definitely make some fun with it even if it has somewhat cryptic labels.

[0] https://www.youtube.com/watch?v=X6_8ZEhmaGE

> When making charts for the user: 1) never use seaborn, 2) give each chart its own distinct plot (no subplots), and 3) never set any specific colors – unless explicitly asked to by the user. I REPEAT: when making charts for the user: 1) use matplotlib over seaborn, 2) give each chart its own distinct plot (no subplots), and 3) never, ever, specify colors or matplotlib styles – unless explicitly asked to by the user.

This kind of stuff always makes me a little sad. One thing I've loved about computers my whole life is how they are predictable and consistent. Don't get me wrong, I use and quite enjoy LLMs and understand that their variability is huge strength (and I know about `temperature`), I just wish there was a way to "talk to"/instruct the LLM and not need to do stuff like this ("I REPEAT").