Book Review: Code Complete, 2nd Edition

Code Complete by Steve McConnell
My rating: 5 of 5 stars

This book provides a solid foundation of the things you need to “construct software”, as the author describes it, and covers a very broad topic.

The author isn't shy about referring the reader to additional reading materials; in fact, that’s a big part of the book and I love it!

The book goes over things that were barely mentioned, if at all, in my college courses. Things like: debugging, refactoring, measuring code complexity, when the right time to optimize code is and whether it even makes sense to optimize it. The author does a good job of showing different approaches to solving problems and gives many examples of “good” versus “bad” practices.

On the surface this book is similar to The Pragmatic Programmer, but goes in to a lot more depth. The book goes well with Clean Code.

View all my reviews

Create your personal brand

I love channel9.

If you've never heard of it, you should definitely check it out. It’s a site filled with interviews, keynote speeches and demos in video format. It’s one of my favorite learning resources.

I was browsing channel 9 the other day, and came across this keynote. In it, Scott Hanselman talks about social networking, something that I’ve never been really crazy about. Despite my aversion to the topic, the title interested me, so I watched the hour long video clip (and the 25 or 30 minute follow up).

Scott argues that every developer should have a blog and use twitter, I’ll leave the details to the video, but the gist of it is that you should think of it as creating your own personal brand.

I liked the idea of a personal brand so much that I extended the concept to that of a virtual business for my online “persona”, to steal a term from Alan Cooper. By thinking of my online self as a business, I can filter what I am willing to blog about by whether or not it’s good for the business. I know, it’s a bit silly, but it makes me more comfortable with the idea.

Once I changed the way I was thinking about it, I had a philosophical moment where I realized that, not only can I apply this to blogging and my career, but the concept could be applied to virtually all aspects of life. It reminded me of a podcast I listened to a while back about relationships.

I think it could be interesting, as well as, motivating to come up with a mission statement and a set of business rules. At the end of the day though, I think it will make me a better developer and that is what really matters.

Book Review: CLR via C#, Third Edition

This book was 29 chapters of awesome, and if I had to pick a favorite book this would be it.

Jeffrey Richter starts off by explaining how the CLR’s execution model works and how to package and deploy applications.  The book covers how to use and design Types, how the garbage collector manages resources as well as threading.

The author does a really great job of explaining everything, and is careful to point out what his personal preferences are and why. The material in this book lays a solid foundation for development using the CLR, C# and the .NET framework.

This book is going to be a great reference.

Book Review: Clean Code

When I read the first few chapters of this book, I wrote about my initial reaction. Now that I’ve completed the book, this is a follow up.

This book is basically split in to two things: organizing your code so that it’s easy to read and following “good” OO practices. A great deal of the information presented in Clean Code is Robert C. Martin's personal preference, he’s very upfront about that, and what he has to say throughout the book makes a lot of sense.
The first part of the book makes it seem like writing clean code is relatively simple:

• Use unambiguous names for variables and methods.
• Comments should say things that the code can't say for itself.
• Keep methods small.
• Write unit tests.

Organizing your code as the author suggests, will make it very easy to read.

The trickier part has to do with the OO principles that are covered.
Knowing when you've violated SRP, OCP or if your methods have multiple levels of abstraction can be more difficult.

Fortunately, there are some nice examples in the book that the author walks you through. This is something that is clearly going to take practice and discipline to master.

All of the examples are in Java. I use C# at work, so I converted the examples to C# and refactored them alongside him. I found this to be very helpful.

In addition to covering the importance of unit testing and the role it plays in keeping your code clean, the author has listed all of the advice at the end of the book. This makes for a handy reference to ensure that you are writing clean code and is listed under the heading “Code Smells”. The list includes advice from the author as well as Martin Fowler.

I enjoyed the book and look forward to mastering the techniques that were covered.

* Update *

I found a video clip of Robert Martin where he presents a lot of the points in this book.
It's a little under an hour long and despite the fact that he rambles a little bit for the first 8 or 10 minutes, it's worth watching.

Does function size matter?

I just finished the 3rd chapter of Clean Code by Robert C. Martin and I feel like my brain has exploded.

