After a happy series of acquisitions and mergers, Norbauer has been retooling from being primarily a large international web application consultancy to a smaller, more focused team working on a suite of productivity apps (to be announced late 2013) for retail sale. As I've been working on that process, working both on cross-platform/in-browser and Windows desktop apps, it has been helpful for me to reflect upon the engineering and aesthetic values that led me to software in the first place. I've thus been thinking back a lot to an interview I did in 2008 with software/design theorist Amy Hoy. As much for my own benefit as anything else, I'm reproducting that discussion below.

AH: How would you describe yourself in, oh, 15 words or less?

Let’s see. How about: "I seek beauty, and elegance out of complexity—which are pretty much the same thing."

Admittedly, it sounds a little pompous, but it’s not far from the truth.

AH: How did you first get into programming?

In 5th and 6th grades, I was put in a weird, experimental “gifted” classroom with 15 other kids from around the county (largely I think because my teachers were exasperated and didn’t know what else to do with me.) The curriculum consisted of nothing more than setting a bunch of nerds loose all day to daydream and follow their own pursuits.

This is where I met and fell in love with a certain Apple IIe. And thus I spent two entire years of my formal education teaching myself to program Star Trek adventure games in Apple BASIC.

Needless to say, my transition back to normal public school wasn’t pretty.

AH: How did you continue programming as you got older?

As a dabbler, mostly.

In high school and one summer in college, I interned at a NASA software facility where they worked on code for the space shuttle, so I came to know the surreal and ugly world of huge-scale software development early on. I primarily worked on re-writing their inscrutable procedure documents for clarity, and I created a few web apps in ASP for internal use.

Oh, and I also made a lot of software for my college thesis research in psychology with Visual Basic.

AH: And how did you get into Ruby specifically?

It all started during my second year of grad school as a social science researcher on a PhD track. I was growing disillusioned with academia. I was beginning to realize how hard it is to get tenure doing the sort work I wanted to do—work that could have a real impact on the world beyond the Ivied Walls. The academic system is, bewilderingly, structured so as to encourage irrelevance and obscurity.

So I dropped out of grad school and taught myself PHP to pursue a business idea I had been toying with for a couple years—a capitalist, rather than academic, approach to addressing a social problem.

That business became Lovetastic, which was my first experiment in building a business and playing seriously with web applications.

Shortly thereafter, I attended 37signals’ Getting Real workshop—back before there was a book of the same name. Even though the workshop didn’t specifically advocate any particular technology, a lot of what Jason and David said that day (along with the beautiful code the latter presented in his slides) pointed me in the direction of Rails.

I went straight back to the hotel and read everything I could find on Rails (which I had been interested in for several month months) and I decided that same day to rebuild Lovetastic from scratch in Rails. In a few months, it went from 20k lines of PHP spaghetti code to 2k lines of well-organized, elegant Ruby code that was a pleasure to deal with.

Since then, Ruby has become a huge part of my life. I run a Ruby/Rails consulting firm with teams in New Delhi and New England, and we all get to work together on some amazing projects for some very smart and thoughtful clients. It’s amazing how one’s choice of technology can act as a filter for the kind of clients you’d want to work with.

AH: Why was Ruby and Rails such an instant draw for you?

As Lovetastic went live and grew in complexity, I found myself experiencing a terrible sense of creeping dread every time I contemplated feature improvements or additions, because I knew that any one change was likely to break five other things.

PHP made it too easy to be a bad programmer, making it a lousy tool to put in the hands of a lazy and slightly daft guy like myself. I don’t just need an angel on my shoulder; I need a dominatrix. And that’s precisely what Ruby (via Rails) is for me. Quite simply, Ruby and Rails taught me how to be a good programmer. It encourages me to seek elegance in the way I express the core logic of my application, and to abstract away complexity and repetition as soon as they show up.

AH: You also are someone with a passionate interest in design and design philosophy. How did that come about?

Ha. Yes, well, my favorite terms of self-derision are “effete aesthete” and “pathetic peripatetic.”

The thing is: I’ve always been drawn to what you might call “big questions,” for some reason or another. The reason I chose psychology as a major in college, for example, was because I viewed that discipline as a way to study the big transcendent questions of philosophy (conciousness, motivation, etc.) using the tools of science.

Equally, my love of design has always been about big questions: the power of images, colors, and lines to convey profound ideas using really elegant visual cues.

I think this all started with Mrs Morgan in sophomore English class. On the first day of class, she read to us Keats’s “Ode on a Grecian Urn:”

