Summary: This book is basically a collection of tips and other best practices in writing software (or preparing to write software or judging the software once parts of it are written).
Comments: This isn't really a book to read straight through. It does seem like it might be a good reference though. Assuming I remember that I have it.
Wednesday, November 28, 2012
Sunday, July 8, 2012
The Fault in Our Stars, by John Green
Summary: This is the story of Augustus and Hazel, two teenagers who have cancer, and also the story of a book.
Comments: In spite of the cancer, this isn't a particularly depressing book. It's also not a trope of person beats cancer (at least for now) and goes on to save the world. It's mostly just a story of two teenagers and the adventure they have. I think the cancer aspect does make me think though. Cancer is rarely something that's relevant to my day-to-day life.
Comments: In spite of the cancer, this isn't a particularly depressing book. It's also not a trope of person beats cancer (at least for now) and goes on to save the world. It's mostly just a story of two teenagers and the adventure they have. I think the cancer aspect does make me think though. Cancer is rarely something that's relevant to my day-to-day life.
More Information Than You Require, by John Hodgman
Summary: This is a book of fake trivia. Everything in it contains some amount of untruth to it.
Comments: I think this book strikes a decent balance between truth and untruth. A certain percentage of the stories contain an element of truth to them prior to taking a turn for the weird. I found this to be a rather amusing book, but I certainly wouldn't rely on it for anything.
Comments: I think this book strikes a decent balance between truth and untruth. A certain percentage of the stories contain an element of truth to them prior to taking a turn for the weird. I found this to be a rather amusing book, but I certainly wouldn't rely on it for anything.
Tuesday, January 24, 2012
Code Complete, by Steve McConnell
Summary: This book is a series of tips about how to write good software. It starts with the design process, moves on to coding, and then debugging. The author manages to fit quite a few tidbits into about 1000 pages.
Comments: I think I learned quite a few things, but I would say most of the value of the book lies in being able to reference it later. And in spite of being long (and taking me 6 months to read), I found it interesting. I kept stopping to write down things that I found useful or amusing or that caused me to reflect on something. I did find a couple (probable?) inaccuracies, but neither of them had anything to do with code; they were both in examples. One related to the highways in western Washington (a reference to an exit that doesn't exist) and the other related to car speedometers (a claim that they read 0 when you're backing up because they can't go negative). I'm not sure what percentage of my comments related to code and what percentage were things like squee over the penguin that was on a picture of an iceburg or noticing random pictures from somewhere in western Washington (the author is from somewhere not far from Seattle, which is probably why places I'm familiar with kept popping up). My notes also included a long list of books and articles that might be worth reading. There were a number of references to studies that people had done, and I'm curious how they came up with their numbers and if they have any speculation as to cause. I would say it's worth reading for any programmers out there, but probably over the head of most other people.
Comments: I think I learned quite a few things, but I would say most of the value of the book lies in being able to reference it later. And in spite of being long (and taking me 6 months to read), I found it interesting. I kept stopping to write down things that I found useful or amusing or that caused me to reflect on something. I did find a couple (probable?) inaccuracies, but neither of them had anything to do with code; they were both in examples. One related to the highways in western Washington (a reference to an exit that doesn't exist) and the other related to car speedometers (a claim that they read 0 when you're backing up because they can't go negative). I'm not sure what percentage of my comments related to code and what percentage were things like squee over the penguin that was on a picture of an iceburg or noticing random pictures from somewhere in western Washington (the author is from somewhere not far from Seattle, which is probably why places I'm familiar with kept popping up). My notes also included a long list of books and articles that might be worth reading. There were a number of references to studies that people had done, and I'm curious how they came up with their numbers and if they have any speculation as to cause. I would say it's worth reading for any programmers out there, but probably over the head of most other people.
Subscribe to:
Posts (Atom)