Making Software

Concluding Remarks

Readers of this book should have an affinity to the reflective practitioner view [Jarvis 1999], [Argyris and Schön 1996], where practitioners reflect on what they do in their daily work and develop better ways of performing work tasks. To get hold of the usually implicit understandings of practitioners should be a main focus of disciplines such as ours. I must mention that our HR manager from earlier also stated that her company didn’t really want their programmers to spend time reflecting too much upon what they did. Rather, they should just implement what they were told to implement. I’m sure most of us, together with Joel Spolsky, would not find this view particularly appealing, but it is all too easy to revert to such strategies in pressed lead-time situations, i.e., getting trapped in the urgent/important quadrant at the expense of the important/not urgent planning and development quadrant [Covey et al. 1999].

With our insights, however, we can lay a logical trap for our already time-trapped HR manager: her previous remark on IQ entailed that (1) GMA predicts programming performance, but (2) since GMA predicts learning ability first and foremost, this must mean that she wants programmers who are fast at learning, and (3) learning is done through reflective practice, but (4) once she has her programmers, she doesn’t want them to reflect, hence she doesn’t want them to learn. I’ll call this the unreflective time-trapped HR manager’s paradox.

In fact, our HR manager ...