10 Papers Every Programmer Should Read

I’m always on the lookout for good reading material.  Michael Feathers over at ObjectMentor has served up a great post entitled 10 Papers Every Programmer Should Read.  I intend to.

Now, Discover Your Strengths

This is the title of the follow-up to First, Break All the Rules by Marcus Buckingham.  The first book was brilliant and really challenged the way we think about what makes someone successful at their job.  Now, Discover Your Strengths attempts to follow up on that with an in-depth discussion of “strengths.”  Strengths are a combination of knowledge, skills, and what the authors call talents.  A talent is “any recurring pattern of thought, feeling, or behavior that can be productively applied.”  Basically, it is your innate ability to do something.  If you aren’t born with a talent for, say, public speaking, no amount of training will make you Steve Jobs.  If you don’t have a talent for abstract thinking, you’ll never make a great programmer.  Sure, you can become competent at either, but you’ll never make it into the elite of your career discipline.

This sounds about right, but the authors don’t do a lot in this book to justify the position.  There is some talk about the way our brains develop neural pathways.  This may be the reason but the evidence in the book is not sufficient to really make the case.

The core of the book revolves around the premise that you will become much better if you focus on your areas where you have talents (these are your strengths) than if you spend a lot of energy trying to remove your weaknesses.  There is a lot of good anecdotal evidence for this in the stories of Tiger Woods, Cole Porter, and others. 

Unfortunately, the book spends a lot of time on StrengthFinder which is a questionnaire consisting of 180 questions, the answers to which will reveal which of the 34 identified strengths you possess.  The questions felt a lot like those you would find on a Meyers-Briggs test.  With the purchase of the book you can take the quiz once.  It will then tell you what your top 5 strengths are.  I was unimpressed with the test.  While Meyers-Briggs usually aligns well with how I view myself, this one didn’t.  It had elements I think are pretty far from my strengths and didn’t have things I think are.  Either I have a very wrong view of myself or the test is flawed at least in my case.  I suspect the latter.  Maybe I wasn’t able to understand what the questions were asking well enough.  There were several that could be interpreted in very different ways.  Whether or not the test is accurate, the information about the strengths themselves is paltry.  Each gets about a paragraph describing it and a page telling managers how to deal with someone who has it.  I’d like to see a lot more discussion for the individual what to do with their strengths.  This was almost wholly lacking.

The end of the book asserted the case that organizations should focus on strengths instead of skills.  An example of this is hiring for strengths and not specific knowledge or skills.  This may be a good idea, but I don’t feel the case was made strongly enough.  It was more assumed to be true than truly justified.  Even if true, it will be very hard to implement.  Should an organization make each interviewee take a test before being hired?  I’m sure the owners of the test would love that, but it sounds impractical.  It also ignores the ramp-up time someone with only strengths and no present skills takes to become productive.

The overall theme of the book—to pay attention to strengths and not weaknesses—seems right.  I’m persuaded that this is true, but more because of preconceived notions than because of the book.  The follow-through seemed weak.  This is disappointing because the first book in the series was truly eye-opening and much better justified.  Overall, I can’t recommend this book.  Borrow it from the library and read the relevant portions in a day or two. 

Check Out Stack Overflow

I’ve recently become quite addicted to the website stackoverflow.com.  It is a joint venture between Jeff Atwood and Joel Spolsky.  There is an accompanying podcast if you want to hear about the creation process.  The site itself is a question and answer site for programming questions.  Want to know how to do a simple Perl hash equivalency comparison?  Ask.  Want to find the best book on C# for experienced programmers?  Ask.  There is quite an active community and most questions are answered in short order.  You don’t even have to sign up to ask your first question.

If you want to stick around longer than one question, you can answer questions and earn reputation for doing so.  Greater reputation means more abilities on the site.  At one level you can change the tags on questions.  At another level you can vote to close questions.  Still more reputation and you can actually edit the text of questions.  Reputation is granted by users voting for the best answers and questions.  It’s amazing how addicting it can be to try to raise an arbitrary score.

The site has only been open for  a few months and already it is a treasure trove of knowledge.  Joel recently stated that the site gets something like 2 million uniques a month.  As I write this, there are approximately 90,000 questions that have been asked.  Almost all have answers.  This is crowd sourcing at is best.  Once people start linking to it in large numbers, expect to see it shoot up the rankings of programming-related searches.

