Book:	Design Patterns
	Authors:	Erich Gamma, Richard Helm
		Ralph Johnson, John Vlissides
	Binary Review:	1

I’m still terrible at Book Reviews. So heres some dot points:

• Its good, you should read it. Pretty hard read though.
• I don’t understand a lot of it, so I’m going to read it again.
• After reading it, I feel like I’m a better programmer…but I don’t exactly know why.
• Very very well documented.
• Examples mentioned lots of things I don’t know of (i.e. not familiar with C++, Smalltalk etc). Made reading them a little harder.

This is the kind of book, when you’re reading through it, you find a pattern and you realize “Oh damn, that would have been handy when I was implementing X a few months ago” or some similar train of thought. I imagine the more familiar I become with the contents of the book, the more I will have these flashes AS I develop, rather than afterwards (hence why I’m going to read it again).

The book , being essentially a reference manual, does sort of require multiple readings (to familiarize yourself with all of the patterns and their uses) because it would really become useful. Additionally, it is a very hard read. I might not have gone about it the best way (read it from front to back), but hey, my way or the highway.

	Book:	The Pragmatic Programmer
	Authors:	Andrew Hunt, David Thomas
	Binary Review:	1

I’m terrible at Book Reviews, so I’m going to keep this brief. Andrew and David distill within this book 2 lifetimes of knowledge on a variety of programming related subjects (writing code, automation, testing and documentation, basically everything you can think of). Handily, they also summarize each of the important points in the point in small, easily digestible tips. I’m going to mention what I think are the top tips below:

• 4.) Don’t Live With Broken Windows

  The point of this tip, is that if something is broken, it encourages people to care less. A car can sit untouched and pristine for a long time, but as soon as a window is broken, its stripped and generally raped in a few hours. The broken window is a sign that no-one cares, so its okay to not care as well.

  Broken, crap, undocumented code encourages other people to produce more of the same. The lesson here, don’t just leave windows broken, and code covered in shit.

• 11.) DRY - Don’t Repeat Yourself

  Don’t Repeat Yourself. So I wont.

• 12.) Make It Easy to Reuse

  Always write code with possible reuse in mind. If something is specific, abstract it out. The code itself, and its internal structure, should be intended to be used in more that just one place. Never assume that something isn’t going to have another use later, unless……

• 16.) Prototype to Learn

  You prototype! The key point here, and the one we fail at miserably, is that you do NOT continue to develop prototype code. You kick it to the curb. Prototype code is NOT code that should be used, extended or anything of the sort. You prototype to learn a lesson, not to create a code that will be used later on. If you are trying to do that, you should follow the Tracer Bullet approach (where you create code that is of high quality, but limited in its functionality, with the intention to extend it later. You create a solid base to work from).

• 62.) Test Early. Test Often. Test Automatically.

  Self explanatory, and yet we still don’t do it.

I’ll be honest. Theres a lot more of worth in the book than just the points above and I’m doing the book a disservice by trying to pick the top X points of worth.

In summary, if you are programming, and you haven’t read this book, you’re probably shit (I know I was before I read it!).

Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers)

Binary Review: 1

Release It! is a great book, if you’re planning on designing and building software that doesnt suck. It speaks at length about the various patterns and anti-patterns for Stability and Capacity, explaining how to create software that will run successfully in a production environment (you know, without crashing, burning, dying, being wrong, being stupid, killing your loved ones, etc).

It contains many tidbits of information about potential pitfalls, issues that your average software developer probably wouldnt have thought about (unless of course they had personally run into them bef0re). Of course it also contains ways to minimise the impact of those issues on your software. I wont go into more detail, because a lot of the information in the book is very specific, but I personally learned many lessons from it.

Overall, incredibly useful, recommended reading for anyone whos going to write software. Any software. At all.

PS:

Dont read this book just before you start working on a massive project, because it will terrify you with a giant list of all the ways you can screw up.

Personal Binary Review: 1

Entertaining, easy to read, interesting ideas, storybook format.

Business Binary Review: 0

Lessons more applicable to large manufacturing corporations struggling with outdated organisational structures and ideas, less applicable to younger, more agile organisations not run by dinosaurs masquerading as men.

The basic point of the entire book, is that Semler is a renegade, who implemented the idea of empowering his employees (in Brazil of all places) and actually treating them like people, and it paid off. I know, shocking, right?

Still, some interesting points:

• Complete transparency to the inner workings of the company, including employee salaries. Everyone knows everything.
• People set their own salaries, which allows for voluntary cuts during hard times, and raises and bonuses during good times. System isnt open to manipulation, because everyone knows everything from the point above.
• Challenge anything, anywhere, anytime and have people in power who will listen.

In summary, interesting, entertaining story but business lessons not really applicable to us.