Perhaps not bad, but different habits

In my last post I ruminated on some habits of mind I’ve developed over the years that are not serving me well in guitar building. In software engineering or other “symbolic” construction activities, we can undo our mistakes with a keystroke. Writing a paper is a bit like shaping bits of wet clay into a form; revising and editing is like shaping fine details. If we don’t like how something is coming out, we can scratch it out and re-do it.

In woodworking and other crafts, there is no undo button. Recovering and re-working a mistake can be quite time consuming. As I continue my guitar build, I pass several points of no return. If I take too much thickness off a side or plate, I have to start that piece over. If I bend a sharp kink into one of the sides, it’s unlikely I can un-bend it smoothly, and have to start from scratch on that piece. Once both the top and bottom are glued to the sides, there is no going back to tweak the interior bracing. The real hold-my-breath moment will come when I’m trying to fit a finished neck to a completed body – if I take too much material out of that joint while adjusting the angle, I’ll have to build an entire new neck.

Guitar making calls for a particular set of mental work habits. Critical among these is careful planning and execution of individual work phases. But that doesn’t make the way of the software engineer “bad” – rather, it’s an inappropriate set of habits for the job at hand.

Modern software engineering paradigms depend upon rapid iterations of design-implement-test cycles, with lots of throwing-out-and-redoing of code. See, for example, Agile Programming philosophy.

Professional software engineers have reflected on how programming lies somewhere on the span between art and engineering. In the arts, the creator is in constant communion with the medium, be it a canvas, manuscript, block of marble or code module. S/he works toward a goal, but there are always opportunities for the work to reflect back “hey, I’ve got a better idea!”  Good artists listen, appraise, and change direction in response to new revelations. Agile programmers follow a similar process with respect to both their discoveries along the way and the changing needs of their clients.

Woodworking can sit in varying spots of this spectrum as well, in some cases being more linear in process (think building a house), in others smack up against the arts end of the scale (starting with a chunk of firewood on a lathe, and ending up with a bowl). In the case of a guitar, there are strict constraints on certain design elements – the frets have to be spaced just so to produce well-tempered intonation (but see the fan fretted guitar for a clever innovation – retaining the relative fret spacing string-by-string but scaling each string to a different length). But there is also wiggle for late changes; on my current guitar, I’ve decided to alter the original plan for the neck-body joint. Rather than use the classical Spanish heel, I’m designing a bolt-on neck joint. Totally non-traditional in the classical guitar world, but this joint affords a lot of fine-tuning at a critical phase of construction (getting that angle right). For a relative novice luthier, having this flexibility is a gift – I don’t have to get everything “just right” several stages in advance, only to discover weeks or months later the critical mistake that has killed any chance of getting a playable instrument from the process.

The bottom line:  I’m not “bad” for needing to learn a different set of work habits when I close the laptop and put on the shop apron. These different habits of mind serve well under the appropriate circumstances.

Gluing a flexible lining along the top edge of the sides, to provide a better gluing surface for attaching the top.


Freedom, constraint, and design

Mike Darlow, in his book Woodturning Design, writes:

Perhaps a major reason for the popularity of bowl turning is the belief that you can produce a good bowl without having to do any formal design in advance. The wood is supposed to “speak” to you and thus empower you to free the wondrous bowl hidden within the unpromising blank – I may be deficient in the necessary spirituality, but wood doesn’t speak to me all that often or all that clearly.

Darlow is not exaggerating about the mythos of wood “speaking” to the turner. Many “artists statements” accompanying gallery turnings contain similar language – so-and-so follows the natural properties of the wood and is never sure what is going to emerge in advance. The remainder of Darlow’s book argues that 1) good design is critical to avoid a lot of wasted time (and wood), and 2) the only way to become expert enough to “listen” to wood is to have spent a lot of labor turning out well-designed turnings.

