Programmer Musings

Review of Smart & Gets Things Done

Smart & Gets Things Done
Joel Spolsky
Apress, 2007

This book represents Joel Spolsky's approach to hiring programmers. Smart & Gets Things Done is based on Spolsky's weblog, like his previous book, Joel on Software. In this book, Joel brings together his various writings on hiring software developers. Not surprisingly, Joel bucks traditional wisdom on the subject by stating that you should be hiring only the best and ignoring all of the rest.

Now, many companies will publicly agree that you should always hire the best. They may even post slogans or motivational posters saying that We only hire the best. Joel takes a different approach. He honestly suggests that if you can't find the best, you are better off continuing to search than to hire someone who is less than the best. Although he doesn't say it explicitly, the text does hint at the fact that the best for his company may not be the best for your company. However, he does pretty much ignore the whole do they have the right keywords approach to hiring.

Joel mostly focuses on his view of what the best looks like, how to convince them to work at his company, and how to keep them once they are in the door. A lot of what he says will look wonderful to most software developers. I suspect that many hiring managers and human resources people will hate his advice. As someone who develops software for a living and who has been part of the hiring process with a handful of companies (large and small), I think Joel's ideas have some merit. I'm not sure I can agree wholeheartedly with everything he says in the book. Amusingly enough, I think the spots where I disagree are probably very different from where a manager or HR person would disagree.

All in all, the book is a quick read. Joel's writing style is always clear and readable. He brings up a number of interesting points, not all of which are on his weblog. In fact, it was a pleasant surprise to find that this was not just a re-edited version of articles from Joel's weblog. There is actually a bit of new material in there as well. Even without the new material, the book form may be easier to digest than getting this material from half a dozen scattered essays.

If you are involved in any way in hiring software development staff, you probably want to read this book. If you are looking for a job, this book might give you something to keep in mind while considering company offers. My only real complaint about the book was the fact that most of the material is already available on Joel's site, and I consider that to be a minor issue.

Programmers and Reading

What is it with programmers who don't read?

Most of the best programmers I know are constantly learning. They seem to have an insatiable curiosity for any topic they are interested in. These programmers are often reading websites, books, and magazines almost constantly to help extend their knowledge and understanding.

Others never seem to read anything. Some appear to believe that once they learned enough to get a job in the field that more learning was unnecessary. Now it's possible that some people really are that good, or that they work with people that are such experts that they can learn everything they will ever need just by asking.

I wasn't born that good, and I've never worked with people who really knew everything (although I have worked with one or two who thought they did). In order to get better at my craft, I read quite a bit. Looking elsewhere in this blog, you can see a number of books that I have reviewed. My collection of computer books is significantly larger than what I have written about. I also read a few computing/programming magazines and even a couple of websites.

I do this for several reasons. I want to improve. I want to see where others are taking the field. I want to be able to learn from other people's experience, so I don't have to make all of the mistakes myself.

A programmer I worked with a few years ago said he saw a study covering the number of computing books that programmers had, on average. The number floored me...zero. I have over two hundred computing books in my personal library. Over the years, I have culled the ones that are really no longer relevant. I really don't have a good idea of how many programming books I've read.

I just can't imagine how someone can be a programmer without this kind of resource.

Misleading error checking examples

I'm finally getting back to my blog after YAPC::NA. It's been a while since I wrote, so I figured I would start off easy.

Many months ago, I stumbled across yet another article describing how hard exceptions are (The Old New Thing : Cleaner, more elegant, and harder to recognize). It's an old article and I'm pretty sure I had read it before, but this time it struck a different cord for me.

The author carefully does not make the argument that exceptions are bad, he just states the getting exceptions right is harder that getting error-return checking right. His main argument boils down to the following two pieces of code:

NotifyIcon CreateNotifyIcon()

{

    NotifyIcon icon = new NotifyIcon();

    icon.Text = "Blah blah blah";

    icon.Visible = true;

    icon.Icon = new Icon(GetType(), "cool.ico");

    return icon;

}

NotifyIcon CreateNotifyIcon()

{

    NotifyIcon icon = new NotifyIcon();

    icon.Text = "Blah blah blah";

    icon.Icon = new Icon(GetType(), "cool.ico");

    icon.Visible = true;

    return icon;

}

The author states that the first is wrong and the second is right and this is subtle and hard to notice. He also uses a completely different example for showing good and bad error-checking code, where the mistakes are much more blatant. Several of the follow up comments take the author to task for flaws in his arguments and for specific details of the examples. My problem is that he did not do an accurate comparison. He compared apples to oranges.

Let's re-write these examples in the check error return style. I am going to modify this to be C++-specific, so that I can get the new operator not to throw an exception. I'll use RAII to simplify the memory management. Let's also assume that we want to return a null pointer on error.

Now, let's start with the bad code example:

NotifyIcon CreateNotifyIcon()

{

    std::auto_ptr icon( new(std::nothrow) NotifyIcon() );

    if(!icon)

    {

        return 0;

    }

    // Needed to add some error checking here for memory allocation

    if(!icon.SetText( "Blah blah blah" )

    {

        return 0;

    }

    icon.Visible = true;

    icon.Icon = new (std::nothrow) Icon(GetType(), "cool.ico");

    if(!icon.Icon)

    {

        return 0;

    }


    return icon.release();

}

The correct version of this code looks like this:

NotifyIcon CreateNotifyIcon()

{

    std::auto_ptr icon( new(std::nothrow) NotifyIcon() );

    if(!icon)

    {

        return 0;

    }

    // Needed to add some error checking here for memory allocation

    if(!icon.SetText( "Blah blah blah" )

    {

        return 0;

    }

    icon.Icon = new (std::nothrow) Icon(GetType(), "cool.ico");

    if(!icon.Icon)

    {

        return 0;

    }

    icon.Visible = true;


    return icon.release();

}

Once again the difference between the correct code and the bad code is one line moved a little. It may even be more subtle here due to the increase in number of lines of code.

Lest the Java people get the idea that this would be easier in Java, I'll recast the broken code in Java by handling the out of memory exception immediately.

NotifyIcon CreateNotifyIcon()

{

    NotifyIcon icon = null;

    try

    {

        icon = new NotifyIcon();

    }

    catch( java.lang.OutOfMemoryError e)

    {

        return null;

    }


    // Needed to add some error checking here for memory allocation

    if(!icon.SetText( "Blah blah blah" )

    {

        return null;

    }

    icon.Visible = true;

    try

    {

        icon.Icon = new Icon(GetType(), "cool.ico");

    }

    catch( java.lang.OutOfMemoryError e)

    {

        return null;

    }

    return icon;

}

To my eyes, the subtle logic error of setting the visible flag too soon is independent of the form of error recovery used. That example is a red herring that adds nothing to the debate.