There are downsides to Stackoverflow’s popularity.  Questions don’t stay on the front page for long.  I suspect they will have to create sub-pages for different topic areas the way Reddit did with its subreddits.

Why We Conduct Bug Bashes

My team recently finished what we call a “bug bash.”  That is, a period of time where we tell all of the test developers to put down their compilers and simply play with the product.  Usually a bug bash lasts a few days.  This particular one was 2 days long.  We often make a competition out of it and track bug opened numbers across the team with bragging rights or even prizes for those who come out on the top of the list.

Bug bashes are a time when everyone on the team is asked to spend all of their time conducting exploratory testing.  Sometimes managers will influence the direction by assigning people end-user scenarios or features to look at.  Other times the team is just let go and told to explore wherever they desire.  Experience has shown me that some direction can be good.  Assigning people to explore an area they don’t usually work on gets new eyes on the product and with new eyes come new use patterns and new bugs.  Recently I’ve also discovered that it can be helpful to track where people have spent their time.  During our last bug bash we created a list of areas that should be explored and had people sign off when they had investigated them.  This gives us a much better sense of just what the coverage looked like and allows us to ensure all areas received attention.

Conducting a bug bash can be expensive.  There is a lot of work to get done and putting everything else aside for 2 days adds up to a lot of other work getting pushed off.  Why do we do this?  What is the return on the investment?  There are three primary reasons that come to mind:

We have found that empirically, a bug bash flushes out a lot of bugs in a short period of time.  Our most recent bug bash saw the number of bugs opened jump to 400% of the daily average.  This is important because we frontload the finding of the bugs.  The earlier we know about bugs, the more likely we are to be able to fix them.  Knowing about more bugs also helps us make more informed triage decisions.

The second reason we conduct bug bashes is because they are likely to find bugs on the seams.  Test automation can only find certain kinds of bugs.  Exploratory testing is a much better way to find issues on the seams—where functional units join up.  Sometimes these bugs are the most critical.  Imagine if we could have found the Win7 MP3 bug or the interaction between playing audio and network throughput before shipping the respective products.  These are the sort of issues highly unlikely to be found in test automation but which can be found through exploratory testing.  We obviously don’t find all such issues through bug bashes, but we do find a lot.

The final reason we run bug bashes is to get a sense of the product.  Most of the time we spend our days focused on one small part of the operating system or another.  It’s hard to get a sense for the state of the forest while staring at individual trees.  After spending several days conducting exploratory tests on the product, we can get a much better sense whether the overall product is doing well or if there are serious issues.

Managing Humans

I just finished reading Managing Humans by Michael Lopp, aka Rands in Repose.  Michael is a 15-year veteran manager from Silicon Valley.  He’s worked for such notable companies as Netscape and Borland.  He has a lot of good advice based on this experience.  The book is a compilation of blog posts so you can probably get by without buying it if you really want to.  However, there is a lot of good stuff in here and having a copy to mark up is handy.

If I have something negative to say about the book, it is that it doesn’t have a well defined audience.  Despite the title, the book isn’t all aimed at managers.  Some of the book is telling managers how to think.  Some is telling employees what their managers are thinking.  Still others are aimed at those starting a company.  A 4th audience is those trying to land a job and going through the interview process.  Each of these sections have good essays dedicated to them, but it also ensure there will be essays that are useless to everyone reading the book.

The best essays cover the subjects of meetings and employees. 

On meetings, Michael dedicates several essays to the sort of people you’ll find in meetings and how to help those meetings succeed.  He also gives advice about how to determine a meeting is doomed so you can leave.

On employees, he explains the concept of the “free electron” which is that rare super programmer and how to keep them happy.  He talks about analyzing poor performance and then acting on it.  One great tip is determining what the real problem is by creating a 2x2 grid comparing motivation and skill.  In a point that hit home with me, Michael pointed out that sometimes what appears to be a motivation issue can really be a skills issue.  Someone who once had great skills but who has been coasting on past accomplishments may have low motivation because their skills have atrophied.  In this case, skills training may be the solution to the motivation issues.

If you are managing a team, read this book.  If you want to understand what your manager is likely thinking, read this book.

One more note, the writing style is very irreverent.  If you are easily offended, you may find yourself wincing at times.