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.

one could argue that the role of sys admins just got more specialized

Read the introduction to the SRE book, available free online [1] - and you'll see that SRE is defined _in contrast to_ systems administration. Its specifically defined as software engineering with the goal of managing operational complexity.

Modern shops' failure to understand this (most SREs haven't read any of the book, let alone stopped to think what SRE actually means) is IMHO a primary factor in the failure of most "devops transformations"

[1] https://sre.google/sre-book/part-I-introduction/

That story was truly a horrific vision of the future.

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

Agreed - this idea is often cited by fans of the book 'Team Topologies'. Its important here to distinguish between the idea of _an_ internal platform team and a _platform engineering_ team. A platform team is any team which provides services to internal clients - one such team would be the one (or ones) supporting whatever platforms-as-a-service are being used to deploy software to production.

This looks great and I hope to deploy it and kick the tires soon, thanks for sharing.

Currently I've been using movienight[1] for this, but it sounds like your app is much more feature rich.

[1] https://github.com/zorchenhimer/MovieNight

ECR borked for us in east-1

Newer solutions which use abstraction layers like postgREST will hopefully result in easier migration down the road - but I doubt most products/projects use such a thing.

This. I went down this road for some time before I reached a point with Pharo where I feel comfortable doing things their way.

You don't need any boilerplate to write an operator - you can write an operator in any language. I've written several in python and they all clock in under 300 sLoC

Thanks for the leads on this - very excited to look further into it.

These projects are a source of fascination to me, however a persistent question for me is how do these more symbolic approaches to cognitive modelling figure in today's world of ML and data-driven AI? I'm very curious to know where and to what extent the symbolic approaches of the past (and present) meet with ML? I ask because you clearly have some exposure to these sorts of projects - any sources you can provide would be appreciated.

This person gets it. Which is rare - do you want a job? :)

But seriously, you hit upon something which is important, but very hard to communicate/admit - a big part of making the "DevOps Transformation" happen - which is a cheesy term but it conveys something better than just DevOps - is saying _no_ to devs and traditional SysAdmins and giving them a better alternative. Unfortunately this means that SysAdmin skillsets need to be supplemented or even supplanted by SWE skillsets. But the TL;DR is yes, doing DevOps often means putting the brakes on fun.

This is why I like the 'platform engineering' meme - much better way to frame the value proposition. See: Thoughtworks' blogs and podcasts on platform-engineering-centric topics.

This is absolutely wrong - DevOps is not a job title. At least it shouldn't be, as anyone in the sector will tell you. The conflation of DevOps responsibilities and specializations with SysAdmin work is the reason why the vast majority of "DevOps" teams are...vastly unqualified.

GitOps is a deployment methodology. Sure its a buzzword, but product devs have plenty of those as well. I _do_ agree that DevSecOps is a pointless concept - as is FinOps and other xOps crap - its become a way to throw work over the wall, which is what DevOps was trying to fix. This endless taxonomy of terms for the people who do shit that we don't want to do is a definite drag on _actual_ acceleration of SDLC in the cloud.

You hit on the most important thing about DevOps: DevOps is not a job title - as any DevOps person will tell you. Obviously it _is_ a job title, but what they mean is that it isn't supposed to be one. Its supposed to be a way of looking at the SDLC to reduce friction, decrase siloing, and approach shipping and building software into production with the same SWE discipline that feature work is given. The failure of the industry to actually grok this has resulted in the re-framing of DevOps as SRE - which is also misunderstood by 99.9% of engineers and managers - and more helpfully, in the rise of the Platform Engineering meme. In my time as a platform engineer - or what devs call a 'DevOps Engineer' - which has never been my job title thankfully - I've found that people either think "DevOps" are wizards or drooling idiots. At the same time, however, many devs are unwilling or unable to consider the complexities of productionizing an application before those complexities cause delays. The point of DevOps was to catalyse cultural change, not to build a new silo for people to misunderstand and ignore.

Talk about myopic.

I suggest Accelerate, Balancing Agility and Discipline, The Phoenix Project and the OG Continuous Delivery book by Jez Humble and David Farley.