Last November Ivett invited me to participate at her Lean Poker event. I was a bit skeptic, as I stopped learning in my free time long ago. There is nothing wrong with learning in your free time, I just re-prioritized my life. In other words, I was sure that I was going to learn something, I just wasn’t sure it was going to be worth my time.
Spoiler: It was.
It was also company time.
I’ll explain briefly what Lean Poker is and what I learned. As Lean Poker is an event to practice, i.e. not frontal learning, you might learn something else.
So, what is Lean Poker? It is a competitive game where teams develop Poker Agents, and then those Poker Agents play against each other, using a well-defined network protocol. Easy to say, not so easy to do. Here are the things that we had to do:
- Figure out how to collaborate (online)
- Make sure that our Poker Agent is always functional, otherwise we’d loose in every round
- Learn the details of the Texas Hold’em Poker
- Learn the API of the common protocol
- Follow state of the game, read the logs and figure out how to enhance our Poker Agent in small increments
This is a lot, and we only had 2×4 hours for this. Actually, I was sick on the second day, so I only got 1×4 hours. During this 1×4 hours we did all the stuff above. I believe, the rest of the team went on doing this.
So here are my highlights from the event:
Figuring out how to collaborate
Compared to my day-to-day development tasks, this was a fast-paced event. We found that creating a git workflow with review and whatnot would use too much time. Instead we decided to do mob programming:
- one person is writing the code, they are responsible for writing code that compiles
- everybody else gives advice, that can be either low level (this is complex enough, let’s write some tests) and strategical (let’s change the bidding algorithm)
So I got some experience with Mob Programming. Not applicable at my work right now, but if we’ll need to collaborate more closely, this is one good way to do it.
Making sure that the Poker Agent is always functional
We did a deploy-to-prod approach and looked at the logs. In some businesses this is OK, in some others it isn’t. I haven’t done anything like this in my career. I was a bit scared, but things were all right.
What I learned: testing in PROD can be OK – as long as the losses for a mistake are tolerable, you do watch the logs, and you have sufficient logging statements in your code.
Learn the API of the common protocol
Well, actually, we didn’t do that. Copilot did.
I am skeptic about AI generated code. However, I saw some good use-cases here. Copilot generated code for this API, so the learning curve was short. This is a clear win.
Copilot generated okay-ish code, based on the method names. This also helped us to deliver stuff quickly. That code was a little too verbose, and didn’t always work properly. We had to test it (that is always a good idea anyway), in a real-life scenario I would’ve cleaned it up before sending for review.
Instead of this craftsmanship, we had a generate-and-throw-away approach: in case the generated code wasn’t good enough, we tweaked a little, and the Copilot came up with new, better suggestions.
What I learned: Copilot can speed up some phases of programming.
tamasrev 