I enjoyed this talk by Justin Searls who highlights what should be an obvious subject (for anyone who programs). There is a gap between knowing the semantics of a programming environment and being able to program with it to create something useful. Justin sheds some interesting light on this fundamental subject.
Though I still live in my intimate bubble with software at my fingertips, I am no longer actively involved in any “communal” making of software. When I do program it is because I want to do something and I have no one else who can program for me. Programming is an edgy experience for me. On one hand I appreciate the potential power of programming. On the other hand I don’t like doing it … and this talk touches on a lot of what I don’t like about it. (It is also another indicator to me that Ruby on Rails is … interesting).
How to Program from Test Double on Vimeo.
I am fresh off a year-long, focused programming effort. During this time I explored, within my own private bubble, applying some of Christopher Alexander’s ideas about unfolding wholeness in the context of creating software. At the heart of Alexander’s view is that to achieve wholeness we need to create wholeness at every step of the way. Nature does not create separate parts which are then assembled into wholes. Am embryo in a womb is always whole, it is never in a temporary state where parts need to come together (fingers are not created and then attached to form a hand).
I found places to apply and express wholeness on many levels … from code constructs (a single line of code, a function, a class) through to underlying processes and overall design. At every point I aspired to have something whole, sensible and working (even if not necessarily “producing tangible results”). It made me wish I’d known of these ideas when I was involved in software professionaly. I would want to explore these ideas in more depth and in the context of collaborative work.
For me, there is a subtle fault line in Justin’s talk. I sensed it when he qualified some of his choices as “personal preference”, evoking a sense of openness and pluralism instead of asserting “rightness” or “wholeness”. Alexander offers a parallel from his world of architecture using an example of a door. If we say a door is 3 feet wide, 8 feet tall, made of wood, painted green with brass hinges … these “facts” will not be disputed. But if I say that moving the door 3 inches to the left will give the room more life, that will be written off as opinion and just a matter of taste. Alexander’s work is an attempt to show that this is an error. That there is an empirical (thought not necessarily quantifiable) truth there, as true as the “more factual” attributes. If we are to get better at making rooms (or writing code) we need to learn to see and recognize this “wholeness” so that we can get better at creating it.
I feel that unfolding wholeness can be a meta-process that can embrace Justin’s observations and give them a deeper and more profound home.