programming

Tools as a vector for expertise

Last year I bought an old wooden plane from a retiring woodworker at his shop sale. The man was curt. It was not a festive occasion, the mood in the shop pointed to his retiring probably more out of necessity than choice. A wide variety of tools was on offer, from borderline museum pieces to stuff probably bought at Harbor Freight within the year, but in all transactions the disposition of the man spoke clearly that you were lucky to have a chance at these tools, at any price.

So, without haggling I ended up with a few things: a level, a tenon marking gauge, a wooden-bodied plane. I mostly work with power tools, but there are plenty of situations, mostly involving big work pieces or weird angles, where a hand plane is useful. This one is a Stanley model 35, which means it could have been made any time between 1870 and 1940.

Screen Shot 2015-10-31 at 12.58.35 PM

Though it might look handlebar-moustachey, this isn’t a museum piece, or even an exceptionally good tool. It’s a decent tool, a money-maker, a thing in common use for decades, only recently turning into more of a fetish item for hobbyists who prefer muscle power to electricity on principle.

The sharpness of the blade makes or breaks the utility of a plane, and sharpening properly takes some practice. So I was greatly pleased when the blade of the old Stanley turned out to be sharpened recently and expertly. There are plenty of books, and even more web pages, on the right way to put edges on steel things. But even the best illustration lacks the descriptive power of the thing itself. From the angle of the metal, the portion of it that tapers down to an edge, the portion of that edge that is mirror-sharp, I can see what is important about sharpening and try to emulate what another craftsperson has done.

My IDE starts out with the same bits as yours, when we download them. But as we grow as programmers we customize our tools in ways that preserve our own solutions for getting things done. The preferences, scripts and template projects we carry around are records of how we dealt with complexity last time, that hopefully help make more things routine next time. What if our digital tools were designed to absorb and transmit our expertise in more and deeper ways? I want to see how great programmers sharpen their planes.

 

Live A/V at Kremwerk, June 4 2015

I played an audiovisual show last Thursday for the first time in around a year. Dusting off this line of work, I kept the materials I was using fairly minimal in order to have a better chance of making something coherent. Tried to keep my short attention span syndrome in check and make my playing more about listening than it maybe tends to be.

I spent most of my preparation this time writing a new visual toolset. I think part of why I don’t do more live visual work is out of frustration with the existing tools for it. Cycling ’74’s Jitter (now part of Max 7), which I helped write, is capable of doing just about anything with live graphics, and it’s what I’ve always used for shows. But sometimes its particular brand of flexibility can be a liability for me, creatively.

So the tools I’m using now are C++ and OpenGL. They are available on every platform, are wicked fast, and are open standards. If I want to switch to a Linux box for my next computer I can do that. Most importantly, I find it easier to read a big C++ program I wrote ten years ago than a big patch I wrote last year, and readability encourages me to reuse what I’ve built.

Thanks to Chaya, here are some camera phone videos from last week’s show at Kremwerk in Seattle. I opened up for the always-masterful Pole, who was touring with fellow Berliner MFO on visuals.