SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Good Programmer = Lazy & Dumb?

Alternative title for programmers using C-derivatives and Java:

Good Programmer == Lazy & Dumb?

I read this blog post, Why Good Programmers Are Lazy and Dumb, and it struck me a being an excellent perspective.  Especially with these 2 quotes:

Lazy, because only lazy programmers will want to write the kind of tools that might replace them in the end.

My goal when working on a project it produce a product that takes me out of the loop on the project.  By that I mean that I want to provide the end users all the tools they need to manage the application once released to them.  No, I don’t want to have to manage in-application security, I want a tool provided to the appropriate person to do that.  I want to be a DBA\Developer, NOT an application administrator.  I want to be able to work on new and exciting projects, not stick with one.

But there’s a more crucial point why a good programmer must be dumb. That’s because for him to find the best solutions to problems, he must keep a fresh mindset and manage to think out of the box (or rather, know its actual shape).

Sometimes, the worst situation is the one where you are re-writing an existing application.  Why?  Because you, or someone else on the team, knows too much about it and can’t see new ways to do it.  A few years ago I moved to a new position and was put on a project with one of the existing developers who had been in the organization for several years and had written much of the current application.  Let’s just say this was a blessing and a curse.  They knew the processes well and what hadn’t worked well, but this also meant that they weren’t able to see other ways to do things which may be better.  I was the “dumb” programmer in this situation and tended to ask, “Why?” a lot and suggest alternate ways of doing things.

So the questions are:

  1. Are you trying to write software that replaces you?  Are you automating the routine tasks of being a DBA so that, with proper documentation, someone can come behind you and not miss a beat?

    I know I have a long way to go in regards to automation and documentation, but I’m working on it.

  2. Are you content with, “I’ve always done it that way”, or are you looking for new or better ways to do things?

    I’d like to think that this an area I do well in.  I’m always looking for a better way to do something, which is why I attend user group meetings, read books and blogs, and participate in the online SQL Community.

How about you?


Posted by Steve Jones on 8 December 2009

It's an interesting question. I typically write code to make things work better and save time, but not necessarily because I'm lazy. I've written lots of monitoring and automatic help code because it's tedious work, I'll forget things, and I can do more productive things with my time.

However I've also been lazy, not wanting to spend 2-3 hours to code something because it takes me 5 minutes a week to do and an Outlook reminder helps me. 3 hours in 5 minute chunks is 36 weeks of time. Plus possible maintenance issues, plus enhancements, etc. Not sure it's worth it in all cases.

In  terms of rewriting software, I think there's almost a case to start two design processes. One with a person that has knowledge and can use that to build a better system. One with a person that is ignorant of current issues and approaches it freshly. You could then combine the designs, or reexamine each one after an initial design period to see who might be approaching it the best.

I think I need a blog on this.

Leave a Comment

Please register or log in to leave a comment.