Programming is hard

There is a phrase that my friend Tan used to always said when we would pair. Programming is hard. Most of the times we said it to troll each other. We would say it after we would spell initialize wrong for the umpteen time, or type in rails c to try and start up a new rails server. Sometimes we would utter those words and actually mean it, like in these cases…

How do I test for a call to an external service?

How do I build my own gem?

How do I implement minimax in tic tac toe?!(current problem I’m struggling with)

What the real question is how do I fix a problem where I only have a vague idea where to start? Or how do I break down a big problem into its smaller parts?


One thing that can be helpful in breaking down a big problem is writing pseudocode. Pseudocode means trying to use plain english words to solve a problem. Fantasy football is a pretty good example to use, it seems like an easy problem on the surface. Simply just play the players that are going to score you the most points. But how do we achieve that goal? Pseudo code for our optimizing lineup might look something like this

# To build the best lineup
# I will play the players projected to score the most points
# The players that score the most points are the ones that play on the best offenses
# And will score more if they play bad defenses
# And will score less if they have an injury

Each of these lines could be further broken down to its own pseudocode, for instance in what ways does and injury effect a players performance?

#Players will score no ponits if they don't play
#Players score will be significantly less if they are listed as doubtful
#Players score will only be slightly effected if they are listed as probable


One of the great things about unit testing is we can take an approach where we are looking to test the smallest thing possible, that fits within the scope of our big problem. This helps narrow our focus and we can build on each of these small solutions.

One good rule is to pick the easiest case possible for what we are trying to test for. Lets say we are working with the scenario of injuries and how to reduce a players points accordingly.

(describe "point-reduction"
(it "reduces a players points because of injury"
(should= 0
(point-reduction "Tom Brady" "Out")

That is what our test might look like. We expect a score of zero from a player that is expected to be out. Then we write the code that will make that pass.

Look we’ve gone from having a big problem and solving one small part of it, but what testing often does is helps us narrow our focus, and get the ball rolling when it comes to actually solving our problem.

I know one of my own flaws I have, along with many other programmers out there is trying to solve a big problem all at once. Take a step back, breath, and think about how you can break something down into smaller problems that you can solve.