« Do it with D3 - Lazy Loading Images | Main | Gottalove Gattaca! »

Quora answer on Programming advice for novices

It’s that time of year when I can sit down to write letters and other waffly things. I have wanted to follow up on this question ever since my friend Josh Levy posted an excellent answer many moons ago. Here’s my chance to chime in with an orthogonal perspective.

A popular anonymous quote best captures what I’m about to say, and be warned - it’s going to look counter-intuitive at first: “Please excuse the length of this letter. I do not have the time to be brief.”

After many years of soaking in the field, first as a hobbyist in my teens, then as a formal student of CS, as a practitioner coding for hours on end in various languages, as a faculty member teaching the science and the art, as a hiring manager of many top-notch programmers with whom I am proud to be associated, and most importantly as a nerd unafraid to code at every available opportunity, I have come to realize the subtle truth in the following dictum. I now try to impart it to aspiring newbies any time I’m able to:

“Strive to code many hours, but few lines.”

A long time ago, I was chatting with Franz Och when the number of lines we had each coded came up in our conversation. I was, of course, surprised that Franz would be even marginally interested in such a quantity - but it made perfect sense. He may have been interested not in how many lines we’d each written, but how few. After all, he prides himself (or once did) in having written the smallest ever Maximum Entropy Toolkit (YASMET).

In contrast, I often encounter programmers who pride themselves on the number of lines of code they have written (Yes, it’s true - even today!) But sheer volume does not necessarily imply good quality. While volume can be a measure of one’s dedication to the art, the true measure of excellence comes from their ability to distill output to say as much as possible in as few words (tokens :-) as possible. Many aspiring programmers can be quick to jump into coding, often writing inefficient and verbose code where a terser equivalent would have been better.

It is a cliche now, but it's worth repeating that programming is an art, and the closest art form I would associate with it is poetry. It therefore behooves programmers to delight in not just the message (solution to the problem), but also the expression of it (how they solve it). One should savor the discovery of new and succinct ways of saying things, relish the clever idioms of others, derive joy from emulating them, and continuously publish new patterns and idioms of one’s own to see which of them others like. Just as the poet is constantly hunting for that succinct phrase which unleashes an ocean of emotion, or as Blake put it, to hold infinity in the palm of his hand and eternity in an hour, the good programmer is also constantly looking for the most elegant and concise statement of solutions to difficult algorithmic problems.

Although I’d like the cool dictum to be something like a grand truth, I concede that it has serious problems in practice. In the worst case the desire to produce the most condensed solution could potentially end up becoming an intractable search. Some excellent programmers I know believe that mediocrity is worse than ignorance, and therefore often suffer a mental block in coming up with any solution that they think is less than brilliant. When they do solve a problem it is awesome. But often they are simply stuck - Better to not solve the problem at all and be thought ignorant, than to solve it inefficiently and be branded mediocre. It’s easy to see why this attitude could be a serious liability in today’s agile environment.

The other issue of course, is that the ideal state is unattainable except via a passage through the less-than-ideal. It is the the same problem as one facing an aspiring writer. The only way to write good prose or poetry is to keep writing. It will get better with experience (10,000 hours according to the sources quoted by Peter Norvig in Teach Yourself Programming in Ten Years). So the only way to write good programs is to keep coding, oodles and oodles of it. But perhaps I could say this instead - Keep coding, but like the artist who’s never happy with his art and keeps tinkering with it to make it perfect, constantly keep re-examining your own code, comparing it to the best that’s out there. Lock it up in your bottom drawer if you must, and continue searching for ways to make it better, more succinct, more elegant and more efficient. One day you’ll have a gem you may be proud to wear on your head.


PS. I admit that a directive to code as tersely as possible could be misleading. For example, a naive recursive implementation of a function to print the nth Fibonacci number is as succinct and elegant as possible on the face of it. But it hides an ugly exponentially large stack and run-time beneath its veil. In comparison, its dynamic programming equivalent is a few lines longer, but its run-time characteristic is far more elegant. The experienced programmer would learn to optimize not just for surface beauty, but also for the “inner beauty” of programs. Like the seasoned poet who excels at the best choices of both the words and the sentiment they portray, she would have developed an intuition for the trade-offs that give optimal pleasure.



TrackBack URL for this entry:

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


This page contains a single entry from the blog posted on December 31, 2012 5:23 PM.

The previous post in this blog was Do it with D3 - Lazy Loading Images.

The next post in this blog is Gottalove Gattaca!.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.35