Today I finished up The Mythical Man Month by Frederick Brooks, which is a surprisingly relevant collection of essays about software engineering, despite being written 42 years ago. Some of the essays I found quite boring, but those were usually essays that also detailed systems specific to the 70s. Most of the book tends to deal with the people of software engineering, and management tactics around the profession.
I won’t rehash them all here; however there is one section in No Silver Bullet - Refired that I found particularly compelling:
I have long enjoyed asking candidate programmers, ‘Where is next November?’ If the question is too cryptic, then, ‘tell me about your mental model of the calendar’. The really good programmers have strong spatial senses; they usually have geometric models of time; and they often understand the first question without elaboration. They have highly individualistic models.
My own mental model of a calendar is an infinitely long bookshelf of circles (or to make the metaphor more visual, metal rings). If you pull a ring off of the bookshelf you are looking at one specific year. The circular nature of the ring is based in the idea that each year always has the same months in a repeating pattern.
The length of the year in days is measured by the circumference of the ring. Leap years have slightly larger circumferences than normal years. One could imagine notches around the edge of the ring to help note month, and day, boundaries.
To visualize daylight savings time, I imagine a human with a saw first cutting the ring, and then welding it back together so that the ring is no longer smooth if you run your hand along it. A trait that is noticeable, and liable to cut you, but that doesn’t fundamentally change the ring structure.
It’s trivial to compare different years using this bookshelf of rings, one has to simply pull the appropriate rings off the shelf and put them side by side.
This ring metaphor can also be extended to any calendar system with a repeatable pattern, as it measures relative time instead of being mired in details like 365 days in a year, 24 hours in a day.
But there are also drawback to this mental model. For example, what if you wanted to compare decades? You would have to pull a bunch of rings down that aren’t physically attached to each other, juggling them and hoping they don’t get jumbled up (of course, as a programmer you could create a new module to grab units of ten for you). Or in the opposite case, what if you wanted to compare seconds? It would be very hard to get that level of detail, unless you exploded the ring into a very large size. Or perhaps more frightfully, what if you are trying to compare dates across calendar systems? If there is no point on this infinite row where time simply begins, how do you arrive at the same point in relative time described by two different calendar systems?
What I’m trying to say is that my mental model works for me as a representation of the entire time continuum as a whole, but runs into trouble at the implementation level detail for specific tasks. In a way, maybe that was the whole point of this question. Software engineering is entirely made up of the thoughts of mankind, and even with a coherent mental model, implementation details sneak through the cracks to bite you in the ass. All software engineers have run into this problem, and perhaps introspecting our own mental models of the world can help illustrate to others (particularly managers) the process by which software can run into snags.
Where is next November to you?