I think he is probably onto somthing with the lazy programmer idea. It's something that I have thought about a lot too. Although I thought his examples of what a lazy programmer might be doing sucked.
In my experience, lazy programmers write tools to automate stuff. It's the guy that wrote YACC that automates parser generation. It's the person that reads the yacc file and uses it to generate c/h files for each symbol, filled out with all of the initialisers specified in the yacc file. It's the person that generates test scripts from an xml file, etc etc etc.
Actually, the longer I work as a programmer, the more I'm bemused by people that talk about how they never do any interesting programming at work. If you are only doing boring stuff, then you are not doing it right. Build a system to automate that boring stuff, that'll get your creative juices flowing!
In my case, I work for a company that does embedded software . As we often work on devices for which there is only a C compiler, we have to use C as the language of implementation for our product. But personally I haven't written any C code for over 18 months - I'm using ruby to put together a whole series of tools that generate c code from, for example, UML diagrams. There's still a bit of tweaking to be done to the C code at the end, but it is just tweaking, which improves productivity for the whole team. Leaves us time to go and get an espresso from the cafe down the street instead of slaving away on boring projects.
Um, no? Should there be? Oh, you're talking about the 'tweaking'? Sorry, I was talking about some specialised edge cases where it just isn't worth trying to make the work automated. Basically all of the boiler plate code is automated, and all of the unique code for each class is coded by hand. But generally it is about 60% boilerplate and 40% unique code. The result is that programmers do 60% less coding, and only need to muck around with the unique/interesting code.
It's not perfect, but it takes a lot of the drudge out of the working day, which was kind of the point I was trying to make in the original post.
On your first point, I think he's suggesting something like "a lazy programmer will right great, detailed unit tests because he's too lazy do all the work by hand and not excited about fixing obscure bugs down the road." Seems a bit odd to call that lazy, but I get the gist.
On your second point, I guess I would say that "curious" might be an odd word. Some people who are intellectually curious dive into things very thoroughly, so they are likely to be meticulous but also likely to quickly find something else to obsess over.
Work ethic probably outweighs everything else over time. Getting something done that is sub-optimal still beats a great design that's never implemented.
In my experience, lazy programmers write tools to automate stuff. It's the guy that wrote YACC that automates parser generation. It's the person that reads the yacc file and uses it to generate c/h files for each symbol, filled out with all of the initialisers specified in the yacc file. It's the person that generates test scripts from an xml file, etc etc etc.
Actually, the longer I work as a programmer, the more I'm bemused by people that talk about how they never do any interesting programming at work. If you are only doing boring stuff, then you are not doing it right. Build a system to automate that boring stuff, that'll get your creative juices flowing!
In my case, I work for a company that does embedded software . As we often work on devices for which there is only a C compiler, we have to use C as the language of implementation for our product. But personally I haven't written any C code for over 18 months - I'm using ruby to put together a whole series of tools that generate c code from, for example, UML diagrams. There's still a bit of tweaking to be done to the C code at the end, but it is just tweaking, which improves productivity for the whole team. Leaves us time to go and get an espresso from the cafe down the street instead of slaving away on boring projects.