Interview with Trevor Williams

TREVOR WILLIAMS (Support Technician, Office of Digital Media, Yale School of Architecture)

Trevor started working for the Yale School of Architecture as a contractor in August of 2011 and was officially hired by the university in October of that year. He holds a Bachelors of Science in Architecture with a Minor in Physics, as well as a Masters of Architecture from Illinois Institute of Technology (IIT). As a resident support technician, Trevor’s knowledge of “the back end”— from his graduate research on parametrics and his time spent developing code for the Rhino BIM project —easily surpasses that of the student and faculty body. In a time when most architectural work is done via digital means, what is the significance of this knowledge gap between practitioner and programmer?

There is a massive gulf between coding and modeling—I mean modeling in the broadest sense that you can think of: working with the concepts of space. But I don’t know if that gap really makes a difference. Ultimately, modeling is about adapting logic into form. Although it’s great to be able to do that with the deep level of understanding that code can bring—coding allows you to automate the process, so you tend to be able to fix problems very early on—if you understand the logical flow that you want your diagrams to make, it is still possible to do that brute-force. People who come into architecture school with a coding background, even a minimal one, are going to work within that toolset and return to it to test ideas. Those who do not come in with that knowledge rarely acquire it because the amount of work and time necessary to gain proficiency does not translate into a semester-long project.

_This fundamental time constraint_—the semester—offers Trevor and the DM office the opportunity to rebuild student workstations multiple times each year, but it also provides another set of difficulties for those who spend their working hours within the shell.

Every year there is a new disk image built from the floor up: We put the hardware for the next year in place, run a clean install of Windows, and start adding software packages. Every time we add a software or driver package we have to check to make sure something else didn’t break. It very often happens that one thing breaks other things. When that occurs we have fix each of things that broke. This involves tracking down specific libraries that might have been changed or moved, pieces of code that different pieces of software rely on, and registry entries that get tweaked by a piece of software and need to be adjusted or duplicated or figured out in one way, shape, or form. Then, if there’s time, and there rarely is, we will start trying to improve user experience. But the semester-based schedule is a double-edged sword. It’s great because it keeps things fresh and gives us the opportunity to go tabula rasa. At the same time, the school’s schedule forces us to work so fast that we can’t always do things correctly. Problems will get reported to us and tickets will have to close out because the semester has finished. The problem is no longer applicable, and because the problem is no longer applicable we no longer have to solve it. Problems often exist in the ether until they crop up a few years later.

Also in Trevor’s purview are the digital fabrication tools found in the Sub-Basement, but perhaps the era of mass customization that has been heralded by so many of our predecessors may be less accessible than anticipated.

A lot of the stuff in the shop, especially the heavy-end fabrication equipment, falls into the category of “dedicated operator machinery.” Users are expected to put in four or five hundred hours of training before they are considered proficient. We might give you forty minutes and a document written by someone with maybe double that experience. The biggest hurdle that we consistently hit is with the Kuka Robot Arm. Figuring out how to make the machine do something specific requires days worth of machine-time to understand and anticipate how the machine will react. On top of that, the software packages that drive these things are every bit as complicated as the devices themselves. The ones we have are actually some of the better options available, and they are awful. That’s the nature of the beast. There are what, 15,000 Kuka arms in the world? That’s a pretty small user base. You can make the experience of using it awful and it won’t matter. The people who need to fit that niche are going to do it. But the semester-based schedule does not allow for that to happen, unless someone wants to have class specifically devoted to trying to figure out how to use five-, six-, and seven-axis milling systems. And while that would be really cool in terms of professional, accredited development, it’s a pretty niche operation. The knowledge gained would qualify you to work at one lab at SCI-Arc. And while I do think that someone should be working at that lab at SCI-Arc, it doesn’t have to be an entire class’ worth of people.