Usually, when I describe my development skills, I do so with “self-taught” included in there somewhere. After all, the way I learned to code was not through any official workshops or courses. Rather, I used language references, tutorials, Q and A forums, and the like to work through bugs or being unsure how to accomplish something with my code. I realize that this self-taught approach to development is not, by any means, unique (how often do we hear of the Silicon Valley mogul without any college education, let alone one in computer science), but carving out a career in interactive media without any formal training instilled a consistent sense of inferiority in me.
Specifically, I just felt slow. Slower than my colleagues were. Slower than that for which my clients would have the patience. Slower than I should have been. This was not, of course, to keep me from continuing on as a developer—the satisfaction of solving a problem with the tools at my disposal was too good to pass up, even if it meant putting in extra hours or not charging for every minute. And whether it was a QBASIC script in 1997 or an iPhone app in 2011, I was determined to figure out how to write it—and do so on my own.
Design, on the other hand, has never been something I’ve been able to tackle without specific instruction and close guidance—be it a book, magazine, interface, or otherwise. To reflect on my inability to feel comfortable with my pacing, color choice, or type hierarchy construction is probably another essay altogether, but knowing that designing my final thesis in book form was a requirement for my degree at DMI hung over me from day one.
Fortunately, I had a strong crew of advisors and colleagues who were willing to walk me through this process. After determining that I was really writing two volumes—one focused on my investigation of theory, the other on my exploration of practice—I produced draft after draft of my books, gleaning feedback from those around me and working to make it better. I realized I might be frustrated by the final result, but at least I would put the time in. As long as I had a strong idea behind why I wanted it to look the way it would look, then I could feel proud about that.
So I spent time considering form. My thesis contemplates our technological trajectory, questioning the influences on the choices we make today. Making sure this trajectory was evident in the physical book became important. Concurrently, giving my readers the ability to take the text-heavy theory-focused book on the road (dictating that it be printed in a pocketable size), while still providing large-format documentation of my practice, became a priority. After a few rounds of brainstorming, my advisors and I settled on a custom-bound case, complete with plexiglass template to hold the small book up against the larger one. This provided both the combined theory-practice volume I hoped for, as well as a beautiful juxtaposition of plastic and paper—two materials with strong presences along our technological trajectory.
Recognizing my own weaknesses, I decided it would be printed and bound elsewhere. I was proud of this willingness to let go of a piece of the process; as anyone who has written a masters thesis can attest, after the years of laser-like focus on your content, handing that document over to someone else to produce is a harrowing proposition. But now, all I had to do was get a quote for the printing and binding, write a check, and deliver the files. Then I could turn my attention to my thesis defense presentation and preparing for a transition out of the student life (I had been ignoring my freelance work for a quite a bit at this point).
And then I received the quote.
I’m not really sure what I had been expecting. As someone who works with print shops on a regular basis, I knew full well the expenses related to printing a book—that a custom bound double volume would push the limits of my budget should have come as no surprise. But there I was at a crossroads: I could sacrifice my vision for the book, I could sacrifice my wallet (let’s not forget about all that freelance work I hadn’t been finishing), or I could take on what I had considered to be an absolute last resort and build the book myself.
“Sacrifice your wallet!” you offer. “You’ll never have another chance to print this book again.”
Or maybe you’re more the pragmatic type: “Sacrifice your vision. Bells and whistles aren’t necessary—it’s about the content!”
Of course, it wasn’t until I had glued the eighth book cloth on when it occurred to me that I had expected a different experience from this. I stopped, looked up, surveyed the scene: piles of paper, bottles of glue, Xacto knives, brushes, markers, and scraps of book-board. This was not a familiar setting. This was a mess.
Oh, how I missed the ability to open up a tutorial and just copy some code from another program into this latest project. The book binding-overview I received from my advisor was thorough, but still just that—an overview. But now I was in deep. Where, I wondered, were my control statements—those lovely little snippets of code used in programming to automate repetitive tasks or logic problems? And could someone please tell me where my sacred undo button had gone? All of this glue and marker and double-sided tape and cutting of various materials were terribly permanent.
Worst of all, however, was the time. Oh, the time. I was getting down to the wire—my final presentation (something for which I had yet to prepare at all) was only a few days away, my parents’ arrival from Florida was imminent, and have I mentioned the freelance clients? Sure, I knew this was going to be labor intensive. But when one is sitting in one’s dining room at 2am, wiping glue on one’s pants, staring at the stack of cardboard yet to be wrapped with cloth, knowing that this would be hard work provided little solace.
And then I thought about my code again. After years of practice, I’m still not comfortable calling myself anything but self-taught. And I struggle sharing my code with colleagues or employers. But I’ve become more confident in my ability. Because the users of my programs never see the hours of time spent at my computer struggling through a bug that is a result of a small typo on one line of hundreds. And they never consider how many iterations it takes to perfect a specific feature. They appreciate my code because it works.
But now I have an appreciation of my own: for the importance of craft—the craft of making, certainly, but the craft of learning. As it turns out, you can’t take twenty years of programming—no matter how industrious those years were—and turn it into one week of book-making experience. You have to remember the time and the attention that you put into former and apply that to the latter.
As I made my books, whenever a plastic template would be cut incorrectly or a straight edge would seem off-kilter, I would designate that particular book as a gift for a friend of mine who I knew wouldn’t mind. Surveying the 20 custom-crafted double-volumes in front of me now, I can’t seem to figure out which one is the most imperfect. C’est la vie et la reliure, the French may say. That is life and book binding.
At the Dynamic Media Institute, we believe in design as research. We believe in the act of making as learning. I learned a lot during those many hours making those books (and I would be remiss not to mention that my wife probably did, as well, as she put in just as much work as I did; I don’t know if she garnered the same appreciation for the craft, however). I learned that, self-taught or not, well crafted work requires time—time to glue, time to debug, time to reflect—but most of all, time to learn.