So here is where I begin to report the little lessons I learn while studying to be a programmer.
This first post is not so fresh in my mind – I’m describing something I worked on roughly a month ago as an exercise in Zelle’s book. But my notes are pretty clear.
The project was pretty simple: choose a card game, design a program in python for playing it, use a simple gui (I used a modification of Tkinter supplied by Zelle), include a splash screen. It was an extensive practice in object-oriented design – so the point was to make good use of classes. (For those who don’t know, OOD is essentially writing chunks of code that can be recalled by a name so you can play around with sticking big chunks of code together like legos instead of writing line after line of the same little details over and over.)
And I did make good use of classes. With one big mistake.
So for those familiar with Blackjack, you have a few actions you can choose from each turn. Mostly, that’s going to be hitting (getting a new card) or standing (ending your turn). Most of blackjack consists of these two things. Because most of the game is these two things, I wrote the program around them. I thought about the other options for only a second. I only thought about doubling down, which is a special kind of hitting and standing that effects your wager, and nothing else. So, no problem.
Except there’s this other important aspect of the game: splitting. I thought I could just “cram it in” like doubling down. No need to spend too much time figuring it out.
This was the mistake. You see, splitting requires you to play with two hands (at least four cards). I had enough forsight to leave enough room in the gui for two hands. So that worked out. There is a minor problem there, because sometimes you can split a split hand (depending on house rules), which means I would need to set up for three hands. I decided it was not worth thinking about. This was just an exercise in a textbook, it needed to be very good, with a lot of effort put in, but not perfect. I decided this house would allow only one split. Fine.
The problem was in coding. It became a nightmare, figuring out how to redesign the program to get input from the user when it was a split. I won’t go into the details. I will say that I spent about 8 hours working on this, and at least 4 of them were trying to get splits to work.
What was the problem? I discounted splits because they are not normal. They occur maybe 5% of the time, at most. I made the mistake of thinking that, since this happened 5% of the time, it warranted 5% of my attention. It warranted more, and it got its attention with a vengeance.
How could I have done better? Spent time mapping out options and observing patterns. I thought that, since I understand blackjack pretty well, and I even coded a primitive version of the same thing a few weeks prior, I could just breeze through. What I didn’t realize was how object oriented programming requires you to step up your planning efforts. You need to spend the time figuring out just what is an object – just what are the essential components of the program – and exactly how everything fits together.
If I had planned this game out, taken the time to map everything in a flow chart or something similar, I would have realized that it would have been easier to make a “normal” hand a simpler version of a “split” hand than it was to make a “split” hand a more complicated version of a “normal” hand. I should have expanded my definition of what a hand is to include a split hand. What I was doing was kind of looking at a split hand as an afterthought – a particular tweaking of a normal hand – and therefore not worth thinking about too much until I got to it.
A more general definition of a hand, based on a more careful perspective, would have allowed me to include the shared characteristics of both normal and split hands, saving me the step of redesigning everything towards the end of the process and making the whole process faster and easier.
You’re probably detecting a kind of moral lesson out of this. And I think there definitely is one. In any situation, it’s better to accept all cases and account for them – whether its at home, in politics, in your day to day affairs of life – than it is to marginalize. If you want to see beauty and some kind of order in your life, you have to make sure you are making relevant distinctions. If not, you risk either rejecting something valuable or neglecting something significant.
See, programming has a lot to teach. More to come.
Needful Question 