To people who haven't heard this before it sounds a bit counter-intuitive. But look at it the following way:
I have 10 computers. (Not really, just for the sake of argument. In fact, this whole example is going to be a bit contrived...) I've decided I want to host a porn site on these machines, and I've decided I need this many just to handle the load. (Encoding realtime streaming videos can take a lot of processor power. Or so I hear...)
Solution 1: I could just log into each machine and set it up separately. Maybe that takes me 3 minutes per machine to do the special setup for this particular application. So it'll take me half an hour to do it. But I won't have to do much thinking, 'cause I'm used to setting up servers.
Solution 2: Alternatively, I could spend half an hour writing and testing a script that would do the setup for me. Then, I spend a couple of minutes running the script on all ten machines. This requires me to actually think, and to maybe bang my head against the wall while debugging the inevitable coding mistakes I make.
So it sounds like the first solution is best, right? I don't have to think, and I finish quicker than the other solution.
Wrong. Solution #2 is actually lazier. Here's why: a couple of months later, my site has become so popular that I decide to double the amount of servers, so I can make my millions and retire early. If I chose solution 1, I'd have to spend half an hour doing really boring stuff, whereas solution 2 only requires me to spend a couple of minutes.
So being a lazy programmer is all about avoiding dull and repetitive work, and replacing it with work that's interesting, and in the process, eliminating future drudgery. If you ever have to do something more than once, consider automating it.
Another way it's possible to be a lazy programmer is to be as general as possible. Sometimes you'll be writing something, and decide that you can spend just a couple of minutes, and the function can handle twice as many sorts of input. Do it. You might not need it now, but you might need it in the future.
An example from my personal experience: I write a lot of shell scripts. I work with a lot of data that's indexed by the date. A year and a half ago, I wrote a function to parse dates. I wrote it in such a way that it could take a date range, and split out a list of dates. It also handles just about any date format you can throw at it (this is actually easier than it sounds, with the date command). Because of this, I've been able to use this function in at least 30 programs over the last year. And each time I use this function, I save myself a couple of minutes of time, and have a really flexible interface for people to use. It took about twice as long to write the function and put it in a separate library so I could import it into later scripts, but that extra two minutes has saved me time over the past year. And since it has been tested by extensive use, I've fixed the bugs that have cropped up because of weird input people have fed it. More bug-free code, and saved time, just by spending a few minutes a year and a half ago? That's pretty lazy.