Welcome to my new website! Building it was quite difficult…and kind of fun.

I am an architect and writer, not a website builder. I have plenty of work to do without fiddling around with web design. But like any business, I needed a web presence, and I figured I could save some money, learn some new skills, and do it myself. I came to that conclusion in 2009.

In the intervening eight years (!), I cycled through several approaches to building websites, committing multiple false starts and wasting a shocking quantity of time trapped in vortexes of misunderstanding and confusion. But I persisted, for better or worse, and in the process discovered something about myself as an architect. (And, thankfully, I now have a website.)

image of code My first attempt at designing my website was with a short-lived Adobe program called GoLive, a predecessor of PageMill, which itself was a predecessor of Dreamweaver (the only one you might have heard of). Nothing came of this effort, but about a year later, at the recommendation of a friend, I successfully built a site using a free tool called Indexhibit.

Indexhibit was designed for artists to catalog and exhibit their work (thus the mashup of “index” and “exhibit” in its name), and it has a winsome artworld hipness that, I must confess, made me feel pretty cool. You install it on your server, upload images and text, and you’re up and running with a simple gallery-style website: a header, a bio, and a series of multi-image galleries.

I found that building a more complex site, however, was a challenge. Indexhibit is terrific, for what it is—a structure for showing a series of single images. If you happen to be a painter or photographer, you’re all set (like my friend Sabrina). But for anyone else—anyone who might want, say, a layout with more than one image—Indexhibit is limiting. To customize it requires hacking, and while there is a vibrant forum on just this subject—and some people have achieved pretty impressive results—I struggled. I did my best and, after days of fiddling and forum reading, managed to make a presentable, if limited, website.

Around this time, I started an architecture project that would overwhelm my practice for years and make business development impossible (and unnecessary, thankfully). As time went by, my lonely, clunky website became more and more out-of-date, and I grew mortified to think that someone might discover it. I kept it as secret as I could, and I was relieved when my big project slowed down and I could pay attention to web design again.

This time, I turned to a more famous website builder: Wordpress. Wordpress started as a blogging platform, and like Indexhibit, if you use Wordpress for its designed purpose—blogging—and you aren’t too too particular about its appearance, it works perfectly well. However, if you want to customize it significantly, things get challenging.

Wordpress is enormously popular, and it has spawned a cottage industry of “theme” builders—programmers, some who work for Wordpress, but thousands who work for themselves—who make stylish-ish website designs that can be wrapped around Wordpress’s core blogging engine and make it work for other purposes, like a site for a small business. It’s as if the hacking has been done for you already, and there are (literally, possibly) a million themes to choose from.

So, I started shopping. And I shopped. And I shopped some more. I finally found a very classy, minimal, modern design called Stockholm and started trying to adapt it to my needs. But as with Indexhibit, hacking it required a great deal of work. Seemingly small things like placing an image in a specific location or centering text in the browser window were titanically difficult for me. Often the changes required digging into the “page source”—the indecipherable register of computer code that tells a browser how to display content. It turns out that Wordpress and its themes have particularly dense, copious code—scrolls and scrolls of letters and numbers interrupted by occasional strings of English that catch your eye like a familiar face on a crowded street.

image of code The code intrigued me. I wanted to understand it, to decipher it, to know what it does and how it does it. In the summer of 1997, I lived with my mother in Las Vegas for a few months before starting graduate school in architecture. I had never worked in an architecture firm—I had never even taken a class in architecture—so I thought it might make sense to get a job at a local firm, and I called around. I ended up being hired to design a website for an older firm that knew it needed a web presence but wasn’t yet convinced the web had much of a future (as evidenced by the fact that it hired a guy with no programming experience to design its website, and it gave him six weeks to do so). I bought a book on HTML and built four clunky pages with pixelated images.

I struggled, of course, but not just because I was an amateur trying to do something that requires experience and skill. I struggled because I was used to print design, in which you can organize images and text in any way you like. HTML was never intended for that purpose. It was intended to link text and images over a network, and that’s about all. It included a few more sophisticated capabilities—tables, for instance, which were useful to the scientists and mathematicians that created the web—but otherwise, it was pretty spare. Graphic design was, at best, an afterthought.

What resulted, as the internet caught on in the mid-90s, was a field—web design—oddly defined by its limitations. HTML, the lingua franca, was simple enough: <h1> for headlines, <h2> for subtitles, <table> for tables, and so on. The basics could be learned in an hour. But fluency depended on understanding what HTML was incapable of, what it couldn’t do, because inevitably, if the goal was good graphic design, one would want to do it. The only way to learn HTML’s limitations was experience, and that was only possible for students (who have time) and professionals (who are paid). And innovating with HTML…well, that was for computer scientists.