I start with Darlow’s quote because I turned out a very unsatisfying bowl earlier in the week. The sides were too steep, and took a sharp curve into a non-footed bottom.  The shape was, frankly, dumpy.  Too deep for its width, too.  Sadly, I used a really pretty block of rosewood and some uniformly black ebony in the construction – good material gone to a “learning opportunity.”

The shape that I turned out was not the one I intended to make.  I actually did lay out a design and thought I’d dimensioned the critical rings of the bowl blank to fit. It turns out (no pun intended) I made some technical errors in constructing the rings that limited the amount of material I had to work with. Once I knocked the corners off of the wood, I didn’t have a lot of extra thickness left with which to slope the sides. That, and I probably just wasn’t paying close enough attention overall.

So today I decided to start over, and rather than construct a segmented bowl, I’m starting the “old fashioned” way with a solid block of wood (well, actually 3 layers face-glued together – two thick slabs of rosewood topped by a 1/2 inch of curly maple for the rim).  Even for designs where segmentation isn’t used as a decorative feature, I’ve been trying to use a segmented (stacked concentric ring) design in order to save precious wood. The “traditional” method entails using a solid block (or just half a log, sometimes from a freshly fallen tree) and hollowing out the interior on the lathe (as opposed to “designing in” the hollow by building the rough bowl up from concentric rings). This generates an impressive volume of shavings, and when turning large bowls, there’s often enough wood in the interior to create a whole new smaller bowl, if it could be salvaged.

But at this point I’m tired of taking a week to cut and glue the rings (with several overnight drying steps in the middle). I’m going to start with a solid block.  This way I can shape the outer contour to exactly what I’m looking for, and then hollow out the middle to match. I’m not exactly going to let the wood “speak” to me (I know what shape I’m roughly after), but there is going to be some fine-tuning as I look at what I’ve wrought and tinker with the proportions.  It’s also true, as an artist/educator once told me, that one never approaches the canvas with a completely worked out idea of what the painting will be. The partially finished painting “talks back” to the painter, and through this dialog the artist discovers what s/he really meant to be putting down on canvas.

This experience has led me to think through these concepts of design, constraints, and freedom.  By starting with a single block of wood, I’m imposing minimal constraints: the overall diameter and height of the bowl. Wide rim, narrow rim, S-curve, concave, out-flowing… there are a gazillion design choices available with that block. When I sketch an outline and plan the rings of a segmented bowl, I’m pretty much freezing in place the profile I’ve sketched. This is fine, as long as 1) I’m sure the profile I sketched on paper will look good in 3 dimensions, and 2) I don’t make any technical mistakes that result in an altered profile.

Another way to think about this is to ask “when do critical choices get made?”  If I sketch up front and construct rings to match, all of my design choices are locked in before I’ve started to actually see the 3-d product.  If I start with a solid block of wood, I’m making a series of micro-decisions every time I shave a little more wood off the bowl.  Like sculpting marble, this is a “subtractive” process – we can’t add wood back on once we’ve shaved it off. In fact, if I’m puzzling over a particularly important cut, I can stop the lathe, stare at it, or even go take a break and come back.

The price I pay for leaving lots of options open is to waste extra material.  In a sense, I have the wood available to make an infinite variety of bowls, and with each cut, I cut away some of those possibilities until what’s left is my final product. This, then, seems to be the trade-off:  leave my options open, but possibly waste a lot of resources.  Or, plan for efficient use of material, but constrain my choices down the road.

Somehow I feel like this touches a life lesson.  I’ve seen similar issues come up in software design – when do you lock down design choices?  In the early 1990’s Apple and IBM combined forces to create a new operating system by co-founding the Taligent corporation. Taligent eventually folded without ever producing a product, and some of my friends at the time suggested a big part of the problem was that nobody was willing to constrain design decisions. All of the code was to be “object oriented” and fully extensible, to a fault. By leaving lots of room for flexibility in the design, they never actually produced anything (of course, that’s not the whole story, but a relevant part).

