That last one is particularly good if you learn by seeing things in
action rather than reading about the technique.
(“That last one” being the “Craftsman”).
All interesting, and looks useful. The Craftsman one, though, struck
me as absurd. What I got out of that article was this:
(1) The programmer tasked with factoring numbers did not know how to
factor numbers. He did not realize this until he saw his code fail a
particular test case.
(2) He claims that he would have never been able to figure out how to
factor numbers without having seen that test case fail.
(3) Rather than go back and learn how to factor numbers, as he should
have, he instead progressively modifies his code to pass more and more
(4) He then goes on to happily assume that his final code is good,
because it passed several test cases.
That’s a recipe for danger, right there.
(1) “the programmer” was a junior level programmer, fresh out of college
and had not yet gained the wisdom of knowing what he didn’t know.
(2) He was paired with a senior programmer, who knew exactly what was
wrong with the code, but …
(3) Never explicitly told junior what was wrong, instead guided him to
understanding via a series of incremental tests.
(4) The senior programmer knew it was done because, (a) it passed the
tests, and (b) the tests were designed with the problem in mind. Each
test (for the most part) was carefully selected to advance to the code
to the next level of correctness.
(5) The story is less about factoring (which most of us know how to do
anyways) and more about the interaction of testing, coding and
Ehh, the story might not appeal to all, but I enjoyed it.