chazu

Legally prescribed pharmaceuticals, caffeine, lately nicotine. I also have to start working immediately when I sit down - and continue working until the day is over. Any prolonged break risks taking me out of my resource state.

It's great.

Absolutely - anyone who focuses this much on personal life during an interview is almost assuredly clueless as to how to manage people.

I've got one of each and they are unquestionably the best things I've made, done or invested in.

I'm consistently shocked by the number of people who have never heard of this principle. Introducing arbitrary numerical limits (emphasis on _arbitrary_, as performance limitations or other actual requirements obviously trump this rule) is a design decision that I find myself having to clean up after frequently.

I see a lot of people here questioning the wisdom of the rule, however, like every other principle used in SWE, it shouldn't be applied blindly. Ask yourself "why am I specifying that a maximum of five wangervanes can be specified in the turboencabulator settings?" _IF_ you have a good reason, fine. Most of the time you will not.

Examples of issues Ive seen in the wild because people violate this rule include payroll systems with an arbitrary maximum number of pay codes and review app systems with a static number of review apps.

Just like every other heuristic in software engineering, its not a silver bullet, but generally speaking, this principle will serve you well.

Cue is one of the most exciting developments that's impacted me professionally in recent years. I can't advocate for it enough.

Not sure what you mean. Sometimes the word API is used in one sense, sometimes in another. It's a useful distinction insofar as it allows you to talk about APIs as things used by programmers. I find many developers have a hard time understanding this sense of the word API and as a result fail to apply good API design principles such as SOLID. In fact I think this is often what separates mediocre programmers from good ones.

I want the author of htmx to get together with the guy from pandastrike and rant about the misuse of REST for an hour a week. It would be my new favorite podcast.

An API is also the interface used by humans to create programs. When you use a library, you're using its API. This sense of the term API is often lost.

Very cool - thank you for sharing. I like the idea of task-based benchmarking for UI toolkits, and I'm also happy to see more tview code for me to study.

90% of SREs and SRE managers haven't read the SRE book(s).

99.9% of folks hiring SREs or starting SRE teams haven't read the SRE book.

The SRE book (and its sequels) say quite plainly what SRE is and isn't. They also say that not every org is going to be exactly like google so no, "we're not google" isn't an excuse.

the E in SRE is for engineering. As in software engineering. SREs are software engineers. Or should be. If your SREs don't know basic SWE principles, they're not SREs. If your org isn't applying software engineering principles to minimizing operational complexity at scale, your org isn't doing SRE.

I'm constantly shocked by how hard these things are to grasp, even for most SREs. If the problems I (occasionally) get to solve weren't more interesting than most regular product work, I'd get out of "SRE" entirely.

> From the productivity standpoint, it is not acceptable that a Machine Learning engineer or a Full Stack Developer are expected to know Kubernetes. Or that they need to interact with a Kubernetes person/team.

I agree - these things should be abstracted from the developer - thats the goal of SRE/platform engineering - DevOps is [supposed to be] as you said, a philosophical and cultural stance around early productionization. While not mutually exclusive, they're not the same thing.

But back to your point re: orchestration-level concerns being foisted upon devs - at a shop of any size, there will be devs who feel they _need_ to touch kubernetes to get their job done (wrongly, IMHO) as well as devs who want nothing to do with it - so without engineering leadership throwing their support heavily behind a specific approach, its hard for a small team to deliver value.

That story was truly a horrific vision of the future.

Has this been translated into English? Cursory googling returns nothing.