# Watch Your Input/Output Ratio

Every now and then I remember something from teaching high school that is incredibly helpful to learning to program, and today is one of those occasions.

If your learning is all input and no output, you will develop a backlog of information that has never been processed, and stop retaining it. In order for long term learning, the rate at which information goes into your brain and the rate at which you do stuff with that information need to be comparable. Maybe not the same, but certainly within an order of magnitude. Here’s a simple example:

Suppose you’re trying to learn Spanish. You come to my class every day, and I talk to you for an hour about Spanish grammar. After one week, how much Spanish can you speak? Basically none, unless you’re either an experienced or naturally talented language student, or you already knew Spanish. Now suppose you come to my class, and on I teach you four sentences to say, and then give you some time to practice. The next day, we practice those four sayings, I add two more, and there’s more practice time. At the end of the week, you’ll probably be able to count a bit, introduce yourself, and ask where the bathroom is.

I think most readers have been through enough good and bad teaching to recognize the two situations, and to see which one is preferable. In the second situation you learn more because you got practice. Your input/output ratio had enough output that you learned to do a thing. So, on the one hand, if you read programming blogs all day and don’t write code, close the browser and go write some code.

But what if your input/output ratio is skewed in the other direction? What if, for example, you spend 8 hours a day writing code and never read code, or read books about code, or read blogs about code? Let’s go back to Spanish class.

Imagine, halfway through the semester, that your teacher quits explaining new phrases or sentences. Students continue to practice. Some of the clever ones learn to recombine pieces of the sentences they know, and continue to progress for a time, and some of the dedicated ones find a few key snippets on SpanishOverflow, and begin using these, but no one really gets better without input.

How can you gauge your input/output ratio? Well, unfortunately I can’t just tell you, “oh, about 5 to 7.” You have to pay attention to yourself, to how you’re reacting to information. So here are some symptoms that I would look for, when teaching, to gauge the input/output ratio of my classes. (Of course, “input/output ratio” is not what an education textbook would call this, but this is a programming blog, and “output” sounds way cooler than “opportunity to practice what you learned.”)

### The Symptoms

Symptoms of too much output (that is, symptoms of not enough input):

1. You feel like you’re repeating yourself. You implement a feature, and when you’re done, you could swear you wrote that same code last month.
2. You’re bored – implementing features, hunting for bugs in the code base has started to feel routine.
3. You have no mental backlog. There are no side project ideas, cool language and/or language features you wished you got to use, interesting podcasts you’ve listened to, security vulnerabilities you just heard of, etc. The list of stuff you’ve heard of but haven’t tried is empty, or low. That is, you’re writing code from an empty tank. There’s nothing you’re itching to sit down and try. (Be careful with this last one. If it keeps up long enough, you’ll start to be unhappy and lose productivity really fast.)

Symptoms of too much input

1. You have a case of Object Happiness (as observed by CodingHorror).
2. You often go to use something you learned recently, and you discover that you don’t remember it well enough to get started without going back to the source you learned it from. For example, when I started learning R, I was watching a lot of videos about R, but I never got a chance to use it at work, and I never made time to use it in side projects. Then, when I went to implement something in R, I was right back on StackOverflow because I could only half remember any of the R videos. I needed to make time to practice and slow down on the videos.
3. You’re in the middle of reading 5 books but don’t have a side project.

### Which one is More Common?

I think that, by and large, too much output is more common than too much input. After all, professional developers get paid to write code, not read books about code. Even if a lot of the time we spend “writing” code is actually spent reading code and deciding what code to write, we still spend a lot of time expressing techniques and idioms that we know, compared to the amount of time we spend acquiring new ones.

On the other hand, I think fresh out of school (or freshly self-taught) developers might suffer from too much input. That’s why Object Happiness is associated with inexperience. I think, frankly, that if you made experienced developers take a three year training detour in the middle of their lives, they would come back with too much input and would try to bake piles of extra technique into every line of code.

### The Cure

Of course, the cure for a ratio being out of whack is super simple: Add stuff to the side that’s too small. If you feel like you have the “too much output” symptoms described above, try picking up a book or watching some training videos. If you have too much input, especially if you’re a student or are in the self-teaching phase of your software career, get out and write some code.

Till next week, happy learning,

Will

## 2 thoughts on “Watch Your Input/Output Ratio”

1. […] think this rule really might just a be a special case of watching your input/output ratios. In other words, if you start by reading a technical book right away, your input/output ratios will […]

Like

2. […] trying to learn, not read merely read about the thing we’re trying to learn. We need to watch our input/output ratios. It was also very comforting to hear people who are quite senior and successful Ruby developers […]

Like