Reference Code to Solve Problems

by Patrick Villanueva, Media Lab Assistant and Technology Instructor
November 13, 2020

Everybody in this country should learn how to program a computer, because it teaches you how to think. - Steve Jobs

Steve Jobs once said, "Everybody in this country should learn to program a computer, because it teaches you how to think." He didn't quite elaborate on that, but I wanted to explore it a bit further.

Of course, Steve Jobs was referring to computer programming. His quote made me think, and it piqued my interest. It made me explore why, and I just didn’t read about it. While working at a university, I took courses as a student but wasn't quite satisfied with them. So, when I learned about a new breed of coding camps, where they emphasized modern tools and practices, I took a leap of faith and jumped on the opportunity. 

Their curriculum was pretty intensive and grueling, which spanned 3 months. Days started early and ended late. You needed the discipline. We started with programming foundations in Ruby, moved on to web foundations with Ruby-based Sinatra and finished with Ruby on Rails. The goal was to ultimately give you a springboard upon completion. 

Looking at the big picture, programming is pretty cut and dry. You move from one point to the next, in a logical sequence. A recurring theme was: 1) make it work, 2) make it right and 3) make it fast. These were words of a well-known programmer by the name of Kent Beck. My interpretation of all this: In order to solve a given problem, you write the code to solve it, rewrite it to be as concise as possible, and then ensure that it's optimized for performance. 

Test-Driven Development 

Upon further practice as a Ruby on Rails Developer, I learned of a process called Test-Driven Development, which is called TDD for short. But I believe that's what Kent Beck was talking about, as he's credited for having developed or rediscovered the technique. TDD is a beautiful way of writing code and reminds me a bit about proofs from Geometry class. 

Heading into the class while in high school, I was warned that proofs were a pain. But after getting started with them, I never saw it that way. They turned out to be some of the more memorable math problems that I can remember, and it gave me the right kind of challenge to work through. As a refresher: in Geometric Proofs, you're given a problem to solve, but also given a solution. Your task is to verify the logical steps in between, connecting one to the next in a very incremental way. 


Test-Driven Development works similarly. Your code progresses to the solution but also rewritten to an optimized state. It's often done by a duo of programmers, a practice called pairing, so that you can bounce ideas off and learn from each other. Pairing is a way for programmers to level up on both sides of the spectrum. Ideally, a senior programmer pairs with a junior to work through code. It's a kind of mentor-mentee relationship that helps everyone in the long run. Everyone learns from the experience. 

In using TDD, there are 3-steps known as Red, Green and Refactor. You begin with the problem, much like a Geometric proof. You write a test, then run the test to see it fail (this is Red). Make it pass with code (Green). Then rewrite the code as needed (Refactor or denoted as blue). You move on to the next step and repeat the process. Like a proof, you continue to move towards the solution. 

What I Think Steve Jobs Meant 

Now let's circle back to the Steve Jobs quote. "Everybody in this country should learn to program a computer, because it teaches you how to think." 

Applying Test-Driven Development, you can see how this can be used for life itself. Try something. If it doesn't work (Red), try it again until you get it right (Green). This is like finding the first solution in code. Once you figure out a good way of doing things, modify it accordingly so that your process is efficient (Refactor). This is much like rewriting code to be optimized. It's pretty straightforward, and applicable in a very no-nonsense kind of way. 

Code as Legos

Lego projects are pretty neat. Maybe one piece can be swapped for another piece of a different color or something like that. My point here is to think of Lego pieces as small achievements that you've mastered. This is very much like how bigger pieces of code work, which are called codebases. Comprised of different pieces, codebases can be described to be modular. When code is written with TDD, its strong foundation lends itself to better growth. And you can swap out pieces for another. You can think of life as one big Lego project, but there's this whole other thing about failure. 

Failure is Necessary 

In Test-Driven Development, you write tests to initially and intentionally fail. You will also fail in your progressive attempts to figure out what the code or solution actually is. To succeed with code, you must fail. And that is yet another parallel to life. Failure is okay.  

But failure in life is frowned upon and shamed. It's a dreaded word. It's also feared. I’m not saying or encouraging, for instance, that students should fail classes intentionally. What I don’t understand is drilling the concept to fear failure. Experiencing failure can be turned into the single most powerful motivator and can be vital to one's success. And that's what TDD teaches you. Fear of failure only adds complexity to a solution that's more cut and dry. There's no need to make life more complicated. Conquering your failures can only make you that much more prepared for the next challenge. 


Combine Test-Driven Development with what I’ve previously mentioned with Design Thinking and the GOTE Technique and you have a very powerful approach at your disposal. Whether or not you use them is up to you.

If you have any questions, you can email me at And please feel free to make a virtual appointment with me or my colleague Kristin at We'd be happy to help with your digital needs. 

And until next time, please stay healthy and safe!