I couldn't resist writing a post about what I've read so far, to see what others thought about it. Even though I'm only at the very beginning of this book, I can tell I'm going to like it.

• The first chapter talks about what makes code "clean" (according to the author and a number of developers that are considered industry leaders).
• The second chapter talks about meaningful names, what makes them important, along with some examples. Interesting, but nothing super exciting.
• The third chapter is all about functions. This is where I had a mini freak out in my head.

The author believes functions should:

• use descriptive names
• be small - about 2 or 3 lines each
• do one thing and do it well
• only have 1 or 2 arguments passed to them, preferably none
• have one level of abstraction

This ends up resulting in a LOT of functions. The author argues that if you do this, your code becomes very easy to understand and reads from top to bottom, like a story.

I've never given much thought to the size of my functions before, but 2 or 3 lines seems exceedingly small. I tend to write functions that are 6 - 10 lines.

I've never given ANY thought to the levels of abstraction in my code, in fact, I didn't even know what that was before I read about it. In case anybody else has never heard of this term, the idea behind it is that everything in the function should be at the same level of granularity. Here is a nice definition from Wikipedia and a post on stackoverflow with a good example.

The author argues that it can be confusing if you don't follow this principle because you aren't able to tell whether an expression is an important concept or a detail. Mixing the two in a function is just as bad as falling to be weary of the broken window theory.

If having code that is easy to read and maintain isn't compelling enough for you, and you are programming against the .Net framework, you might be interested to know that Jeffrey Richter, in CLR via C#, points out that code converted to IL is evaluated on a method by method basis. This means that a method isn't evaluated until it is actually needed - this makes your code run faster. Additionally the CLR optimizes the code by "enregistering " variables in the method, but only if it is small enough. Unfortunately Jeffrey doesn't specify what a "small" method actually is.

Book Review: Pragmatic Unit Testing

I didn't even know what unit testing was before I picked up this book.

At not much more than 150 pages, this book is small. It's part of a series called "The Pragmatic Starter Kit". That series is part of a larger series of books that started coming out after "The Pragmatic Programmer" was published.

I LOVE what unit testing promises. To be able to incrementally build code that is known to work AND be instantly alerted when you break it is very, very cool.

The book goes over the NUnit framework, walks you through the initial setup, and shows some unit tests in an example project.

After reading this book, I have no idea how to write a useful unit test.

My guess is that it must take a lot of experience to do it well and might even be a bit of an artform.

The book talks about testing principles, fence post errors, mock objects and edge case scenarios. Things like: testing for null or handing a pre-sorted algorithm to a sort algorithm.

None of that really helps me.

Because of this book, I understand why it's a good idea to write unit tests and what the common reasons are that developers give for not writing them.

Even though I scratch my head a lot when I try to write a unit test, I've started using them. I open the book up, look through the examples, and skim the chapters looking for an appropriate example. Most of the time I feel like I'm missing something.

I'm wondering if I need to read a different book, one that has more concrete examples or find an open source project that uses unit tests.

Book Review: C# 2010 for Programmers, 4th edition

This book isn't for everybody. I found it to be perfect.

My first programming course in college was taught with the "C: How to Program" book by Paul and Harvey Deitel. I think that made this book feel very familiar to me. The difference between the "How to Program" and "For Progammers" series, is that the former includes practice exercises, the latter does not.

I really enjoy the Deitel books, and don't mean to make this sound like a negative review; however, I think the title of this book is a little misleading. The book's title should have been something more like: Intro to .Net development using C#.

In my opinion if you are an experienced developer that needs to pick up C# and .Net, you will probably be disappointed with this book. I think you can probably get what you need from google and some trial and error. On the other hand, if like me, you are a newbie and haven't done much programming and haven't had a chance to become familiar with OOP, XML, UML, etc, then I highly recommend this book. Reading this book will introduce you to the basics I just mentioned as well as C# 4 and .Net, Silverlight, WPF, XAML WCF, Windows Forms, Visual Studio and SQL server express.

The book is well written and offers the classic Deitel "tips" (common programming errors, software engineering tips, etc), that said, it feels like an introductory programming book that you can save a few bucks on because it doesn't have the exercises that you would find in a classroom textbook.

Book Review: The Pragmatic Programmer

