Luck in Software Development, Part 1

Chess is a game that most people think is purely based on skill, unlike poker, which is probably seen more as a combination of skill and chance; i.e. the hand you're dealt. But I posit that chess can sometimes entail a facet of what poker is more traditionally known for, bluffing:

In the card game of poker, a bluff is a bet or raise made with a hand which is not thought to be the best hand. To bluff is to make such a bet. The objective of a bluff is to induce a fold by at least one opponent who holds a better hand.

I was playing chess by email once though I don't think the mode matters; what I did might have been equally applicable had we been playing "over the board." I'd had a significant advantage for a while but through some mistakes my advantage was definitely slipping away and would probably soon be much in my opponent's favor.

However I did see a trap I could set that, if my opponent fell for it, would end up in a winning position for myself. So not only did I set the trap on the chess board, but I also set a psychological trap at the same time, a sort of bluff...

I offered a draw on the very same move as setting the trap.

My opponent responded as quickly if not more so than to any of my previous moves, declining the draw of course, as the pendulum was swinging in his direction. But he fell for the trap too, and I think my offering a draw on the same move made this more likely.

So not only do I believe there can be a non-skill element to chess, but also to software development. I definitely experienced this in my very first professional position. It had nothing to do with anything akin to bluffing whatsoever, but rather was more along the lines of pure happenstance.

We had engaged a consultant for one day to come in and update our SCO Unix systems to a more recent version. He'd finished for the day in merely one hour but then at the same time I did something I'd of course been warned about in Unix classes I was taking at the local community college, but I thought I could get away with if I specified only certain files....

I did a recursive remove.

But of course I'd somehow not specified only particular files (this was nearly 20 years ago so I forget exactly what I did or did not specify) but rather clobbered a whole bunch of critical stuff bringing the systems to their knees. Luckily though the consultant was still there, and now actually had to earn his keep by undoing my damage over the course of most of the rest of the day.

And, as a first-time developer with mere months of professional experience I learned so much by watching over the consultant's shoulder. I remember in particular I learned about the find and exec commands for instance, though today I almost exclusively use find in conjunction with xargs.

And my manager was very understanding, saying that if I didn't make some sort of major mistake at that stage of my career, I wouldn't have been trying hard enough. Though I doubt he would have been quite so understanding had we not had the consultant on site.

Fast forward about ten years to when I was more of an intermediate developer verging on senior and I had another experience where a sort of luck came into play, but I will leave that for the next installment