image of code It’s amazing to me that twenty years later, after all the advances in web technology, the basic limitations of web design are still intact. You still can’t place text and images wherever you want, the way you can in, say, InDesign, Adobe’s program for laying out print publications. Granted, the possibilities in web design are far, far greater than they once were—and the learning curve correspondingly steeper—but the basic structure is the same: skilled designers must understand the quirky limits of the technology as much as its tantalizing possibilities.

In 2015, as I was struggling to get Wordpress in a headlock and make it behave, my friend Kyle caused me to change course again. “You need a static web site,” he said. “Come over for lunch, and I’ll build one for you.”

Kyle is an entrepreneurship professor with a Ph.D. in chemical engineering from MIT. His brain is fast-twitch, and he’s cheerful and energetic and generous. But the thought that someone would build my website in a couple hours after all the years I had spent fiddling around was shaming, and I couldn’t take him up on his offer.

But I did google “static website,” and I discovered the world of Github, Ruby, Jekyll, Sass, Bourbon, and Neat, among many others. Now this was the real McCoy. Not the fluffy “build your own website” world of Wordpress, Wix, Squarespace, or GoDaddy, but the virtual office where real programmers write code and pull all-nighters, complete with the legendary “Command Line”—the badass old-school black screen with chunky letters, a la War Games. I understood little of what I saw, but I was tantalized by the nerdy seriousness of it all. I struggled through austere files called “Documentation,” where terms of art go undefined and a basic level of expertise is presumed. I loved it. And despite the high-altitude discourse, there’s a spirit of openness and collaboration that makes you want to catch up and join in: people write code, valuable code, and share it freely. And some even help the newbies.

In the end, I learned that I needed to go back to the basics and build up my skills from there. I took a few months and learned HTML and CSS (the language for styling a web page), and I started to write my own web pages from scratch, without the help of a website builder. At first, I ran into the same old layout problems, and I tried out the latest hacks: “floats” and “flexbox,” a pair of complicated workarounds that allow you to layout “responsive” pages—that is, pages that change layout depending on the viewer’s screen size, a whole new challenge. But then I discovered the miracle of CSS Grids, a new feature that makes laying out a web page logical and reliable, even for amateurs. Unfortunately, as of this writing, they’re not supported by all browsers, but that’s changing fast. (At least, it better be!)

image of code The interesting question to me in all this is why did I decide to build my own website in the first place? And why did I persist when it became clear that it would be so time-consuming? Sure, I haven’t often been in a position to hire a designer, but I’ve certainly spent an expensive quantity of time on the project over the years. No, I think the reason is something more fundamental. It stems from my personality. It stems from being an architect.

I came to architecture late. I was nearly thirty, and I had been working in the book business—bookselling and publishing. I was at an age where many of my tastes and perspectives were well-formed. I was interested in buildings and cities, but as an amateur and a part-time flaneur, not as a proper student or professional.

When I got to graduate school, I found, of course, that many of my classmates had studied architecture as undergraduates, and I learned quickly that this made them different from me in meaningful ways. Whereas I was formed by the diffuse world of the humanities, they were formed by architecture, a field defined by fixed methods and requirements. They were doers and drawers, and they had a sense of how to start a project and what the final product might be. I had none of this. I was an observer by nature, not a person of action. I liked discovering and learning and discussing, and it was hard for me to put pen to paper and create something. I felt like an outsider, and very often I felt naggingly inadequate. But I also sensed that I had a chance to see things in ways that some of my classmates couldn’t or weren’t interested in: the structures beneath the surfaces—the reasons for things.

I chose Yale because it took a broad view of architecture and how it can be produced. Architecture is not only buildings, I discovered, but something bigger and more abstract: a highly complex aggregation of inputs and influences, a manifestation of culture, economics, history, and the environment. Understanding this not only makes you see architecture with more sophistication, it empowers you to think expansively and find new ways to design. Take a window, for instance. What is it, exactly? It’s many things. It’s technology: it allows a wall to be opened, to be seen through or reflected in. It is a tool for mediating privacy. It is a means of escape. It is a compositional element. It is a collection of materials, organized in very precise ways. It is wood, metal, glass, and plastic, products of industrial processes that emerge from physics, chemistry, engineering, and environmental science. Learning architecture from this perspective made the possibilities seem limitless, which was exciting. But the burden on the student—and by implication, the architect the student would become—was profound.

