[dalke]

That's a rather small "except", as I wrote "My own practice is to have good, automated tests, but these don't get put into place until the cost/benefit ratio makes the tests worthwhile; which is rarely at the start of the code development and always by the end." The difference between you and me is "some tests first" vs. "rarely do tests come first."

The useful skill I think should be practiced more often is of breaking code. Take a code base and find out where it doesn't scale, where it core dumps, where it sits in an infinite loop, or where it lets you write read and write arbitrary files to the file system.

It's pretty fun, but it's a mindset contrary to that of most programmers, who are optimistic and goal oriented, rather than pessimistic and defensive like me.

In my essay I'll ask for pointers to public projects developed in full red-green-refactor style.

Cheers.