In my current work as an education researcher I often see a tension between pre-specifying research questions and a design on the one hand, and desiring fully open-ended exploration on the other. Sometimes when we lay out questions, instrumentation, and samples well in advance, we only discover mid-way through that we should have been asking a different question, or talking to a different population, and by then it’s too late to change course. On the other hand, were we to keep all of our options open, we could potentially waste a lot of money chasing down dead ends, talking to the wrong people, and ultimately never publishing any findings.

So – my thought for the week. Awareness of design choices, constraints, and trade-offs. I don’t have anything particularly insightful to say about this – just that I’ve experienced it in art, engineering, and research.  It’s feeling like one of those “universal truths” that needs to be condensed into a pithy nugget (which means somebody has probably already done so).

Virtual worlds and messy reality

My “hobby” life and professional life recently crossed paths in an interesting way. It started when the federal government announced a grant competition with one of the possible research topics involving robotics competitions.  (For those not familiar with how research is funded, this isn’t at whacky as it sounds. There are lots of programs in the federal government that hold annual competitions in a broad variety of areas. The specification of focal areas is how the government – and we the taxpayers – have some assurance that research conducted with federal dollars will be important and/or useful. As I recall, the robotics topic was part of a larger program that covers innovative uses of technology in education. Robotics competitions are gaining in popularity, and there is considerable interest in their impact on future science and technology interests of the flesh-and-blood participants).

During a meeting with colleagues we brainstormed some possibly interesting areas of research that would respond to the spirit of the grant. Two ideas in particular were notable for their contrast. One was (broadly) the question of what is gained from having a lot of practical, hands-on experience with mechanical systems. Real robots break and have problem with tolerances; builders need to respect the limits of materials, fasteners, and the laws of physics. Whereas in the 1950’s teenagers tinkered with cars after school, nowadays robots are the equivalent pastime for many students.

The second idea had to do with programming and simulation. Robotics also involves control and planning. In many competitions, the robots have to solve tasks or navigate obstacles without any human intervention. This can require considerable programming prowess to execute elegantly. One colleague (who was an advisor to his son’s team) said kids’ programming tends to be a batch of spaghetti code – long lists of instructions and contingencies sort of hacked together to get the job done.

A colleague pointed out that if we care about kids learning the control/automation side of robotics, then the “messiness” of the physical machines often gets in the way. It’s hard enough to devise an intelligent algorithm for navigating obstacles without also worrying what happens when a wheel inadvertently jams up.  One could imagine kids being overloaded with the frustration of learning to program AND having to deal with clunky hardware (these robots aren’t being designed by engineers with graduate degrees, remember). So he wondered whether a “virtual robotics competition” – where the robots were just simulated avatars a la Second Life – would be an interesting case to study.

On the flip side, others felt that learning about the “messiness” of physical systems, how to improvise solutions, plan for contingencies, etc., were equally valuable lessons, perhaps more important than learning elegant programming habits. Having gotten my start in software engineering, and now being very interested in “learning with the hands,” I could see both sides of this argument. Dealing with physical systems can be very frustrating at times; that was one of the appeals of the “virtual world” when I started in computer science. On the other hand, we live in a physical world, and I wonder what is lost when kids don’t get a lot of experience just interacting with the (non-mediated) world as they grow up.

My thinking is that if you want to teach programming, then teach programming, with or without robotic avatars. Just as we teach Newtonian physics in high school with an emphasis on theoretical models (mechanical systems operating in airless vacuums using weightless strings and pulleys, for example), one could imagine teaching the fundamentals of programming with reference to “ideal” robots or objects.

