I’m not a person that quotes a lot, but one quote I keep using is “Laziness is a programmer’s main virtue” of Larry Wall, the creator of Perl. Why is being lazy important as a programmer? Because it makes you be creative in minimizing the amount of work you have to do. That means that lazy programmers will choose and create tools that let them write as little code as possible.
Smart lazy programmers will even try to make those tools and frameworks they created to reduce the amount of repetive work, as generic as possible. This way they can use the same tool for different purposes and if they’re thoughtful, they might even release the tools and frameworks to the public.
People often ask me what I want to do after I finished my studies at university. I never really knew exactly. Months ago it would be any kind of software development. But as I largely lost the joy of programming, it became harder. A couple of months ago we did a project that I really enjoyed. It involved designing and implementing a framework that companies would use to offer services dependent on the user’s current location. This framework was to be used with mobile devices on wireless connections, meaning that it had to be fault tolerant and had to run on both PCs and Pocket PCs. We used .NET to develop this framework. I was one of the architects but also implemented some of it. Why I did like this? Because I could bring up the laziness in me. I had to ask myself questions like: How can I make using this framework as easy as possible? How can we make simple things easy, without making hard things impossible? What parts can we implement for our frameworks users and which ones do they absolutely have to implement themselves? What will the API look like? What will be class and method names be? How can we make it the most like APIs the user already knows? How can we let the most lazy guy do as much with 10 lines of code as possible?
After we finished the rough architecture I started working on the framework usage document. In this document I described how you would go about using the framework. By writing the document I quickly found out where the troubles were and what we had to work on. When a first implementation of the framework was done we handed the binaries to our subcontractors together with the framework usage document. It’s the ultimate test to see if the framework indeed is as easy to use and learn as we thought it’d be.
I realized that this was what I like doing: creating tools and frameworks to reduce the amount of work other developers have to do. Long-time readers of my blog might have already noticed it. Many posts are about programming languages and platforms and advantages and disadvantages they have. This is what I’m passionate about: being lazy, err, tools that make developers more productive. I like playing with them, promoting them and creating them. It’s what I want to do. Not only tools, but also development paradigms and everything that improves the development experience, getting rid of the boring stuff and reducing it to the essentials.
That’s why I like languages like Python and C#. That’s why I like IDEs like Eclipse and Visual Studio. That’s why I like paradigms like object oriented programming and code generation. That’s why I like application frameworks like ASP.NET and Ruby On Rails (which I’ll be looking into soon).
When I get my master(s), we’ll see where I can work on stuff like that. Having programmers only working one hour per day, yet doing the same amount of work they did in a day before, that’s my goal.