Beauty is truth, truth beauty,—that is all
Ye know on earth, and all ye need to know.

She then proceeded to lead us on a year-long tour through words and paintings, with a particular emphasis on Romantic period poetry and painting, along with modernist architecture. She loved art and design and saw them as inseparable from the study of language, which I suppose is what English class is technically supposed to be about. At that impressionable age, she helped me appreciate the grander implications of studying visual aesthetics, something which remains with me to this day.

She was the first teacher to make me realize that the careful study of old poems and paintings isn’t just a rote exercise to prepare for the AP English exam or an “Art Appreciation” quiz, but rather that those activities are really just about the study of ideas. They’re about distilling the whole of our universe and human experience into simple, beautiful concepts that anybody can discuss and understand.

Science at its best does the same thing, and in a somewhat more limited way, so does good programming.

AH: What do you mean by that?

Simplification, unification, and reduction: these are the values of a great craftsperson, whether she’s a tradesperson in the guild of ideas, words, paintings, or software. Shakespeare’s Hamlet, the theory of evolution by natural selection, and Ruby on Rails: each of these is in some way a form of digesting something that seems huge and intimidatingly incomprehensible (death, creation, and the crafting of involved web applications, respectively) into a set of basic, approachable concepts.

AH: Do you ever think to yourself, “Hey. I did the psychology education. I’m a programmer. I run a social web community. I manage a programming team. I write and design stuff. Maybe I should add another field to that list?” [sarcasm alert]

I have to resist the temptation every day.

I guess the reason I’m such a dilettante is that I refuse to make distinctions between disciplinary boundaries. Everything to me is about the underlying ideas. When I find ideas I like, I follow them wherever they lead me.

The ideas involved in everyday design can say things as varied as “this object is rooted in an awareness of history,” “the happiness of the user of this object is worth caring about,” “nature and humanity are one and the same.” But they’re all interesting to me. Attributes like “clean lines,” “lots of whitespace,” or “flat vector illustration,” are important and interesting to discuss, but what’s really at stake is what those things say—the ideas the designer is trying to communicate to his user.

AH: How would you say your background has affected your experience of software development?

Rather unsurprisingly, it has meant that I’m drawn to aesthetic questions. This obviously applies to the way the code itself is written, but there is also beauty to be found the broader concepts of good programming—in particular, searching for ways to abstract away the crushing complexity of these wily networked computing devices we sit in front of all day.

David Hansson was one of the first people I ever heard use the words “beauty” and “happiness” in reference to software development. This totally changed the way I thought about programming. Or, more precisely, it liberated me to be honest about what I felt all along: the programming is, when at its best, an exercise in artistry and craftsmanship (and therefore something I can give a damn about.) Programming should be about making things that seem complicated easy to handle.

In this way, programmers are really lucky. Unlike biologists or mechanical engineers, who have to deal with the world on its own terms, programmers deal in a world that is entirely of their own making. We have the luxury of being able to re-work and re-invent our world to make it easier to understand. Physicists don’t have the option of re-writing the laws of relativity in order to make the cosmos easier to understand for everyone, but programmers do have an analogous power. If something like the exchange of data over the web, or the modeling of database records as programmatic objects is too complex, we have the power to invent a new world that makes everything easier to get our head around. Rails, of course, does precisely this.

AH: If you had a magic history wand, what’s one thing you’d change about the technology industry?

I would eliminate the insecurity that makes so many folks in the industry feel the need to come off as “plausible.” The fact that we’re craftspeople gets lost in all the meaningless bullshit stupid-speak that everyone spews like a nervous tick to prove how “serious” and professional they are.

Eighteenth century furniture makers (among the best craftspeople human civilization has known) didn’t feel a need to talk about their rattan synergy verticals or the going-forward scalability of their organic people-ready growth competencies in wood assemblage. Their embellishments may have been inspired by a certain movement in design or a set of ideas (as Shaker furniture makers were), but primarily craftsmen of the past were just worried about how to make beautiful objects that suited their purpose elegantly: tools for the tasks of everyday life.

Technology is just tool-making. If this process comes off as “complicated” or “sophisticated,” we shouldn’t congratulate ourselves on how smart we are to be able to work with all this complexity, we should be ashamed of our failure. Tool-making is an elemental, ancient pursuit—one which many anthropologists argue is the most ancient and distinguishing pursuit of our species (even more so than language.) It’s about making life easier, for our users, yes, but also for ourselves. We too easily forget that. Programming should be the art of the easy.