Tales from the jar side:
Welcome to Tales from the jar side, the Kousen IT newsletter, for the week of June 9 - 16, 2019. This week I spent a fair amount of time digging into one of the most famous problems in Game Theory, known as the Iterated Prisoner's Dilemma (IPD). The goal is to take the so-called "Tit for Tat" (TFT) solution to the IPD problem and apply to the employee/manager relationship.
The Iterated Prisoner's Dilemma Problem
I've actually been talking about that for years, as part of my regular Managing Your Manager presentations. Now that I'm writing a book on the subject, I needed to dig into the theory behind IPD a bit more deeply. Fortunately, most of the information I needed can be found in this Wikipedia article.
The detailed discussion will be in the book, but I can summarize the ideas here. First, the prisoner's dilemma is a classic problem that says two criminals are captured and accused of the same crime, but interrogated separately. If both stay silent (they cooperate with each other), each serves one year. If both tell on each other (they defect), they each serve two years. If one cooperates and the other defects, the defector goes free and the cooperator serves three years. In matrix form, the rewards look like this:
| | B Cooperates | B Defects | | A Cooperates | -1, -1 | -3, 0 | | A Defects | 0, -3 | -2, -2 | The pairs are the results for A and B. So looking a the result when A defects and B cooperates, (0, -3) means A goes free and B serves 3 years.
If you only play the game once, determining the correct move is easy. Say A is trying to decide whether to cooperate or defect. The reasoning goes like this: "If B cooperates, I can go free by defecting. If B defects, I better also defect to minimize my losses. Therefore, I have to defect." Of course, B will reason the same way, since the rewards are symmetrical.
That's an illustration of what's known as a Nash equilibrium, by the way, which comes up in the movie A Beautiful Mind. Each person chooses an action that minimizes their losses based on whatever the other player chooses.
The game becomes much more interesting if it's played repeatedly an unknown number of times*. That's the "iterated" part of the Iterated Prisoner's Dilemma. Now the goal now is to try different strategies based on what your opponent does over time.
*If the number of repetitions is known, then each player should defect the last time, since that's a one-time game. Working backwards, that means they should defect the next-to-last time, and the time before that, and so on.
The repetitions change everything, because if you burn your opponent and see them again, they're going to take that into account. The seminal work in this area is a book called The Evolution of Cooperation, written by Robert Axelrod in 1984. Axelrod described the results of a computer tournament he organized where competitors tried all sorts of strategies to win a round-robin IPD game. The tournament was won by a trivial little program (four lines of BASIC, believe it or not), called Tit for Tat (TFT).
The TFT strategy is:
1. Cooperate on the first move
2. Echo what your opponent did each move afterward
So if your opponent defected, you defect, but if the opponent then switches to cooperation, you cooperate. This turns out to be an extremely productive strategy, because (1) it favors cooperation (all the successful strategies are "nice", meaning they start off by cooperating), (2) it retaliates immediately, and (3) it forgives immediately as well.
Translating this to the employee/manager relationship suggests that you start off cooperating with the boss, but when they make a decision that goes against your interests, you confront them about it, then negotiate a resolution (if possible), and then let it go.
It may not get you what you want, but the real goal is to train your manager to take your priorities into account when making decisions that affect you. Most employees feel that when their faced with a conflict with a manager, their only choices are to either go along or to leave. The TFT strategy gives them an intermediate approach to follow that forces the manager to be more aware of your interests. That way either they will either start to accommodate you, or they won't, and if they persistently won't at least you'll know it's time to leave.
There are alternative IPD strategies and I describe the game and how to use it in a lot more detail in the book. If you find this interesting and want to play with a nice (free) online simulator, my favorite one is at https://ncase.me/trust/ (note: it plays music, so you might want to turn the sound down on your system before you go there).
As a personal note, I should mention that while applications of the IPD game and the TFT strategy appear everywhere, I've never seen it applied to the employee/manager relationship. That appears to be mine. So I'm simultaneously proud about that and nervous that I'm completely wrong somehow. My own experience suggests that it works, at least within certain boundaries, but that's the epitome of anecdotal evidence. I'll be very interested to see how it plays out once the book is widely available.
I guess that means I really do have to finish it. :)
Kotlin Cookbook Update
Speaking of works in progress, I also spent time on my Kotlin Cookbook this week. We're preparing a new update to go out to the Safari subscribers. In the previous updates, I've added a new chapter each time, and I want to do that again. This time, however, the name of that chapter is going to be "Miscellaneous", because that's where I've been stuffing recipes that will eventually be filed somewhere else but don't have an obvious home yet.
The Miscellaneous chapter currently includes:
Getting the Kotlin version
Forcing when to be exhaustive
Measuring elapsed time
Forcing completion with TODO
Executing a lambda repeated
Much ado about Nothing
among others, and yes, that last title was inevitable, as was my including the You know Nothing, Jon Snow quote in it. :) I have to clean them up a bit and decide how many to release, choosing among these and a few others I didn't mention. I also have taken to writing a brief introduction to each release explaining what's new and different this time.
I did spend some time digging into functional programming beyond the basics of map/filter/reduce, which means I'm finally going to have to figure out what monads really are. My favorite quote about them comes from the Monad Tutorial section in the Arrow documentation (Arrow is a library for functional programming in Kotlin):
"The monadic curse is that once someone learns what monads are and how to use them, they lose the ability to explain them to other people."
For me, that tutorial fits the description. I made it about halfway through, before it started referring to Arrow-specific types and classes and I got lost. Oh well. I'll have to try again soon. I am planning a chapter on functional programming for the book, and it would be nice to understand more than I currently do when I write it.
The risk, of course, is that when I finally do figure out the monad stuff, I won't be able to explain it either.
A few miscellaneous items
First, I spent some time talking to a new client about their "bootcamp" approach to training new developers. The company holds a twelve-week program to take career changers from nothing to productive in software development, teaching from 8 am to 5 pm every day. I'm normally skeptical of programs like that, but I do like the idea.
In this particular case, I met one of the organizers and a couple of the students when I did a Kotlin talk at the Connecticut Java Users Group last month. I talked to them a couple of times recently about helping out, mostly as a guest lecturer on specific topics, because I certainly don't have twelve consecutive weeks free in my calendar. Besides, they couldn't afford me. :)
I do like the idea of talking to local students about specific topics and helping them on their way. If I can commit a few days here and there to it, I'll definitely try. The downside to all these online classes I'm teaching at O'Reilly is that you don't have the same face-to-face contact with the students. Plus it would be nice not to have quite so many eggs in the O'Reilly basket.
Second, the No Fluff Just Stuff season starts up again this week. I have trips planned for the events in Columbus, OH and Dallas, TX soon. It will be nice to see everyone again, but a bit sad. One of the long time speakers, Matt Stine, announced he was taking a high-level architecture job at major bank, and they don't allow you to earn income from any outside sources. That strikes me as very short-sighted, but they are in a heavily regulated industry so who knows? Anyway, Matt's last event is the one in Columbus, so that will be the last time I see him for a while.
Third, this week the Connecticut Java Users Group is having another NFJS speaker, Michael Carducci, but at a new location down near New Haven. That's a bit of a hike for me, especially with traffic, but I'll try to make it.
Finally, my wife and I finally finished watching all the episodes of Star Trek: Deep Space Nine on Netflix. We'd been plugging away at them one or two a night, and reached the finale this week. It's much better than I remembered, but it's still no Babylon 5. (Reminder: all five Babylon 5 seasons are available on Amazon Prime.)
My friend John Paxton still claims he would take Ben Sisko over Jean-Luc Picard, and while I can appreciate Sisko's talents and abilities, that's frankly ridiculous. I like my friend and respect him (or I used to before he said that), but now I question his sanity a bit.
Last week:
Lots of Iterated Prisoners Dilemma work for Managing Your Manager
Wrote a couple more recipes for Kotlin Cookbook
Other discussions with a new training company
Next week:
Basic Android course on Safari
Mockito / Hamcrest course on Safari
Kotlin Fundamentals course on Safari
Connecticut Java Users Group meeting in New Haven
NFJS event in Columbus, OH over the weekend