[w10-1]

So: good (chess) players spend more time mentally countering their proposed moves before moving.

For developers or managers on HN, one outcome would be that it's best to start one's career in testing, or to respect the resumes of those who started in QA. If/since there are hundreds of ways things can break, it's a harder problem to show how it will, or prove it won't; and building a mental library of fault models helps in vetting designs and implementations.

Or, we could teach fault models directly, instead of accumulating by experience. See e.g., Robert Binder, "Testing Object-oriented Systems" (and ignore the model-driven-development gloss from later editors).

But the most important note is the aside: the author avoids chess as addictive. Should we ask ourselves: how can this be? Should that change how I think about my own work?

[singleshot_]

I think the ideal first job in tech is IT help desk, not QA.

Everything that shows up to the help desk is broken. QA people need to have a skill for breaking things or at least an awareness of how things break. They will learn this at the help desk.

Otherwise: I completely agree.