Paired with this was an emphasis on making—on using tools and working with materials. We built a house together, learning how to cut, hammer, and measure (to a point). We were trained to use the wood shop, and we used it to make models and mockups. Most importantly, we were encouraged to be inventive with the ways we represented our ideas. Architecture was seen as an art that could draw upon all the others, and whatever was needed to represent an idea best was fair game. Often the representation itself—rather than the quality of the design being represented—was the point of a project and the main subject of discussion with critics. In addition to traditional architectural media like plans and sections, students used installations, photography, figure drawing, illustration, and digital media to communicate their ideas. And it was those who did this most inventively that received the greatest praise.

image of code After graduation, I embarked on the comparatively less heady process of interning in architecture offices and preparing to become a licensed architect. Despite a fairly high opinion of my background (something that I am sure was irritating to my colleagues), I discovered quickly that I was not very well prepared to do the work of practicing architecture: making construction documents, answering phones, and thinking about things like shop drawings and the proverbial bathroom partitions. Nor was I very useful to the offices that employed me. When things got tight, it was often me who was let go first.

I eventually made my way to a firm that made architecture the way I had been trained—from scratch. They built their own buildings and fabricated their own furniture. They developed details that were based on a sophisticated understanding of materials and construction methods, empowering their builders to make a building rather than assemble it from mass-produced products, as so many buildings are. Can’t find a window in a catalog to fit your purpose? Then design one, and have the builders make it.

It was intimidating, at first, because I wasn’t sure I had the skill to do such work. But to my surprise, it was oddly easy, because it was so natural and elemental. We solved problems very directly: by studying them, researching options, and creating solutions. The detailing and engineering could be challenging, of course, but conceptually, it was simple and refreshing. The solutions we developed became a part of the architecture: they were visible in it. We weren’t trying to conform to a preexisting style, although the buildings did have stylistic consistency. The style grew from the materials and details very naturally, and as such, it projected authenticity. Perhaps best of all, we controlled everything.

image of code Which brings me back to why I insisted on building my own website, even though I had no experience in web design, I am not a graphic designer, and I certainly didn’t have the spare time.

Like just about everyone, I spend most of my professional life working on a computer and fiddling with my phone. I am lucky to leave my desk and visit construction sites from time to time, but in truth, the computer is my partner, my colleague, and my coworker, and engaging with it forms the majority of my experience.

So much of what we do on a computer—in fact, everything we do on a computer, unless we are programmers—is mediated by a veil of operating systems and applications: from iOS and Windows to Photoshop and AutoCAD. All of these programs, while necessary for productivity, are proxies for the code that hides behind them. And it is here—in the code—where the real action takes place. While it’s not practical to start fiddling with, say, Excel’s code (and why would you want to?), web design is a field in which you can peek under the hood of your computer and learn how things work. You can even direct how things work.

From my first awkward attempts to design a website nearly two decades ago, this accessibility, this DIY spirit, has appealed to me in a very immediate way. Seeing behind the curtain and learning to have greater control over the digital tools that have infiltrated every part of our life is empowering. It invests our work with more meaning by bringing us closer to the place where it actually occurs: where the hammer strikes the steel. It’s akin to making your own window. Instead of accepting something made by others, in which hundreds, even thousands, of choices have already been made, you start from scratch and make the choices yourself. This is the basis of an authentic connection to one’s work, and making something authentic and meaningful is what motivates me—as an architect, a writer, and an semi-pro web designer.

image of code Once I started becoming more fluent in HTML and CSS, I began to value the quality of the code I produced, not just its instrumentality. I had sensed immediately, even though I didn’t understand it at the time, that the code in the Wordpress themes I worked with was bloated and messy. This is understandable—Wordpress and its themes try to satisfy a vast audience of users they can’t know in advance, and so they must use the programming equivalent of a shotgun, or bomb, to hit a thousand targets at once.

There is a countervailing movement in programming—one I learned of when I discovered the command-line culture of Github—to encourage “elegant code”: code that is direct, clever, clear, and modest. The idea is to make it accessible and legible so that it is easily sharable and improvable. It’s an effort to improve the vocabulary, grammar, and syntax of programming, but I respond to its crisp, clean aesthetic. Elegant code is actually visually elegant. And better yet, it is intellectually elegant. It represents a noble commitment to invisible quality—an attempt to dive below the thin surface of appearances and make things good at their heart, where it matters, even if few people can appreciate it.

I am sure my website falls far short of this standard, and I am positive that a good graphic designer and programmer could improve it substantially. But I like that I know what’s inside the box, and I like that I know how to add to it and change it. In some ways, it’s nothing more than a good first draft, one that I would feel good about turning over to someone with talent and skill to make better. I like to think they would understand what I was trying to achieve and, more importantly, what I care about—and not just because of all the words and pictures, but because of the way it was built. Because of the code.