But to me, there is something special about tinkering with physical systems. I can’t put my finger on it exactly, but I feel like there are some valuable lessons in there, some of which are shared with the programming world (perseverance in the face of failure and frustration; the need for careful planning; problem decomposition, etc.), but others which are entirely separate from virtual spaces (namely, how gears work, what friction “feels like” on different surfaces, the strengths and limitations of motors, etc.)  Just writing these down, I feel a big “so what” question looming – do we really care that youth gain facility with building drive trains? It’s more than that – it’s a “feel” for mechanical systems. Again, I’m at a loss for words. Maybe I’m just being sentimental. But I know I’m not alone in this. Others have been writing at some length on the need to re-integrate the hands into educational experience (e.g., Doug Stowe’s Wisdom of the Hands blog), and some have designed engineering curricula appropriate for elementary school (e.g., Engineering is Elementary).

Actually, I can think of one lesson that differentiates the physical from the virtual – I’ve written about this in the past. The physical world does not have an “Undo” button. Mistakes have consequences. A piece of bad code can be erased and revised in the blink of an eye, but a badly assembled drive train can mean a week of wasted effort.

Slowing things down

I’ve been following Doug Stowe’s blog The Wisdom of the Hands, and in one of his recent postings he linked to this article Text-Addict kids Make More Mistakes.  The basic finding is that when given a timed experimental test, kids who more frequently used cell phones for texting tended to respond more quickly to test items, but also make more mistakes.

I want to dwell on this for a bit.  I remember hearing a talk – I believe it was Lani Guiniere – about gender differences on standardized tests (if it was Ms. Guiniere, the test in question was the LSAT).  Apparently there’s a research finding that suggests that males are more likely than females to make “fast decisions with uncertain information.”  In other words, women tended to deliberate over test questions, considering answers from multiple angles, whereas men tended to answer their best educated guess and move on. With a test limited by time, failure to answer all items could penalize one’s score. (And of course, Ms. Guinier asked who we would rather have making law – fast shoot-from-the-hip types or deliberative, careful thinkers).

My third example – this one is personal.  I came of age as a computer science major and software engineer more than a decade after punched cards were the standard storage media for mainframe computers. In the “old days,” as some of my professors loved to tell it, you had to write out your programs on a deck of punched cards, carry the deck to the operator in the machine room, and then wait hours (or overnight) for your job to run.  If you’d made a coding error, then oh well! you just lost a day.

With the advent of high-speed storage (floppy disks onward) and timesharing systems (followed by personal computers), a programmer could run a program, receive instantaneous feedback on errors, and make corrections immediately. What developed as a result was a “code first, think later” mentality akin to Ms Guinier’s observation of males speeding through tests, or the Australian researcher’s claims that frequent texting is associated with higher error rates. Why bother carefully planning one’s code if you could draft a program, run it, and just clean up the “errors” one by one in real time until you got it right? (By the way, I’ve heard similar laments on the impact of word processors on the writing process, when compared to long-hand or typewriters).

I can personally attest to the tendency to want to code first, think later, at least in the early stages. What serious students learn in university (and hopefully in their careers) is to slow down, design and plan their overall approach, and systematically craft and test modules. When the size of your program grows beyond a page or two, it’s increasingly inefficient to just “hack” the code until it works. But to this day I find that deadlines and job pressures encourage shortcuts in my coding, not thinking about the bigger picture (like, how will my colleagues be able to make heads or tails of what I’ve just done when I’m on vacation).

What Doug Stowe likes about woodworking (among many other things) is that the medium forces one to slow down and contemplate next moves. A “do-over” can cost days of time, akin to the botched punched cards handed to the machine room operator. We haven’t found a way to speed up the process of woodworking, particularly because there is no “undo” button to press.

Like Doug, I believe it is important for kids to have that “aha!” moment – frequently – captured by the slogan “haste makes waste.”  In fact, I would argue that events that require an immediate shoot-from-the-hip response are quite rare in our day-to-day lives. Almost any situation can bear an extra breath or two, a pause before speaking, a second measurement before cutting into that curly maple. I wonder what the world would look like if we all learned to slow things down a notch, to think that one extra beat before acting or speaking (or changing lanes on the highway, or sending that e-mail).