What a load of horse shit.

I assume this is just in jest, because we absolutely are not.

Tired of this trope. Learning data structures and algorithms is not about memorizing the specifics of some particular algorithm. That's like thinking that learning math is about memorizing formulas.

DS&A is about learning *algorithmic thinking" and how common data structures actually work, so you can begin to build a toolbox of things you can use when making your own data structures. Software engineers that are actually good know this shit backwards and forwards, because it does actually come up all over the place (and these are the kind of people that actually write libraries). Even the basic things you learn in school are actually incredibly useful for understanding the implementation details of databases and how query planners and indexes work, for example (very helpful when trying to understand query performance).

And don't get me started on just how fucking much directed acyclic graphs come up in the real world. Git? DAG. Any package manager? DAGs. Nix? DAGs. Open Telemetry? DAGs (the main data structure is a tree which is a special case of DAGs, but if you use linked spans, it would form a DAG). Hell, I'm working on something right now that needs to be modeled as a DAG. It's almost comical how useful they are.

We should be encouraging people to learn and grow more, not less.

It's not body shaming to make fun of grotesque body modification that looks fucking stupid.

No, the author is not confusing them. It's everyone else that has been confused insofar as they use "REST" to describe APIs that are not actually REST. True REST is a way of architecting networked applications according to a set of constraints, as defined by Roy Fielding in his original dissertation. Here's an excerpt that sums it up:

In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.

Many "REST" APIs do not adhere to these constraints, especially self-descriptive messages and hypermedia as the engine of application state (also known as HATEOAS). Note that this says nothing about HTML: HTML is but one representation of hypermedia, but far from the only one. Hypermedia is something that allows discovery of additional, related resources by way of links between resources. There are a number of ways of doing this, such as RFC 8288 Link Headers or embedding links within one of a resource's representations (such as a JSON representation).

It's a much larger topic than I can fully explain here, but I highly recommend reading Roy Fielding's dissertation, especially Chapter 5 which talks about REST and what it is.

I also highly recommend this blog post from Google Cloud's engineering team, which talks about why you should use links instead of keys to represent relationships in API design: https://cloud.google.com/blog/products/application-development/api-design-why-you-should-use-links-not-keys-to-represent-relationships-in-apis.

From what I remember, Vscode has quite a fair bit of native code in various areas to make it perform better. So it may not be the representative Electron app for comparison.

That's what Open Telemetry is for, honestly, specifically tracing. I'm in the process of adding tracing for all of our web handlers, http client calls, database transactions/individual queries, and asynchronous jobs. Should give us a pretty good view into the performance of the system, and allow us to monitor for things like performance regressions without any dedicated profiling needed (though we certainly could add additional profiling information through Otel down the road). Since I know you're a Haskeller (recognize your handle), the hs-opentelemetryecosystem is quite solid and has integrations with a lot of libraries in the wider ecosystem, like wai, persistent, postgresql-simple, conduit, and a bunch more. I haven't needed to write too much of our own instrumentation, aside from our job system since that's a bespoke system.

We are fully capable of thinking PHP, NPM, and PyPi are trash simultaneously. Though it should also be said that only PHP has had decades of security flaws in the language itself, rather than a package manager.

It's just a very poorly designed language with countless footguns and fucking idiotic standard library functions, on top of being a running joke, security-wise.

Or, you know, your middle schooler can just draw silly things like we all did growing up.

This is a better discussion of this topic, imo: https://www.frank.computer/blog/2025/05/just-a-tool.html.

It's not, they are correct. There are so many telltale signs of AI code it's not even funny. The most obvious being the absolutely garbage comments that people invariably leave in. And the god awful naming of things.

But it's more than that. If you're in this industry long enough, you get pretty good at reconstructing a real author's thought process when they wrote the code. Part of understanding code is understanding why it was written the way that it was, which means understanding how the author thought. Sure, there was plenty of garbage code and stupid thinking, but it was still thought and usually had its own kind of internal consistency. AI code has no thought process, no reason. It is pure mimicry, an amalgamation of millions of authors all at once. It has no internal consistency. It produces code no human ever would, because it doesn't make any fucking sense. It's like reading an alien language, where the constructs it produces are so aberrant to how any human would ever think that it could be nothing but an LLM.

I definitely can't tell you everything about a piece of code by reading it, but I sure as hell can smell an LLM in it, because it fucking stinks.

Sure that works too, though you would likely need to configure your git forge to treat that new branch as the master branch. A branch is ultimately just a pointer to a particular commit, though usually git forges treat one particular branch as "special" (it's the default branch used for clones, and typically disallows direct pushes). This is usually the master or main branch. So my git reset suggestion was intended to reset whatever the default branch of the upstream repo was (probably master).