Finding differences will help you make sense of your code.
We’re fairly good at spotting things that are different. But how good are you at thinking of different ways that something can be similar or different? That’s an important skill you need to develop in order to become a better programmer.
Listen to the full episode or read the full transcript below for examples. And if you’d like to participate in programming sessions where I work through issues like what I described in this episode, you can become a patron of the podcast and select your reward level.
Transcript
Differences will creep into your code as you think of new things it needs to do. It happens to all of us. And if you don’t recognize them, the differences will turn your code into a jumbled mess.
There can be different ways to think about things so you have to examine your code from different viewpoints to find things that are similar and things that are different.
There’s a popular children’s show called Sesame Street that sometimes shows a game called “One of these things is not like the others.” At least that what I think it’s called. It’s been a while since I watched it. You have four pictures and need to figure out which one is not like the others. Let’s say there’s a picture of a baseball, a man, a bird, and a bat. Which one is not like the others?
Most kids will choose the baseball because all the others are pictures of living things while the baseball is not alive. But this is where you can develop your programming skills by thinking of other ways that things are alike.
Maybe you said the man is not like the others because the others start with the letter b. This is accurate but not the best programming reason because names don’t usually define behavior. Look for differences in behavior more than other things.
Maybe man could be different than the others because all the others fly. But does a baseball really fly? Not really, it gets thrown instead. And while it’s not that easy to toss a man, it can be done.
You could think about the baseball being unlike the others because the others can move on their own. That’s similar to being alive. It would make more sense though if the bird was replaced with a picture of a motor.
The point is that you can sometimes find multiple similarities and differences. These will change how you think about your code and will affect your design.
Getting to the right level of similarities will allow you to solve basic problems once and then reuse that solution in other parts of your code. Then you can focus on just the new differences and not worry about things you’ve already figured out.
Think for a moment about our bodies. We’re made up of various organs and systems. Is our skin similar or different than our arm muscles? They seem very different but actually contain a lot in common.
If you were programming something like this, you might start out with different classes for skin and muscle since they seem so different. But eventually, you’ll realize that both need food and oxygen and the ability to grow. This is where you can start going down the wrong path if you don’t recognize the similarities.
All of our organs are made of cells that are specialized but actually very similar. Even plants are made of plant cells. The cells all perform the same basic functions but can be adapted slightly for skin, muscle, bone, etc. They all have the ability to absorb nutrients through the cell wall and divide and grow.
This is where you can benefit by writing code that does the common functionality once and reusing it in all the different places that need it.
As an another example, consider the game that I’m working on. I wanted a configuration file to hold some of the data that defines the basic behavior and settings of the game.
The configuration file uses properties that each have a name and a value. That’s already making things similar. Whether controlling how many zoom levels the game will have or whether a particular piece of the map will be filled with grass or trees, these things might seem very different. They can all be expressed with a property name and a value though.
When I first started programming this, I wanted different types of values. Numbers are different than strings. And then I needed some properties to have multiple values. For example, I wanted to express the idea that a beehive could be found in either a tree or a log. That property needs two values. So I added another type of for an array of values.
I eventually realized that while these types do eventually need to be separate, as far as the configuration file is concerned, why not make all the values strings. Then what about single values vs. multiple values?
If you have a bag, do you have to always put two or more things inside the bag? Why can’t the bag hold a single item as easy as it can hold two? So I decided to give all property values the ability to hold multiple values. They were suddenly all the same. They were all strings that could have one or more values.
This is the type of thinking that you need to put into your programming. You adapt and change your code as you write more and discover more similarities.
The lessons we learned as young children come back to us and this time can help you become a better programmer.