As part of my ‘training’ for my new (first) job, I was instructed to pick up and read the book Hackers and Painters by Paul Graham. It seemed like quite the novel idea; after all, people who program computers are supposed to be scientists. It’s a science to most because that’s the definition of science: something that can be repeated ad nauseam with the same result. But it’s deeper than that to those inside the business, and that’s what Graham focuses on.

Anyone can write something that uses a finite language to perform a task; they view programming as a science because the result is all-important. A subset of these people care about the means to that end, how to innovate and control or to clarify and enhance something that predates their intervention. It is these select programmers that see what they do differently from science; as Graham’s analogy goes, they are as painters.

It was a novel idea, one I hadn’t personally thought of. Coming out of the 80′s and taking computer classes in the 90′s, I learned that the old, original way to program was pencil-and-paper; you traced, retraced, and did it again until you were sure that all the pieces compiled and didn’t hang on an infinite-loop. Ka-chunk-ing the graphite into punch cards or translating the pseudo into real code seemed like a science; the very implementation of the scientific method.

Enter the 2000′s. As a Comp Sci student, there are classes everyone dreads. Algorithms are typically one of them. Learning the Complexities of Djikstra and A* meant sleepless nights reviewing code, compiling, and reading the textbook. Sounds like a science to me! But, at the end of it all, the reason so much pain was endured is quite clear: it makes us resilient, faster, and better “painters.” We see the loops, callbacks, and hash trees as strokes on the canvas or rhymes in a song; storing references instead of whole objects slides the slant rhyme into a perfect-pitch. I thought differently, even began speaking a different language in my head: a programeese that was based more in logic and absolutes than society’s compassionate relative truths.

Then again, this brings up its own interesting tangent. Maybe software engineers are closer to being writers than painters, but no one has written about the connection because the thought of mixing science and creativity was a noxious concoction. William Strunk wrote Elements of Style in 1918. He didn’t have a clue what Boolean logic or a vacuum tube was. But he did understand writing; and words were his symphony. He must have, I believe, painstakingly sat through the English Composition equivalent of our programming algorithms class. His grasp of what makes a good essay translates with only a little help into great programming practice.

An excerpt with noted emphasis:

Make the paragraph [function] the unit of composition: one paragraph [function] to each topic [task].

[…]Ordinarily, however, a subject [task] requires subdivision into topics [functions], each of which should be made the subject [task] of a paragraph [function]. The object of treating each topic [task] in a paragraph [function] by itself is, of course, to aid the reader [programmer]. The beginning [declaration] of each paragraph [function] is a signal to him [or her --Ed.] that a new step in the development of the subject [task] has been reached.[…]

~ Bartleby

That’s remarkably coherent for what was changed! And if you hadn’t thought about it before, beautiful code follows this advisory very closely. The function is the fundamental unit if any program, (if you bar the variable since they are in themselves stoic). Its purpose should be solid and rudimentary if internally complicated. But just as my 5th-grade teacher taught me when outlining my papers, that complication should not become so extensive that the intent is lost; in that scenario, the paragraph should be subdivided, and likewise the offending function should be dissected. The contexts are different, but the underlying principles are the same: K.I.S.S. — Keep It Simple, Stupid!

So, after all, maybe programmers are men and women of double duty; scientists who engineer excellent structures that do exactly as told, and yet makers who craft works that are intuitive and engaging to use. I guess that “programeese” I constructed my world around once I appreciated what I had learned was more than sounding crazy. It was learning how to fasten a dangling participle or paint a Douglas fir Bob Ross would be proud to put in the background of one of his paintings.

Buy The Elements of Style
Buy Hackers and Painters

Can we reference an algorithmically-named set of variables in one variable to make our PHP code as future proof as possible? Yes we can!

Welcome to Advent Technorati, the code-oriented portion of Advent Euphoria, my LiveJournal, (LJ), weblog; a blog stuffed with ideas, anecdotes, and insights from my aspect as a newfound professional software engineer.

© 2011 Advent Digerati Suffusion theme by Sayontan Sinha