There is a subtle scenario with read-modify-write transactions in MVCC where SQLite lacks some grace (in my opinion).
In MVCC, transactions work with a point-in-time (read "between atomic transactions") consistent "read snapshot" of the database.
Consider this example:
Transaction A begins and reads from table foo.
Transaction B begins and updates table foo.
Both transactions commit.
There is no conflict here because these transactions are isolated from each other via the snapshot mechanism. Transaction A's read snapshot is immutable and will not see any writes from transaction B, even if they are happening concurrently.
Now what happens in this example (from the OP):
Transaction A begins and reads from table foo.
Transaction B begins and updates table foo.
Transaction B commits.
Transaction A tries to update foo.
This is a true conflict because both transactions are trying to write to foo, and transaction A's writes might be based on what it just read. There is no consistent way for A to proceed, because B already wrote to foo, invalidating A's read snapshot.
So SQLite handles this by returning an error to A, effectively requiring A to restart the transaction.
There are other ways this could be handled though. The DB could optimistically retry the transaction for you. There is even a special BEGIN IMMEDIATE; statement that it could use to proactively take a write lock on foo so that the transaction doesn't get starved by other writers. But SQLite puts all of the responsibility on users to handle this.
I'm not an expert, so there could be a very good reason that SQLite works this way, but it feels a bit annoying as a user.
I don't actually know off the top of my head how PostgresQL handles this particular scenario.
I agree with the article's ideas, but certain things about the execution bother me.
calculate_order_total_for_customer. I'd just call it calculate_order_total. It's clear than any order will have a customer, it's in the type signature.
is_user_eligible_for_discount. I'd call it user_is_eligible_for_discount. Because inevitably that function is getting called in an if statement, and you'd rather it read closer to proper English: if user_is_eligible_for_discount: ....
"Designing for Tomorrow". I agree that dependency injection is a valuable technique, but it's not always strictly necessary and they seem to say you might as well always do it just in case. That's counter to YAGNI. Make sure you have an immediate use case, or let future you do it if you end up needing it. It's not hard to refactor something to inject a dependency.
As for actual coding, I use ChatGPT sometimes to write SDK glue boilerplate or learn about API semantics. For this kind of stuff it can be much more productive than scanning API docs trying to piece together how to write something simple. Like for example, writing a function to check if an S3 bucket is publicly accessible. That would have taken me a lot longer without ChatGPT.
In short: it basically replaced google and stack overflow in my workflow, at least as my first information source. I still have to fall back to a real search engine sometimes.
I do not give LLMs access to my source code tree.
Sometimes I'll use it for ideas on how to write specific SQL queries, but I've found you have to be extremely careful with this use case because ChatGPT hallucinates some pretty bad SQL sometimes.
ICE just needs to scan his face with the Racistron 2000 app and it overrides his birth certificate, haven't you heard?