I saw the keynote speech David Heinemeier Hansson gave at this year’s Railsconf in Portland and I liked it a lot. I really like the idea of following the pattern of “Less software is more” to the work we do each day. In his speech he says developers should spend one day a week discovering a subject of interest, writing code for a pet project, contributing to an open source project, etc. Basically anything but doing the work they do on the other four days of the week. This “day-off” raises the developer’s productivity so it is a net gain for the main work he is involved with, too.

I tend to agree. However, in this post I want to elaborate rather what ‘be more’ means in both the ‘less software is more’ and the ‘less work is more’ phrases. Less software means less lines of code to achieve the same tasks. Less work means less time spent working producing code to achieve the same tasks. There are two underlying concepts here that make this possible: abstraction and productivity. More precisely: the ideas in your (hacker) head and the tools that allow you to implement these ideas in abstract, high-level terms and thus raise your productivity.

When you write a program, there are basically two phases of producing code that solves a problem: first, you think about how to solve it and second, you convert the ideas into code. There is always a gap between the ideas and the code you write and that the computer comprehends. The more high-level the language is, the smaller the gap that needs to be bridged. But there is a backward effect, too. Usually when you are in the first phase you already think in terms of the second. The expressive tools the language provides have a strong effect on how you think of the problem (generally you know what language your solution will be implemented in). And that is bad because it dumbs down your thinking before you get to the point where you should consider the possibilities of the language.

I tend to think less of the language specifics in the first phase if I know the language provides all the high-level tools and provides them neatly. “For” loops skews your thinking more than -all kinds of- iterators. If I know functions are first-class objects and metaprogramming is available I worry less about how (or whether!) my abstract solution, only existing on the plane of ideas can be converted to functioning code.

So, back to where I started, your choice of the language counts and it counts a lot. It can help you be more productive in several ways, not just the fewer-lines-of-code-to-do-the-same-thing way but also the minimizing-the-skewing-of-your-thinking way. However, a high-level language is no guarantee to achieve that. One can churn out C-like code in Ruby, it is just easier to realize you are not using the full arsenal. And that’s where it really kicks in: if you know you can basically do anything painlessly you will dare to think big, your ideas can get off the ground. Consequently they will be abstract enough for you to be more productive.

So armed with daringly abstract ideas and tools that make it possible to put them into code, one sets out to conquer the world. The limit to the amount of code generated is the number of hours one can spend each day programming. After about ~8 hours of work is it worth to put in some more time to produce more code? Probably not. Our thinking breaks down pretty fast after that. I have experienced on several occasions that I could do in 10 minutes the next morning what I could not do in 2 hours the evening before. This is not about dropping the keyboard when the clock strikes 5pm, of course. It is about planning for measurable progress without too much overtime.

I think David is right when asserting that replenishing your mind so it can come up with constructive ideas is equally important. I am sure there are numerous ways to attain that. Some of them are constructive activities in themselves (David’s example was playing the banjo), some may just give you peace (e.g friends, family) and some may simply drift your thoughts away from the very problem you are working on (e.g playing soccer) and help you that way.

So what do you think about all that? Can low-level languages still have advantages over high-level ones in certain situations? Do you think the language your are programming in can have an effect on your problem-solving thoughts? What activities switch you off in the most “productive” way? What other factors have an effect on your work? (of course your working environment is very relevant). Are naps worth it? When would the official Railsconf’08 videos be online? :)