Software development is a temporal activity: it takes place over time.
Any temporal activity can be shown as a series of snapshots. This is a way of "speeding them up", usually for the purposes of analysis or instruction. It’s a kind of "as if" thing. For some kinds of thinking, we can just elide, ignore, or lightly annotate the face that the activity takes time to happen.
There’s nothing inherently sinful about these "as if" visions, but sometimes, when their conclusions are ramified into prescription, especially rule-centric process, they can produce unexpectedly unpleasant results. The whole snapshotting conversation is really about the framerate we choose in which to talk about our way of making software.
How often do I take a snapshot of "my way" to make it valuable to onlookers? And the answer depends almost entirely on who those onlookers are and what they want to do with the resulting sequence of images.
The most common answers in development pedagogy seem to be 1) just show the final result and explain it. 2) one second = one second, and, the most common 3) snapshot once an interesting change has occurred.
At different times, i’ve used all these methods as consumer and producer both. I generally prefer the third when i’m learning something brand new, and the first when i’m out there looking for "how I implemented X?" type answers. I want to hone in on the third, because I think it’s most useful for the largest part of the trade. If we double the population of working geeks every five years, that means that any given time half of the trade is composed of — no offense — noobs.
What noobs — often including me, depending on domain — seem to benefit the most from is sequential frames where each frame has an "interesting" change from the frame before it.
Didja ever do something dumb that got your mom mad at you? And she said, "oh, child, what were you thinking!?!?" as a noob forging my way into a new domain, that is the question I most often want to get the answers to. "what were you thinking?" geekery is the sociotechnical act of integrating high levels of creativity with high levels of rigorous technique.
A rewrite: geekery is the sociotechnical act of integrating high levels of creativity with high levels of rigorous technique over susbtantial periods of time to make artifacts that please.(I added that rewrite cuz it mentions or implies all the muddinesses present in this very muse.)
If we are to learn, do, analyze, teach, or give advice about geekery, we have to incorporate all of this into our vision.we have to address the artifacts, the pleasing, the creativity, the technique, the sociotechnicality, the humanity, and temporal flow of the enterprise. Honestly, nothing else will do.
Perhaps my biggest whine — this is not a rant today — about these branded prescriptive processes I encounter every day everywhere all the time: it is the extent to which they seem so often to leave out one of these key aspects.
What I am after is a description of software development that is formulated to include all of it.i don’t know that I have such a thing inside me, or that any of the geeks I love and respect have it in them, either.
At the end of the nineteenth century, david hilbert produced a famous list of "problems we must solve" in mathematics. I guess I believe the most pressing problem we must solve, as an industry, a trade, a discipline, a way of being and living and working, is just this:
How can those of us who are successful at this express what we do to those of us who are less successful at it?