I don't think everyone leaves with the next best salary upgrade if you pay fair. Leveling up a junior should be rewarded in time. Part of the mentoring is to teach them how to fight for your upgrade, right?

Good culture is good, but no culture fits all personalities.

In the end you probably have to accept that some portion of mentees will leave and try to minimize the rate.

What I would be afraid of that grown up juniors may get stuck in their learning environment and remain junior for way too long.

You started out with the claim that your database is fast, but you added almost no info to support this claim. Don't get me wrong but if you remove the initial claim the article would be more trustworthy.

The benchmark results are right in the blog post.

> The purpose is to broadcast your view of your priorities, so interested parties can ask that they be adjusted.

Concrete team stories are usually quite clear. OKRs force you to encode a bunch of them into objectives and key results. This produces utter nonsense if the duties and opportunities are generic or fragmented. Not every team can write a clear OKR which makes it obvious what's happening, especially if you servicing multiple departments.

Propagators of those techniques also tell you that sometimes there is no help. I.e. completely irrational positions or mindsets, as well arguments that are already set with hostility.

Plus the mercy of 3d card companies to make their linux driver's suck less.

If you want transaction like behaviour you can simulate it. Not sure if that is even remotely a point with Web APIs.

Web api's are a lot of things. Some are transactional, like booking systems, inventory systems, banking systems, web shops...

Ed: however the thing with tls is that it is session based, and it's probably a good idea to surface that state to the application, so you had a connection-based transport, and you could say: "I know this session, it's encrypted, and I've flagged it as authenticated to this user, and can map that to authorization" - rather than have a cookie that can get stolen rather easily.

You might still hijack an encrypted session of course, but it should be a bit more tricky.

Sql databases are usually behind an application layer. Still they can suffer from RCE. Sqlites model is no protection.

Now I am intrigued to make a minimal snippet that creates a histogram of loading times.

To mock about the doings of others is easy. Plead me guilty. But there are rights and wrongs on both sides. Usually.

My theory is that engineers are often stuck in a filter bubble. Especially newer engineers. If you read all day about microservices and SPAs, there is at some point no place for something else. But classic web app achitectures are still doing very well. At a common scale they do things better with less complexity. The point is that they aren't very heavily discussed anymore. Most problems have been discussed and there are solutions for it. For me it is hard to argue about the problems of modern approaches. Not because I don't have any arguments, but because mostly the response is that we have to throw more code, hardware and architecture at it. It works for FAANG, why argue?

All sides need to pay more respect to things that work. And we have to set context when/where/why it works.

True, definitely Amazon is heavy on the Serverless marketing/filter bubble.