When I first started reading this book, it seemed to me to be a lot of stuff that I would consider common sense. As I progressed through the book, I noticed that it felt more and more like I was getting really good advice from an experienced developer.

I'm glad I read The Pragmatic Programmer early in my career. The authors talk about things that I think you can spend a lot of your time, if not your entire career, perfecting; things like the DRY principle, being careful not to program by coincidence, and the value of being able to make good estimates.

They also mention some really interesting things to ensure your code stays tidy and flexible, like moving the things that can change out of your code and in to configuration files, programming to an interface, and being aware of the broken window principle.

Overall I enjoyed the book, but I wish it had been more detailed. All of these principles are really great, but it would be nice to have somebody that's been there and done that to actually show you the ropes. The authors acknowledge this shortcoming in the resources section at the end of the book and provide a nice list of books, blogs, magazines and web references to look in to for further reading.

Book Reviews

I've been reading.

On average, I read one book related to software development per month.

I've been doing this since I started developer work in March.

I'm going to review what I've read and express my personal opinion.

I'm a newbie so this will naturally be reflected in my review. 

My hope is that this will generate discussion and suggestions for further reading and exploration.

At first, most of what I was reading was directly related to projects that I was working on. As I started to get a handle on the basics at work, I compiled a list and started working through it.

I developed the list based off advice from a couple friends, Marshall being one of them, as well as recommended titles I found while searching stackoverflow.

See what I'm currently reading.

To date I've read:

• C# 2010 for Programmers
• Professional Silverlight 4
• CLR via C# (Dev-Pro) (text only) 3rd (Third) edition by J.Richter
• Programming Entity Framework 2nd edition
• Refactoring to Patterns
• Agile Software Development, Principles, Patterns, and Practices
• Pragmatic Unit Testing in C# with NUnit, 2nd Edition
• The Pragmatic Programmer 
• C# in Depth, Second Edition 
• Clean Code
• Code Complete

Books remaining in my library that I haven't read:

• Inside the Microsoft Build Engine
• The Inmates Are Running the Asylum 
• Effective C# 
• More Effective C# 
• Head First Object-Oriented Analysis and Design 

Books I'm planning on adding to my library:

• Patterns of Enterprise Application Architecture 
• Real World Functional Programming: With Examples in F# and C# 

Books I'm considering adding to my library:

• UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition) 
• Programming WCF Services: Mastering WCF and the Azure AppFabric Service Bus 
• WPF 4 Unleashed 
• Silverlight 4 Unleashed 
• Universal Principles of Design, Revised and Updated: 125 Ways to Enhance Usability, Influence Perception, Increase Appeal, Make Better Design Decisions, and Teach through Design 
• Coder to Developer: Tools and Strategies for Delivering Your Software 
• Software Craftsmanship: The New Imperative

Are comments always necessary?

I was reminded of a conversation Marshall and I had about comments when I read this post by Jesse Liberty.

The post gives an example of the reason your comments should explain why you're doing something, rather than how you're doing it.

At the end, Jesse argues that if your reader knows the language, your comments will be reduntant if you use descritptive names for methods and variables.

Lately I've been thingking a lot about how much I should be commenting. And whether or not I'm just stating the obvious.

Take this method for example.

public string GetRunTimeForAllCars()
{
  IEnumerable<Car> listOfCars = listOfVehicles.FindAll(c => c is Car).Cast<Car>();
  double totalRunTime = listOfCars.Select(t => t.RunTime).Sum();
  return totalRunTime.ToString("f2");
}


I experimented with a few ways or writing the method out before I decided on this one.
I think it's pretty clear and doesn't need any comments to tell you what's going on.

What do you guys think?
Are comments always neccessary?
If somebody doesn't know linq, can they still understand what that code is doing?

Being a better developer

Scott Hanselman lists some things to "sharpen the saw" on his website.

I listened to the podcast he links on his page, he mentions several things I found interesting.

Reading books is a great way to learn, but Scott warns about becoming "too academic". A great way to improve your own code is to read other's code. Of course, you want to make sure the code you're reading is "good code". One way to do this is to read code from successful open source projects.

Scott mentions several by name:
CastleProject, Microsoft's Patterns & Practices, SubText and he puts in a plug for dasBlog as well.

