One of the first catch phrases I heard when learning to program was “Garbage in, garbage out”.
This refers in computer science to the fact that 
computers will often accept incorrect and even incomprehensible data and produce undesired, often meaningless output.
People will drive miles away to get gas from a preferred station for their car. However, when we need a snack we grab the most convenient, often more expensive, usually unhealthy choice of ‘food’. Surely we don’t think more of our cars then we do of our own bodies?
All our bodies have to work with is what we put into them. How can we eat better? In software development we often ask ourselves how we can code better. One of the best solutions is to right tests before you right the code. This is a practice from eXtreme Programming called Test Driven Development or known more commonly by it’s abbreviation TDD.
TDD teaches us to first write a small failing test. Secondly we do the minimum to make the test pass. Thirdly we refactor, which involves removing duplication and organizing the code. This third step gives us an opportunity to reflect on our approach to passing the tests. We then repeat the process continually until we are satisfied.
If we feed ourselves with less then ideal food we will not perform to our maximum potential.
One important part of improving our code is to make small, sustainable changes, not large changes. Large changes can create instability, something that is very much undesired in software and in our bodies.
I’m going to write a very simple test that involves one of the most famous snacks of all time, the hamburger. Yes, I am writing about a hamburger. It might not be what you think as my hamburger has already been through a few ‘improvements’. For example, I don’t eat bread with my hamburger and am very happy to see that many restaurants are now offering a leaf of lettuce on either side to substitute for the bun. My burgers are also full of spinach and onions and no fillers like bread crumbs.
Ok. I need a new test that will improve my hamburger. My main concerns are nutrition and taste.
The name for the test is test_is_burger_made_with_grass_fed_beef
Kind of a funny name when you think about it. If the world made sense the test should be called test_is_burger_not_made_with_corn_or_soy_or_something_else_that_cows_dont_normally_eat but we will go with the current standard so there is no confusion. FYI, corn is fed to cows to fatten them up so they can sell for more money (increased weight). It marbles the meat which people associate to better taste. I disagree. Grass fed beef tastes better and is much better for you. Please do not take my word for it. Go and buy some grass fed beef or even do a taste test. (hmmm…future article on A/B testing?).
Back to our Food TDD. We have our new test which fails since the ground beef I have is not grass fed. Yeah, failing test!
Second step, I find a store and buy some grass fed beef for my burger. I don’t eat burgers very often so I don’t mind paying a bit more for them. It makes the treat even more enjoyable and special. Then I make the burgers and eat them. I have two burgers since they are so good.
Finally, TDD tells us to refactor. In cooking I look at any wasted steps or ways to improve the process. I find one. I made a critically error. I actually wrote three steps at once. I also wrote these tests:
does_burger_topping_include_red_swiss_chard and does_burger_topping_include_goat_cheese
My burger tasted great but the goat cheese didn’t quite work and I’m not sure about the red swiss chard which looked great but was over powered by the goat cheese. I’ll have to make them again and this time just make one change at a time to see if it improves the recipe. To focus on grass fed burger, it tasted amazing and I feel good knowing I put better quality food into my system.
This is a very simple concept but if you want to improve your code or yourself you need to reduce your feedback cycles so you can learn whether a change is making things better or not. Each of these changes need to be done with quality. Anything done poorly will have poor results.
If “Garbage in, garbage out” happens then let’s do what we can for both our bodies and our code and put quality into everything we do.
HumanRefactor 