I worked at a company with a world-class QA team. They were amazing and I can't say enough nice things about them. They were comprehensive and professional and amazing human beings. They had great attention to detail and they catalogued a huge spreadsheet of manual things to test. Engineers loved working with them.

However -- the end result was that engineers got lazy. They were throwing code over to QA while barely testing code themselves. They were entirely reliant on manual QA, so every release bounced back and forth several times before release. Sometimes, we had feature branches being tested for months, creating HUGE merge conflicts.

Of course, management noticed this was inefficient, so they formed another team dedicated to automated QA. But their coverage was always tiny, and they didn't have resources to cover every release, so everyone wanted to continue using manual QA for CYA purposes.

When I started my own company, I hired some of my old engineering coworkers. I decided to not hire QA at all, which was controversial because we _loved_ our old QA team. However, the end result was that we were much faster.

1. It forced us to invest heavily on automation (parallelizing the bejesus out of everything, so it runs in <15min), making us much faster

2. Engineers had a _lot_ of motivation to test things well themselves because there was no CYA culture. They couldn't throw things over a wall and wash their hands of any accountability.

We also didn't have a lack of end-to-end tests, as the author alludes to. Almost all of our tests were functional / integration tests, that run on top of a docker-compose set up that simulated production pretty well. After all, are unit tests where you mock every data source helpful at all? We invested a lot of time in making realistic fixtures.

Sure, we released some small bugs. But we never had huge, show stopping bugs because engineers acted as owners, carefully testing the worst-case scenarios themselves.

The only downside was that we were slower to catch subtle, not-caught-by-Sentry bugs, so things like UX transition weirdness. But that was mostly okay.

Now, there is still a use case for manual QA -- it's a question of risk tolerance. However, most applications don't fit that category.

However, the downside of custom session managers is that other services might not be able to read/write the created session. For example, I'm currently to get off of Express and onto Fastify. Unfortunately, @fastify/session isn't perfectly compatible with express-session (although I'm working on it). I would have a similar issue if I introduced Next.js + Blitz... Sometimes, I wish there was a shared protocol for sessions between languages/libraries!

However, the downside of custom session managers is that other services might not be able to read/write the created session. For example, I'm currently to get off of Express and onto Fastify. Unfortunately, @fastify/session isn't perfectly compatible with express-session (although I'm working on it). I would have a similar issue if I introduced Next.js + Blitz... Sometimes, I wish there was a shared protocol for sessions between languages/libraries!

We had to balance between making the files too big (which would be slow) and making them too small (too many lambdas to start)

I _think_ they were around ~10 GB each, but I might be off by an order of magnitude.