Again, confusion is the result of describing two different things with the same word:
1. Desiring efficiency, so one can achieve more with less effort.
2. Not wanting to think very hard, and putting off difficult decisions.
This article argues that programmers aren't number 2. I'd agree. Others argue that programmers are number 1. I'd agree. There's no conflict here, just confusion!
But the first definition doesn't make much sense does it?
For example: if you're in good shape you can run up a flight of stairs without any effort. But is getting in shape laziness? Not by any sane definition.
I'm sure you can think of a dozen other analogies, but they all illustrate the same thing: educating yourself, improving your tools, getting in shape are not laziness but the opposite.
And I think that's what original author meant. There is conflict between the definitions, and only the second definition indicates laziness.
I use the term intelligent laziness, that is the constant desire to minimize the effort you will need to invest long-term in your life to achieve your goals.
Suddenly writing code cleanly becomes a very lazy thing to do, it reduces the amount of effort you have to invest in a program over the program's lifespan, unless its a throwaway and then ugly stuff makes sense.
Working out isn't a lazy thing, it is easier to climb a flight of stairs than to train 6 hours a week for a year and climb a flight of stairs. It increases the efforts you invest in things, it might be a goal to be healthy and energetic but then the lazy thing to do is to try to hack your training schedule and get the most benefit out of every drop of sweat.
I think the confusion comes from applying real world constraints to code. Most people would be in shape if you only needed to get in shape once and you maintained that body with zero effort over time. Lazy programmers recognize you only have to build the code once to benefit every time you use it. So building tools can be useful but only if they are going to save you effort over time.
The problem I see with many lazy programmers is they tend to hide how easy it is to fix problems over time. If might take them five minutes to do something, but they don't feel the need to share this with other people. But, in the end lazy programmers tend to get more done than average even if they don't spend much time actually working.
What if I decide to take the elevator? Some would say I'm lazier than the person who takes the stairs, but if the goal is only getting to the 6th floor, then being lazy (resistant to exertion) was more efficient.
Getting in shape would be like working to increase your typing speed so you can write 1k-line programs easier when a lazy programmer would just write a shell one-liner (take the elevator).
The article is pointing out that "lazy" is often used like this:
"I program because I’m too lazy to do the same thing again and again!"
i.e. I want to abstract the concept of doing it into a computer program (or shell script, or cron job, or whatever). But the author understands "lazy" to mean something different, and more to the point, negative.
The point that I'm trying to make is that this argument is not about whether programmers are lazy, but it's about what people understand by the word "lazy".
I understand what you're saying. And I think this whole mess could be clarified by simply not using "lazy." I think it's pretty normal for people to assume the dictionary definition, and I don't think I would challenge anyone against thinking differently.
I was going to disagree with this article until I actually took the time to read it.
Sapir-Whorf says that the words we have available to us (and choose to use) influence the way we think. Perhaps "Good programmers are lazy" is, in that respect, using the wrong word. Perhaps it encourages the wrong habits of thought, and a better choice of words would have a beneficial effect.
Then again, perhaps the problem is due to the incompleteness of the quote. It's not laziness in isolation that works, but "laziness, impatience, and hubris", quoting Larry Wall.
An arrogant programmer would not copy and paste the same function 40 times - it would hurt his sense of self-worth. Perhaps what works is the three "qualities" together, rather than in isolation.
First: I think the influence of the word lazy on good programmers is to encourage them to be more efficient. I could be wrong, but that's how it feels to me.
Although I think the author is right that copy/pasting the same function 40 times does represent laziness, it also represents short-sightedness. Something the Wall quote doesn't explicitly state is that the good programmer is looking to optimize for the sum total of effort over the project (or programmer) lifetime, not to be "lazy" in the immediate moment, mortaging the future for ease of the present.
I'm probably pointing out something obvious here, but I don't see any other comments mentioning it yet.
Larry Wall was trying to employ humor to get a point across. By coming up with three negative character traits and finding a way to plausibly make them sound like positive character traits, he got attention because his choice of labels was so surprising. If that causes someone to be curious enough to read more and think about what he is saying, edification can result. If he had just laid out the same principles without the surprising labels, he would have gotten much less attention.
The danger, as with any joke, is people not "getting" it. I think that is what this article warns against. People not in on the original joke, might think that you want to be lazy in the conventional sense. Or, worse still, someone might use Wall's quote to defend their own, (conventionally) lazy behavior. Kind of like someone watching All in the Family and not getting that Archie Bunker is not meant as a positive role model.
People who say Good programmers are lazy are obviously using the word in a different context than what the author of this article is talking about. She even mentions this.
She then proceeds to say that it's a "cry for attention", like a skinny girl calling herself fat. It is not, it is an honest statement, and frankly the meaning of it isn't far from the classical definition of laziness.
You know why I write shell scripts? It's not because I'm concerned about clarity, or modularity, it's because I don't want to type "dhcpcd -k wlan0 && iwconfig wlan0 essid $ESSID && dhcpcd wlan0" more than once. This is why people have made things like paste, or abbrevs.
When I'm writing application code, sure I'll be more concerned with clarity, modularity, efficiency, and the rest of it than I am when I'm basically pasting some command commands into a script - but a good bit of the abstraction that I do in application code also stems out of laziness. I just don't want to type that shit in again, if only a little bit of it would change. Laziness is one tool I use to discover abstractions worth having.
Sure, copy-and-paste works too - but that's only laziness in the short-term, and often generates an assload of work in the long-term. Most people who have been writing code for any length of time know this.
I'm lazy for the long-haul.
She's correct that simplicity and elegance are hard, and that striving for them is not lazy. I can tell you that some of the repetition-saving abstractions I have made before are neither simple nor elegant, and didn't take much striving.
I don't think that anyone ever claimed that good programmers are just lazy. Laziness without that strive for simplicity/elegance/clarity leads to hard to maintain code. However, I have yet to meet a coder that I had any respect for that didn't twitch and the prospect of having to perform the same task on a computer more than twice though - and that's because that means it could be automated, and they "didn't want to have to do that shit over and over", not because there was necessarily a beautiful abstraction to be found there.
But uh, yeah. That probably sounded a lot harsher than I intended it to. I think I should get some sleep now.
Laziness is different for different folks. It's like using VIM - just a question of intelligence. If you are relatively smart, you can quickly come up with a complex VIM command sequence to do what you need. Otherwise, you copy and paste for 5 minutes, because that's quicker (or at least you think it's quicker, which is even worse).
Same with programming - if you are a good programmer, it's quicker for you to invent and refactor then to copy and paste, so you do that. Only in that case is laziness good.
Long term laziness and short term laziness aren't the same thing. Good programmers are willing to sacrifice in the short term (work really hard) to be lazy in the long term (have the computer work really hard for them). Like learning Emacs or VIM - you work hard in the short term to work less in the long term. Like almost all things in life, having a long term view of things makes short term sacrifices seem less painful.
If I recall my Camel Book correctly, Larry Wall called what the article describes as "False Laziness". Copy-and-pasting code will save you time in the short term, but probably cost you time in the long term. If laziness is about minimizing effort, then a truely lazy person will take the time to do things correctly so that he or she has less to do later on.
"Laziness makes you not mind if you copy and paste a function 40 times without abstracting it. Laziness lets you avoid figuring out how to do something better, because you really don’t want to think about it. Laziness lets you put off finding a solution, copy code without understanding it, hard-code values in your applications, or stuff inline css in your html tags ‘just for now’."
1. Desiring efficiency, so one can achieve more with less effort.
2. Not wanting to think very hard, and putting off difficult decisions.
This article argues that programmers aren't number 2. I'd agree. Others argue that programmers are number 1. I'd agree. There's no conflict here, just confusion!