There was once a book written in the 1990s which promoted the idea of the "Lazy programmer".
The book argued that lazy programmers wrote the best code because they would do things like 'reuse' rather than 'copy paste' and write 'high quality, well modularized' code instead of 'crappy spaghetti' code.
They did this because they knew they would have to maintain the code and, being lazy, they wanted the smallest possible code base (via reuse) and the easiest to maintain (high quality, no crap code).
Lazy programmers are too lazy to maintain crappy bloatware so they do their best to avoid creating it in the first place - hire a lazy programmer today! :)
And then code reuse and laziness became Ultimate Virtues, package managers were invented to facilitate it, and maintenance became a nightmare as many devs used other peoples' code with little care. Rather than write the smallest possible code base, easy reuse facilitated bloat and many devs freely indulged in it. I was there at the time. I built my own Linux From Scratch, then I got involved with a distro. I burned out hard.
I think the lesson here is that soundbites out of context get far more traction than actual sense. It's always been a problem. Don Knuth's Goto Considered Harmful was a well-reasoned and balanced paper, but it triggered a fanatical purge of goto which Knuth found disturbing. I think there are other examples, but I just got up and I don't like recalling the bad stuff.
It feels like the problem was worse in the era before most programmers were on social media. There have been "electronic bulletin boards" since the 60s, but I suspect the demographics were heavily skewed towards students. Probably, 90% of mature programmers didn't have access. Then came "eternal September". In 1993, half the kids in America got online and started plaguing the Internet with things they were enthusiastic about but didn't understand. Prior to 1993, September was always like that as new kids got into universities, but the professors had a chance to calm them down. From 1993 on, the hype just never stopped. But now, reading dev.to, I see matur*ing* programmers exerting some influence for good. It might just be my limited perspective, I don't know.
I think the book's author was being rather "tongue in cheek" or maybe even ironic with the term "lazy programmer". The term was probably just click bait in an era before the term "click bait" existed ;)
What I believe he was really promoting was "work smarter, not harder" but that mantra was well established, even back in those days, so would not have had the same eye catching effect on a Borders bookshelf as the concept of an IT author "promoting" laziness.
Everyone knows that the most laziest of programmers are too lazy to spend the time to refactor code to effect code reuse and thus a smaller, more maintainable code base. Truly lazy programmers will copy/paste themselves and the companies they work for into a code bloated, unmaintainable, spaghetti oblivion. I know this because I've seen them in action in various companies for multiple decades. It never ends well. Even if the company survives the bloatification and duplication of their code base their profitability is usually severely constrained.
I remember one project I was brought in to "fix" at the 11th hour. Customer complained about a particular issue in one of the pages and I worked out the cause and fixed it only to get a call from the customer to say the exact same issue happened on another page which I thought was odd ... until I worked out that this other page used virtually the same code (with the same bug) just copy/pasted. I thought, maybe I should search for other occurrences of this code and associated bug ... O_M_G the original developer had FIVE instances of this exact code in the code base when a simple refactor could have seen it done in one method that was called from the 5 places that needed it. Fix the code in that one place and the bug disappears in all 5 pages!
Radical reuse? No, it's just what a half decent developer should have done in the first place.
I remember the Don Knuth's "Goto" experience. Certain types of parsers are much harder to write without using goto but there was the potential for overuse in C, especially by self taught hobbyist programmers coming from BASIC where 'goto' ruled the seas.
I used to read Coding Horror, I do enjoy reading experiences like that. I'm glad I don't have to experience them myself! ;) But no matter how much we explain what the authors of this book and this paper meant, their titles have absolutely been taken out of context. I saw more of it in Linux in the '00s, I think. Perhaps it was the same self-taught hobbyist programmers coming from BASIC who took them out of context, but I think many of them were too young to have experienced that sort of BASIC.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There was once a book written in the 1990s which promoted the idea of the "Lazy programmer".
The book argued that lazy programmers wrote the best code because they would do things like 'reuse' rather than 'copy paste' and write 'high quality, well modularized' code instead of 'crappy spaghetti' code.
They did this because they knew they would have to maintain the code and, being lazy, they wanted the smallest possible code base (via reuse) and the easiest to maintain (high quality, no crap code).
Lazy programmers are too lazy to maintain crappy bloatware so they do their best to avoid creating it in the first place - hire a lazy programmer today! :)
Lazy devs are the best
And then code reuse and laziness became Ultimate Virtues, package managers were invented to facilitate it, and maintenance became a nightmare as many devs used other peoples' code with little care. Rather than write the smallest possible code base, easy reuse facilitated bloat and many devs freely indulged in it. I was there at the time. I built my own Linux From Scratch, then I got involved with a distro. I burned out hard.
I think the lesson here is that soundbites out of context get far more traction than actual sense. It's always been a problem. Don Knuth's Goto Considered Harmful was a well-reasoned and balanced paper, but it triggered a fanatical purge of goto which Knuth found disturbing. I think there are other examples, but I just got up and I don't like recalling the bad stuff.
It feels like the problem was worse in the era before most programmers were on social media. There have been "electronic bulletin boards" since the 60s, but I suspect the demographics were heavily skewed towards students. Probably, 90% of mature programmers didn't have access. Then came "eternal September". In 1993, half the kids in America got online and started plaguing the Internet with things they were enthusiastic about but didn't understand. Prior to 1993, September was always like that as new kids got into universities, but the professors had a chance to calm them down. From 1993 on, the hype just never stopped. But now, reading dev.to, I see matur*ing* programmers exerting some influence for good. It might just be my limited perspective, I don't know.
I think the book's author was being rather "tongue in cheek" or maybe even ironic with the term "lazy programmer". The term was probably just click bait in an era before the term "click bait" existed ;)
What I believe he was really promoting was "work smarter, not harder" but that mantra was well established, even back in those days, so would not have had the same eye catching effect on a Borders bookshelf as the concept of an IT author "promoting" laziness.
Everyone knows that the most laziest of programmers are too lazy to spend the time to refactor code to effect code reuse and thus a smaller, more maintainable code base. Truly lazy programmers will copy/paste themselves and the companies they work for into a code bloated, unmaintainable, spaghetti oblivion. I know this because I've seen them in action in various companies for multiple decades. It never ends well. Even if the company survives the bloatification and duplication of their code base their profitability is usually severely constrained.
I remember one project I was brought in to "fix" at the 11th hour. Customer complained about a particular issue in one of the pages and I worked out the cause and fixed it only to get a call from the customer to say the exact same issue happened on another page which I thought was odd ... until I worked out that this other page used virtually the same code (with the same bug) just copy/pasted. I thought, maybe I should search for other occurrences of this code and associated bug ... O_M_G the original developer had FIVE instances of this exact code in the code base when a simple refactor could have seen it done in one method that was called from the 5 places that needed it. Fix the code in that one place and the bug disappears in all 5 pages!
Radical reuse? No, it's just what a half decent developer should have done in the first place.
I remember the Don Knuth's "Goto" experience. Certain types of parsers are much harder to write without using goto but there was the potential for overuse in C, especially by self taught hobbyist programmers coming from BASIC where 'goto' ruled the seas.
I used to read Coding Horror, I do enjoy reading experiences like that. I'm glad I don't have to experience them myself! ;) But no matter how much we explain what the authors of this book and this paper meant, their titles have absolutely been taken out of context. I saw more of it in Linux in the '00s, I think. Perhaps it was the same self-taught hobbyist programmers coming from BASIC who took them out of context, but I think many of them were too young to have experienced that sort of BASIC.