Duplo Programming

Five years ago, I just stepped out from university and immediately transitioned into my first job. It was a time when I’m brimming with youth and confidence to a point close to being boastful (and I wasn’t arrogant at that time). It’s a time full of dreams and unfounded ambition, which I would gladly tell friends that one day I’m going to write a great application which people would use. Even better, I’ll write a framework or a content management system that people could reuse and implement.

Five years later, my accomplishments: nothing. Zip, nada, zero. Talk about not being able to live up to my own expectations.

Despite programmer’s tendency to be optimistic and believes that all problems could be solved using a computer, there are lots of problems that are inherently hard made hard by myself as I optimistically believe that I’d the capability to come up with a generalized solution that could solve all sorts of permutation of problems. Of course, as you could tell, if you can’t really narrow down the boundary of a problem, it almost spelled instant doom. It’s quite easy to get infected with analysis paralysis when you have a problem with an infinite plane.

Nowadays, well… I now rather do lazy programming: thanks to the Internet and all the open-source tools and framework available.Recently I have been relying on existing cool stuff like CakePHP, Bluetrip and jQuery to whip something up as soon as I could. It’s especially important to know what problem I wanted to solve: and most problems tends to be far less technically-inclined most people believe to be so.

This reminds me of a talk by Paul Graham:

Bottom-up programming suggests another way to partition the company: have the smart people work as toolmakers. If your company makes software to do x, have one group that builds tools for writing software of that type, and another that uses these tools to write the applications. This way you might be able to get smart people to write 99% of your code, but still keep them almost as insulated from users as they would be in a traditional research department. The toolmakers would have users, but they’d only be the company’s own developers.

If Microsoft used this approach, their software wouldn’t be so full of security holes, because the less smart people writing the actual applications wouldn’t be doing low-level stuff like allocating memory. Instead of writing Word directly in C, they’d be plugging together big Lego blocks of Word-language. (Duplo, I believe, is the technical term.)

I may not be a super hacker who could hack a completely new framework or CMS in a week, but I’m certainly able to know what tools to use to solve problems and getting things done. After all, the technical challenges are only one part of the problem space that has been solved.