21–30 of 121 posts
I have never read this book. Ironically, I have read and enjoyed many books from PragProg. But this one always struck me as a "fufu" book, written around giving advice that one can independently reason and acquire during one's career.
Am I wrong? Is this book worth reading if you already have many years of experience under your belt?
I... I don't know. I have never read this book. Ironically, I have read and enjoyed many books from PragProg. But this one always struck me as a "fufu" book, written around giving advice that one can independently reason and acquire during one's career. Am I wrong? Is this book worth reading if you already have many years of experience under your belt?
There's some good advice in the book, but I found the majority of it seems to be rather goldilocks flavored. Implement the features you need, but don't add too many, but don't omit important ones either. Write some documentation, but not too much or too little. Etc. You read it, and oh yes, very wise, but not really helpful? Not much here would be useful in resolving a dispute between two programmers, one who wants t…
The way to resolve the dispute (should there not be much difference between them) is to arbitrarily pick one and iterate in short bursts to ensure its assertions come good.
What I've never been able to figure out is why it has never been updated in all that time. Does anyone know? I heard from someone who heard from someone that there was some kind of legal reason they couldn't update it, but I can't really imagine what that would be.
Obviously, lots of books don't go into multiple editions, but given what this one was about, I felt like it couldn't possibly be entirely full of "timeless advice" that wouldn't ever show its age.
The original version of this book is something I'll always treasure. It sits next to "Code Complete", the Gang of Four's "Design Patterns" book and Martin Fowler's "Refactoring" on my top shelf and I still read parts of it every year.
There’s been a lot of love for this book, but I found the title to be jarring. When I was given the book to read, I was doing a lot of maintenance work, and was doing a lot of ‘duct tape and bailing wire’ kinds of fixes to keep the systems functional, while slowly addressing the root causes of downtime and issues. To me this was truly pragmatic programming, but nothing in the first few chapters even tries to deal wit…
Earlier quoted context omitted.
I'll agree with your summary, but I'll also argue that moderation is often a lesson coders need to learn/remember. It is easy to "know" in theory but become dogmatic in practice. There are reasons we are still learning the lessons from 30+ years ago - we keep getting dogmatic about concepts that interfere.
I think GP's point is that saying "you need to do X, Y, Z" in moderation" carries nearly zero bits of information. Of course I don't want to overdo or underdo something. But how much is too much? How much is too little? How do I know? And since code is something that accumulates over time, how do I maintain the balance? Answers to these questions is what's needed for coders to do a good job. The original book does en…
There’s been a lot of love for this book, but I found the title to be jarring. When I was given the book to read, I was doing a lot of maintenance work, and was doing a lot of ‘duct tape and bailing wire’ kinds of fixes to keep the systems functional, while slowly addressing the root causes of downtime and issues. To me this was truly pragmatic programming, but nothing in the first few chapters even tries to deal wit…
Whats with companies constantly throwing people in the trenches and forcing them to be in constant maintanence mode all the time? I feel like they are just asking for burnout and turnover. If its that bad, give it to someone to greenfield some painful part of it rather than spend their life on the hamster wheel.
Most of the time, you're just throwing crap together at the last minute. Doing things without saying no.
There's some good advice in the book, but I found the majority of it seems to be rather goldilocks flavored. Implement the features you need, but don't add too many, but don't omit important ones either. Write some documentation, but not too much or too little. Etc. You read it, and oh yes, very wise, but not really helpful? Not much here would be useful in resolving a dispute between two programmers, one who wants t…
The other side of the coin is that people are constantly reinventing the wheel, bloating the tool sets, and relearning lessons already learned because of lack of standardization.