[sigill]

The article makes a number of good points. The first three points in the "Learning" section resonated very well with me.

Then there's stuff I just don't understand. For example:

> Multiple scales. Move between scales freely. Maybe this is a design problem, not a testing problem. Maybe it is a people problem, not a technology problem [cheating, this is always true].

What does he mean by scales?

[epaga]

Great programmers often take a step back and ask themselves whether the problem they are encountering is only a symptom of a far larger problem, e.g. "maybe this entire component needs to be refactored instead of just tweaking these tests." or "maybe when customer asks for X what he actually wants is Y"

[richdougherty]

He might be suggesting that you can consciously consider the problem different at levels of detail. You can step back and look at the problem in its wider context ("the big picture") and you can also zoom in and focus on aspects of the problem in more detail.

[sigill]

Thank you. I was thinking of scale as a measure of order of magnitude and then it didn't make sense.