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.
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.