Other things he talks about doing are:
Talking with other developers about how they do things.
Teaching a class on a topic and joining a developer's users group.

I'm guilty of being too academic. I do a lot of reading, mostly books.
Since March I've read: Programming Entity Frameworks, Refactoring to Patterns, Pragmatic Testing in C# with nUnit, C# in depth, and I'm halfway through CLR via C#. These are on my list for the next 6 - 12 months: The Pragmatic Programmer, Clean Code and Code Complete 2, they've arrived at my house and I'm really excited to read them!

I also listen to podcasts, mostly Scott Hanselman's, and I read blogs from the same, as well as, Scott Guthrie, Jeffrey Palermo, Eric Lippert, Julie Lerman and John Papa.

I've watched quite a few videos on SilverlightTV and Channel9.
There are some really great videos on that site.

I really like watching the videos and downloading the code from the show, it's really great to be able to go through the code to see how they've done what they're talking about on the show.
That makes me think that checking out code from some of those open source projects is going to be really good for me.

Scott briefly mentions that learning a new language to get out of your comfort zone is a good idea.
I've heard this idea on other podcasts and read about it as well. The idea being that if you're a Windows guy working in .Net you should try running Linux and play around with Python, Perl, Ruby on Rails, etc. To that end, I set up my home computer to dual boot Windows and Ubuntu. I installed MonoDevelop and eventually plan on learning IronPython (since it works with .Net in Visual Studio) and F#. I'm also considering eventually taking a look at Ruby on Rails, Lisp and Smalltalk.

I'm going to start by downloading and reading code from one of those projects, it sounds like that's where it's at.

What do you guys think?

Good Taste

In episode #222 "Art is Shipping", Scott Hanselman interviews Jin Yang, the lead designer for StackOverflow.
In this podcast Jin Yang mentions a couple things that I found really interesting:
The first was that a well designed site should evoke a feeling from it's users.
I had never considered this, but it makes a lot of sense. Imagine you have a site where you want your users to donate money for some worthy cause, you might design the site to evoke a feeling of compassion so that your visitors will be inclined to donate more.
The second was that good taste can be developed.
This got me to thinking "what is good taste?".  According to Immanuel Kant, it comes down to a judgement based on a subjective feeling. Well, if that's the case, how do you get better at it?

Scott links a number of design blogs in the notes for the show, perhaps the anwer is to check out the blogs, see what others are doing, and take from that the things that appeal to you.
I've found that I'm a big fan of minimalist art, a style that Apple has been really good at.

What do you guys think? What is good taste and how do you recognize it?

Are you a Cargo Cult Programmer?

Jesper and I have been doing a lot of learning lately. We're both learning C#, and in doing so, reading a lot of books,  blog posts, and other resources.

Specifically, we've had several discussions about the book CLR Via C#. This book goes into great depth about how C# works, and some depth on how best to use C#. This is the type of book to read when you want to know why to solve a problem a certain way, instead of just solving it that way because, you found some code online, and it seems to work. The goal is to really understand why, not just how. There is a reason they teach math in school. They could have just given us a calculator our first day of first grade. Why didn't they? Its important to know the why.

Anyway, while reading a book review on Jon Skeet's website, I ran across the concept of a "Cargo Cult Programmer." I was intrigued. I followed Jon's link to the  original blog post which explained the concept. A Cargo Cult Programmer is someone who just cares about how, and not why. I have been guilty of this in my career but I strive to improve and this is one place I'm working hardest.

Anyway, I thought that Cargo Cult Programmer blog post was a good read so I thought I'd share.

More Helpful .NET Websites

I'm still learning .NET while working on my current project at work. I'm using Silverlight and learning .NET and specifically C# and XAML to support that end. I've recently run across two really helpful sites and thought I'd share them here.

A colleague showed me  101 LINQ Examples which is a nice site from Microsoft that shows LINQ examples from simple to hard. I have found this useful.

The next link, Parameter Passing in C#, is an excellent article on how parameters work in C#. This information explains details about passing value or reference types by reference or value. It was here that I learned about the ref keyword which is pretty damn cool.

I hope you find this usefull.
-Marshall