No issues so far.

And this is what Markdown is for: its just enough above plain text such that you can get at least 95% of what you need for a blog post, whilst still have the source be easy to type and proof read.

Most importantly, they have the diligence and patience to methodically test subtly different cases, which I frankly don't have.

On the question of whether QA slows things down, I have to ask: slows down what? Slows down releasing something broken? Why is that something to optimize for? We should always be asking how long it takes to release the right thing (indeed I'm most productive when I can close a ticket after concluding nothing is needed).

After all, even if one has some slow and beastly, unoptimized Spring Boot container that chews through RAM, its not that expenseive (in the grand scheme of things) to just replicate more instances of it.

My experience with something like the latest Claude Code models these days has been that they are pretty good at SQL. I think some combination of LLM review of SQL code with smoke tests would do the trick here.

In practice though, for most enterprise web services, a lot of real world performance comes down to how efficiently you are calling external services (including the database). Just converting a loop of queries into bulk ones can help loads (and then tweaking the query to make good use of indexes, doing upserts, removing unneeded data, etc.)

I'm hopeful that improvements in LLMs mean we can ditch ORMs (under the guise that they are quicker to write queries and the inbetween mapping code with) and instead make good use of SQL to harness the powers that modern databases provide.

Its already quite debatable whether software developers should be called software engineers, but this is just ridiculous.

What you might consider "middle class", suburban households, and up. These "upgrades" are something that you can roll into your mortgage.

> Why are they going off grid?

Electricity and water availability issues.

For example, I live in an area where water is unavailable between days and weeks, every few weeks. The systemic issue in my municipality is that they have not kept up with the maintenance of water pipes, which means a significant portion of water pumped from the national provider is lost via leaks. Thus when some pumps and reservoirs go offline due to power disruptions, the loss of flow can lead to no water in higher lying areas that takes time to restore.

There are private solutions to this - the most affordable option is to install a big water tank on your property that in affect acts as a water battery. A more expensive solution is to install a borehole on your property, and to draw water from the water table (this might make sense for a complex, or a rich household).

This is the same issue I've had with ORMs - I get that they make it easier to generate functionality at speed, but ultimately I want control over the biggest performance lever I have available to me.

As the country's ability to provide basic utilities falters, sufficiently wealthy households go partially or completely off grid, depriving revenue for the utilities and further exacerbating the problem.

Answering that question requires domain interrogation. If after that I'm still unsure, then I err on the side of having two copies with maybe a comment on both pointing to the other.

The main reason is more to do with maintaining Go code than writing it: I find it very helpful when reading Go code and debugging it, to see actual containers of values get passed around.

Also, whenever I write a bit of boilerplate to return an error up, that is a reminder to consider the failure paths of that call.

Finally, I like the style of having a very clear control flow. I prefer to see the state getting passed in and returned back, rather than "hidden away".

I know that there are other approaches to having clear error values, like an encapsulated return value, and I like that approach as well - but there is also virtue in having simple values. And yes there are definitely footguns due to historical design choices, but the Go language server is pretty good at flagging those, and it is the stubborn commitment to maintaining the major API V1 that makes the language server actually reliable to use (my experience working with Elixir's language server has been quite different, for example).

A Private (system) Investigator. :)