In the context of writing a new service for a new company, you should not spend one second thinking about whether your technical choices will allow you to serve 100,000 requests per second, or 150,000 requests per second. If you are, you are focusing on the wrong thing. If you get to 1,000 requests per second with a real paying client base you already achieved more than most dream of.

On the other hand, if you are optimizing a mature distributed low-latency equity trading system that is consuming ten's of thousands of market data ticks per second, a 50% improvement in performance on a 20 machine cluster might turn into some real $$$ savings. But that's not what this article is about.

What about drafting communications with an attorney? Is a draft email that has not yet been sent protected? What about a Word doc containing a draft of an email? What about a Google search for “how do I spell amfeetamine?” that is part of your process of drafting your communication with your lawyer?

I'm also a convert.

There is one conclusion that I do not agree with. Near the end, the author lists cases where you will outgrow flat files. He then says that "None of these constraints apply to a lot of applications."

One of the constraints is "Multiple processes need to write at the same time." It turns out many early stage products need crons and message queues that execute on a separate worker. These multiple processes often need to write at the same time. You could finagle it so that the main server is the only one writing, but you'd introduce architectural complexity.

So while from the pure scale perspective I agree with the author, if you take a wider perspective, it's best to go with a database. And sqlite is a very sane choice.

If you need scale, cache the most often accessed data in memory and you have the best of both worlds.

My winning combo is sqlite + in-memory cache.

We're in an interesting spot here and the tension is tangible.

Right now, my wife and I are sticking to annual photo albums. They're already fun to flip through and we're not even that old yet.

Seems that you never worked with Accenture consultants?

My point is that some people find this stuff valuable. You're not the target audience.

It’s much better than writing bitter diatribes.

I am recruiting in Poland, they say that they're Polish, have very Polish names, but they are clearly not Polish and not in Poland.

It's easy enough to spot their resume's if you know what you're looking for. If you're interested, I can share, but email me (email is in my HN profile).

If you don't know enough to pick good starting points you probably won't know enough to optimize well. So don't optimize prematurely.

If you are experienced enough to pick good starting points, still don't optimize prematurely.

If you see a bad starting point picked by someone else, by all means, point it out if it will be problematic now or in the foreseeable future, because that's a bug.

I'm dealing with this all the time in recruitment. It can be done. People lie all the time or don't read the requirements. You need a way for the ones who really do know how to do the thing you need to demonstrate it to you.

Have you ever been in a situation where you had to hire someone to help you with something? Would you really follow your own advice? Your advice does not make sense for carpenters, cooks, or drivers. Why should it make sense for programmers?

If I want to hire a driver, I can train someone who does not know how to drive, or hire someone who has experience as a driver. I can do either, but I'd prefer to do the latter in most cases.