It's low priority in the sense that people in charge tend not to value it.

That's different from saying it is not impactful, or wouldn't lead to a good business outcome, if the software were built better.

Software that needs to be babysat is an ongoing opportunity cost.

You state this so confidently, like every person who walks through the door to interview will be 100% honest about their level of experience.

Have you ever interviewed? Nobody _wants_ a software engineer on their team who is awful.

Sometimes they slip through the cracks for a variety of reasons.

Using your personal experiences and the personal experiences of people you trust as an anchor is a good thing. It keeps you from falling for propaganda. Note that this DOES NOT mean studies conflicting with your personal experience are all wrong.

The tricky part here is understanding the limit of what your own experience can tell you.

The entire point of slowing down is so you don't do this. Understand the problem well first, so you don't waste time building something that was never viable in the first place.

The author isn't advocating for perfect. You have to understand the problem well enough to know what all of the critical assumptions are. Some assumptions will derail an entire project if you get them wrong. Others will be a minor inconvenience, at worst.

In software, having a solid handle on future architecture means you can speak to how unanticipated new features fit in. You know what parts you can skip for now, and have it not be a big deal.

I've started to wonder if many of the people obsessed with speed lack capability. If you can't build something well, you can try building something poor quickly. This certainly applies to my current employer.

So many businesses are pushing AI hard. People with varying levels of job (in)security want to be seen as "leading the charge" into a post-AI era.

LLMs can do some really impressive things, don't get me wrong. But I regularly find massive blunders in the code it produces.

And that actually makes sense if you understand how LLMs operate and the quality of software on GitHub.

Dark matter is a great example.

Our understanding of gravitation didn't cleanly apply at ultra-large scales so we had to add a massive fudge factor.

You can't "go faster" than the speed of light, but space in between things can expand faster than the speed of light.

It seems like things that are "settled" regularly get an "ope, but except for this special case..." treatment.

The PR reviewer isn't the only person who will ever review your code, you know.

The first thing that came to mind for me: how do you change a single site's password? The article doesn't say. It only mentions that changing the master password would require changing all passwords. That also seems like a complete non-starter.

There is an array of useful functionality that modern password managers provide, too: password sharing, saving select file content securely, password history, storage of security questions and answers, storing username (when you use something atypical for anonymity).

I can't help but feel like this idea is a dud. It's neat in an academic sense but it can't seriously compete with what already exists.

Where in the US do you find it's difficult for people to get an ID? Where is it not? What percentage of the population has an ID in a place where it's difficult to get one vs somewhere it is easier?

What constitutes an ID being expensive?

Nearly every country in the world requires proof of citizenship to vote. How is the rest of the world dealing with this problem? Do you think that their democratic processes might be compromised because of it?

I am talking about American support for a working legal immigration process, and enforcing that process. Not everyone agrees about exactly what it should look like.

I'm not talking specifically about the actions Trump is taking or the job ICE is doing currently. The current sentiment around ICE is very negative.

That's been happening for a long time in the US. Staggering military industrial complex. Tens of billions lost in COVID relief. Billions lost in Minnesota due to unchecked privatized social welfare fraud (which has been known about for a decade).

Some mistakes will happen. What we have is unacceptable. If the government can't handle the money responsibly, it has no business collecting the money.

If people immigrate to America, the arrangement should be mutually beneficial.

We are not, and should not be, the self-appointed saviors of the world.

Traefik really is awesome once you can get your head wrapped around the configuration.

I appreciate that you revised the docs, but I still found it quite difficult just to get started. My experience was poor enough that I almost switched to Caddy. The thing that kept me from doing that is that Caddy requires a custom container build for DNS-01 ACME challenges which I didn't particularly want to deal with. I found Caddy's documentation much easier to grapple with, so that could serve as some inspiration.

I have some feedback I'd offer of my own, too:

1. I'd recommend you take a look at the Divio documentation system: https://docs.divio.com/documentation-system/. Your documentation aligns to this vaguely, but I'd recommend reading about the different doc types and applying that feedback throughout the docs.

2. Traefik's tutorial and how-to docs are very dense and feel overwhelming. [1] Related to my first point, I think you're trying to provide too much information in the wrong places. Tutorials and how-to guides should be very focused and limit explanation to only that which is absolutely necessary.

3. Reference and understanding docs are mixed together. I'd recommend using an approach more like Caddy's, where the config reference (https://caddyserver.com/docs/json/) shows prominently what the expected config schema is, and all of the fields are explained briefly. If there is very nuanced behavior for a particular option, consider moving that to a separate reference or explanation page.

4. Having a few How-To guides for the most common patterns which include complete configurations would be helpful.

[1] Here are some concrete examples:

- On https://doc.traefik.io/traefik/setup/kubernetes/, there is a whole introductory session about setting up Kubernetes and I have to scroll before reading anything related to Traefik. It's not only unnecessary -- it's noise. Nobody is going to consult Traefik's docs for setting up Kubernetes, so just omit it.

- https://doc.traefik.io/traefik/setup/kubernetes/ and https://doc.traefik.io/traefik/getting-started/kubernetes/ are different pages which seem to explain mostly the same things. They both include too much irrelevant information, like overly explaining what Helm commands do. Similar to the previous point, it is not the job of Traefik's documentation to explain Helm to me.

Like all genres, games within the roguelike genre (or what some people call "traditional roguelikes") have some variance. But if you played two games in the "traditional roguelike" genre, you'd definitely feel the similarities.

These days if you pick two random games on Steam with the "roguelike" tag, you're going to get two experiences which are not even reminiscent of the other.