No, it just means someone has encountered that particular problem in the past.

The 10X immediately knows the answer. The 100X immediately knows the answer, but asks "That is an interesting observation and I'd really like to know why too. But is writing 1 million characters to the console essential to the problem your solving?"

Indeed.

Then the 1000x engineer explains:

"You are confused because you do not understand Tao. Only a fool expects rational behavior from his fellow humans. Why do you expect it from a machine that humans have constructed? Computers simulate determinism; only Tao is perfect.

The rules of programming are transitory; only Tao is eternal. Therefore, you must contemplate Tao before you receive Enlightenment."

"But how will I know when I have received Enlightenment?" asks the 100x engineer.

"Your program will run correctly," replies the 1000x engineer.

Meanwhile, the 10kx engineer sits here on HN, doing nothing while requirements change again and again - waiting to implement the thing when the requirements finally settle.

It's really an example that we should teach people to use a sampling profiler. anyone can answer this question in a minute or so, no speculation necessary, if they just know what tool to use.

Except the insight of the answer is that the bottleneck is in a different program than suspected. Running the suspect program under a profiler wouldn't yield any answers.

Sure, anyone can find the answer if they already know where to look.

Running the suspect program would show blocked states; even without that, you would simply see no difference, conclude that the problem must lie elsewhere, and switch to looking at a full system profile.

FWIW, I always start with a full system profile including all thread states when debugging mysterious performance issues, precisely because "the problem is in another process" is such a common occurrence. This is also why it's important to use a sampling profiler specifically.