Article: Software Development Lessons Learned from Poker

There is no silver bullet. We know it, but don’t act like it. Your language, tool or process is better, right? In this article, Jay Fields says: “It depends”. The right choices varies with context, people, and more. This article touches upon how a lot of things must impact a choice; learning culture, skill levels, teamwork, incomplete information, metrics - and context.

As a framework for discussion, Jay makes comparisons on these topics with his former career - as a professional poker player. From the article:

One thing is absolutely true about both poker and programming: almost no one is as good as they think they are. Knowing that you aren’t as good as you think you are is a good first step, but it’s hard to know how much better the experts are. Programmers are rarely exposed to enough experts to fairly judge their own skill level. At the poker table everyone gets together for tournaments, but I’m always very surprised by how highly most people rate their abilities.

I am a bad poker player, and a possibly overvaluated IT professional. And somehow I am using poker as a replacement fon negotiation training (which from now on will include serving heavy drinks to my opponentes).A couple of issues really hit the target, like "you can't claim you are an expert if you never met a real one..." and the fact that there are metrics hat matters and other that don't. Also, poker has a "lifecycle" which makes you play very differently at the beginning an at the end.

Unfortunately, in software development one has not so many chances to "fold" as it happens on thepoker table, and this is probabily the biggest and saddest difference. :-(

There are good observations and life experiences taken down in this article ("Reading material is great for learning, but it's almost always the context that determines when to apply a certain technique."), but as a whole I find the comparison of poker and sw development rather worthless. In fact the same theses apply for dozens of other activities or jobs ("Reading material is great for learning, but it's almost always the context that determines when to apply a certain technique.") and are not exceptional for sw development or poker.

The best poker players implicitly team up with one another because they know "you make [money] by playing with [good players] to take it from those who are not". That doesn't sound exactly like a highly collaborative enviroment to me.

Expert developers collaborate "with other expert developers, [...] managers, customers, business, analysts, quality assurance, and any individual who can contribute to their success". I think they should collaborate with anyone who can contribute to the success of the team or the project, and that usually includes less expert developers as well.

Maybe my point of view is different just because I used to play rugby rather than poker? :-)