Beautiful Code and Beautiful SoftwareMonday, October 29, 2007Programming was fun because I could make cool stuff, but what actually got me obsessed about it was suddenly seeing something interesting in the semantics
and syntactics of the very lines of code. Being sensitive to the difference between good and bad code was intensely motivating, and discovering ways to write
efficient, self-documenting, and thoughtfully-organized code was something I knew could captivate me forever. This is what I loved (and still love) about my
field—the art of programming, the wonderfully complex craft that could take a lifetime to master.
As I added to my Ruby knowledge Java and then Objective-C, I began appreciating software development at a lower level. I grew up in an environment (the Rails
community) where there was a lot of hate for those big verbose languages, but upon actually experiencing them for the first time myself, I discovered that I
enjoyed them. They were different, but still interesting in differing ways. And hey, there was something satisfying and clarifying about writing dumb code
after being born in high-level land—my first for-loop in Java, for example, helped me better appreciate the cleaner, object-oriented practices I knew, but I
also saw something appealing in the for-loop itself. It wasn't just elegant language that intrigued me, it was also the basic logic behind the syntax, and
the fact of differing syntax. Computer language, and differences in computer languages, were fascinating in and of themselves.
I had the same satisfying feeling when I first learned Assembly in college this term. Assembly was tedious and sometimes quite painful, but the way it made
me think about basic programatic functions in such new ways was completely worth the pain. Of course, I also got a geeky pleasure just from being aware of
the low-levelness of the code I was writing.
It gets worse! I had a great moment of self-discovery when I read Wolf's Programmers Don't Like to Code early this year. I indeed love the problem solving,
elegance-creating, coding-to-learn part of coding, but I realized that I actually like coding for coding's sake, too. At least, that's how I describe my
enjoyment of CSS and XHTML. I have an extensive enough grasp of front-end programming that I don't often solve a new problem these days (in fact, problems
that take me a while or bugs I haven't seen before can be downright thrilling). Yet, I still enjoy working with the stuff. There's something relaxing about
dumping out good-looking code that I understand very well, sort of like how I enjoy doodling the same cartoon cat over and over in my class notes, or how I
enjoy playing the same three tunes when I sit at a piano. Even just looking at good CSS—well ok, my CSS, with everything ordered, indented, and cascading
correctly—feels good in the same way that I felt bad, almost physically ill, as I waded around in the stylesheets of a certain forum software and found
inconsistent indentation, extra line breaks, commented-out junk styles, and styles disabled by deliberately misspelling the property name.
This is what happens when you're so easily inspired, interesting shadows on the walls motivate you to continue living. You have to come back in once in a
while and reorganize your levels of sensitivity so that your appreciation for light and sound is appropriately proportional to your appreciation for Off-Off
-Broadway.
That is to say, these days I've been thinking a lot about the software part of software development. Specifically, the design of user interfaces in software.
At BARcamp this year, I liked how Aza Raskin asked all developers to raise their hands, then all designers, later saying that the hands that went up the
first time should have stayed up. All developers should be designers. At least, that's true for all developers lucky enough to work jobs where they have a
say in the design of their software.
I'm getting increasingly excited about the importance of design within development, especially as I come to terms with my different passions and reflect over
some of my past gigs. In the web app contracting world, design and development are usually separate jobs. In some cases, the design job is minimized in
comparison to the rest of the project because clients generally pay for features, not for beautifully thoughtful design. On a project where I played both
design and development roles, I recall feeling uncomfortable because I was assigned only two days to complete the visual design. It needed a lot more than
two days. It was a complicated application that deserved weeks of rigorous iteration and conversations with the client. Unfortunately, that's not what the
client was paying us for. The client was perfectly fine with the version-one mockup that took me a couple hours, and well, we had an app to launch.
I had another wake up call while I was at C4 this year. It appears that many Mac developers, perhaps most of them, are solo indies producing their own
products. As such, they really do have to be both designers and developers. Actually, design is often the most significant part, and there seems to be a lot
more enthusiasm over user experience and just producing a great product than there is over the code itself. One night during C4, someone inadvertently helped
me see this when he described to me the nature of his work: "Coding the basic functionality is the easy part. That just take a couple weeks. What's really
hard and time consuming is figuring out the specifics of the UI."
Wow, I thought. Why does that seem so right? Why is that so cool to me?! Oh, right, I'm a designer to begin with. There are dramatic rifts between my
enjoyment of development, design, and art because I appreciate each of them in very different ways. I constantly try to integrate development and art, but I
really ought to figure out how to mix all three.
After all, my goodness! Do we want beautiful code, or beautiful software? Here's another peek into my life: A side effect of being extremely open minded and
absorbent is that I find myself believing all kinds of contradictory ideas, sometimes even opposite ones. It doesn't bother me right now because I'm in
exploratory mode, not know-what-I-believe mode, but to retain sanity it is, of course, a must to occasionally sort things through until they make some kind
of sense.
Thus, for further consideration I've listed just a fraction of the many things people like about software development, loosely ordered from the most
intrinsic rewards to the most extrinsic rewards. I've left out a lot of really wonderful stuff like community, open source values, and challenges because
those are harder to fit into this order, but I think you'll get the point. This is an extremely interesting sort order to me because of how psychologists say
that intrinsic motivations are stronger and more likely to keep you going. For example, the person who takes karate classes because she feels energized and
excited by the sensation of punching and kicking will more likely end up with a black belt than the person who takes the same classes for the health
benefits.
Is it the same for programming?
The sensation of writing codeThe knowledge that one is writing codeEnjoying computer logicEnjoying computer languageElegant syntaxElegant semanticsLearning about codeProblem solvingLearning about problemsAchieving usabilityFinishing a productElegant softwareSolving human problemsSolving business problemsSatisfying market needsMaking moneyHaving a stable careerWhich is the most persistently motivating kind of reward? Most importantly, which kind of motivation produces the best software? I'd love to do some formal
research on this topic sometime, but I'm already pretty sure that the answer is "a healthy balance of most of the items on this list," as we certainly want
our software to be both usable and maintainable, and sellable, and everything else. I'm also pretty sure that the balance is different for every situation
and person. At the moment, however, I envision a wide bell-shaped curve sitting upon a rectangle, and everything turned on its side—the motivations that
result in the best software are the ones nearer to the middle of the curve; but really, I think all of the motivations are beneficial in some way, and
insofar as the programmer has her priorities straight, the more the better.
The tragedy of our field is that most programmers don't ever get to appreciate the majority of these rewards, particularly the more profound ones. Then
again, it works out great because the majority of programming jobs couldn't possibly satisfy someone who cared about all these things. Still, I wonder what
the industry would be like if we were all intrinsically, thoroughly passionate about our craft, and nobody was signing up for Computer Science classes just
for the "stable career." I wonder what it would do to the world.
I think I should revisit this train of thought every year or so as I become a better software developer. I get the feeling, though, that my fate is already
somewhat set in the fact that the more I grow, the more I desire a working situation where I have enough freedom to create beautiful things. It's probably
worth noting that both freedom and beauty are vague, subjective ideas, so that could mean anything. All I know is that the compromises to both beauty in code
and beauty in software design as necessitated in most programming jobs give me an unwavering feeling of discontent. I wouldn't be surprised if I ended up
settling down as a freewheeling solo developer using, you know, web design contracting to support my freewheeling solo lifestyle.
Eventually I'll retire my computers and spend the rest of my days plein air painting on some beautiful farm out in the country. That, or a sensuous city life
of alternating between street art missions and serving time. It's fun to imagine where I'll go once I feel done with technology. Hopefully that never
happens, because I want to be the cool guru grandma who's still around when her children are giving mandatory programming lessons to their children.
