Microsoft Solutions Framework Essentials

The book, Microsoft® Solutions Framework Essentials was referred to me as a deep resource on the Microsoft Solutions Framework so I thought I’d give it a read. The chapters on project management or iterative development weren’t new to me, but I did appreciate the focus on technology projects. The section that really jumped out at me was on mindsets. It can be hard to introduce change to a team once they get started, but anyone can change their mind at any time. That's what struck me as being so valuable about mindsets, you don't need to buy anything, convince anyone about a technology change, or get anyone else to agree or approve. You can just change your mind and go.

Thinking... please wait

MSF Mindsets

  • Quality Is Defined By Customer
  • Pride of Workmanship
  • Team of Peers
  • Frequent Delivery
  • Willingness to Learn
  • Get Specific Early
  • Qualities of Service
  • Citizenship

Book Review: 97 Things Every Programmer Should Know

As the title suggests, 97 Things Every Programmer Should Know is a buffet table of delicious best practices including small functions, unit and performance testing, version control, command line tools and more. However, just as many chapters focus on personal traits such as perseverance, reflection, professionalism, continuous learning and other traits that only apply to the reader. Finally, there are stories from the trenches such as the importance of realistic test data, (there are a lot of error message that lead to "career limiting" events) as well as requirements gathering and project management.


From Chapter 25

It was getting late. I was throwing in some placeholder data to test the page
layout I’d been working on.

I appropriated the members of The Clash for the names of users. Company
names? Song titles by the Sex Pistols would do. Now I needed some stock ticker
symbols—just some four-letter words in capital letters.

I used those four-letter words.

It seemed harmless. Just something to amuse myself, and maybe the other
developers the next day before I wired up the real data source.

The following morning, a project manager took some screenshots for a

This book is an easy read, since each chapter is a maximum of 4-5 pages. This makes it a great book to read on the train, or as part of a brown bag session at work. However, none of these chapters provides enough background to start a new development exercise. For that reason, I would suggest this book to new programmers who are looking to become professional developers. Many of the concepts in this book are not covered in a university CS program, and developers need to learn the lessons at some point. For current professionals, I found the book to be an easy read (and a reminder for certain practices which you may have let fall by the wayside).


From the preface:

There is no overarching narrative: it is for you to respond to, reflect on, and connect together what you read, weighing it against your own context, knowledge, and experience.

Programming Pearls

My review of Programming Pearls is going to require a little personal background. My undergraduate degree is in Finance, not Computer Science, and my focus has always been on programming, not computer science. However, I have enough experience now that I'm running into those things that CS majors need to know.

When I first started reading the book, it was dry and academic, and I quickly lost interest. The first few chapters focused on algorithms. It went into my bag, not to be read. Recently I was bored on the train and tried to keep reading it. I was quickly drawn in, nodding my head as I read the problem descriptions he sets about to solve. The book quickly became much more compelling to me and I was excited to keep reading. The book is a collection of articles from Communications of the ACM that actually read pretty quickly. The focus is on "thinking" about difficult programming problems to come to elegant solutions. The "pearls" are born from irritating programming problems. The book is split into

  1. Preliminaries
  2. Performance
  3. Product

I realized, that for myself, the first part was a bit too academic, and the third part was a bit contrived, while the middle chapters about Performance were just what I needed. At the end of the book (currently second edition) there was a compendium of common algorithms and it's easy to compare/contrast them. After reading this, the first chapters were much more meaningful. If you are finding it difficult to follow this book, jump ahead to another chapter or section that may interest you more.