81–90 of 121 posts
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.
I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern. I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable…
30 years ago? That was 1989. How many companies were using source control in 1989? How about 1999? Still not very many. 2009? Well, now you will find quite a few using SVN, but Git hasn't really taken off yet.
In 1989? Lots of RCS shops who had recently moved to CVS and were excited about the "C" part...
I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern. I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable…
30 years ago? That was 1989. How many companies were using source control in 1989? How about 1999? Still not very many. 2009? Well, now you will find quite a few using SVN, but Git hasn't really taken off yet.
I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern. I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable…
> I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. This made me laugh - not because you aren't right (in theory), but because I just took over a project from a big four consulting company. When I asked about the location of the latest version of the code (after looking in VC and not finding it)...answer: on the production ser…
I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern. I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable…
I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern. I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable…
> I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. This made me laugh - not because you aren't right (in theory), but because I just took over a project from a big four consulting company. When I asked about the location of the latest version of the code (after looking in VC and not finding it)...answer: on the production ser…
Earlier quoted context omitted.
> I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. This made me laugh - not because you aren't right (in theory), but because I just took over a project from a big four consulting company. When I asked about the location of the latest version of the code (after looking in VC and not finding it)...answer: on the production ser…
I was just told at my day job that the team will not be using VC for tracking production analytics code because "using git is over-engineering".
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…
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.
Add Fogel's "Producing Open Source Software" and Brooks' Mythical Man Month and you've perfectly described my shelf too. I found most of those when I was a lowly junior developer and they were instrumental in shaping my thinking, approach, and understanding of tradeoffs. I'd love to see more people pick them up.
So, worth buying ?
Not all of it may appeal to you, but if there are just a few points that help you become a better programmer then it's worth it.