When you’re a programmer, there’s way too much to learn. Think about when you wrote your very first “Hello, World!” program. For me, it was in fourth grade. We learned C++, and our teacher had written the program by hand on the blackboard for us to copy. We used Turbo C++, which we’d copy to a floppy disk so we can experiment at home1.
At the time, I didn’t think of Turbo C++ as an editor. I didn’t think about it as an IDE. For me, Turbo C++ was C++. As far as I could tell, it was the only way to program. I didn’t really know what it meant to “compile”. I didn’t know why you needed that
#include <stdio.h> bit. I didn’t know what
main did, or how
printf can accept however many arguments I pass. I just copied the program from the blackboard, hit
Run and got the output on a screen.
This is great. This is how programming should be taught. You should do stuff way before you can figure out how it works. For a while, you should intentionally be ignorant about distracting details.
Eventually, you will grow up. You will know what
#include does when you write your first “big” program. You will know where the output from
main goes when you start running executables from the shell. You will know how
printf works with parameters when you learn about variadic arguments.
Knowledge debt doesn’t exist just for fourth graders taking their first steps in this world. I coded in C++ before I knew how shared libraries work; I developed a web application before I knew how the underlying web server handles requests; I programmed for embedded Linux before I knew how to compile a compiler for different targets; I created an Android app before I could tell you what is an “application life cycle”. Again, this is great. You should definitely not know about metaclass before you write your first Python application (some would say - never).
These were all “knowledge debts” I had for quite some time while programming professionally. Putting them aside allowed me to make progress quickly without being bombarded with details. But knowledge debt, like technical debt, should be temporary.
You should, intentionally and tactically, decide which piece of information you can do without, for now. But you should also, intentionally and strategically, decide when to pay back that debt.
Knowledge debt is like financial debt. It’s a tool - you need to use it wisely to make a profit. Imagine you want to start a small business. Taking on some debt up front in order to make more in the future can be a great decision. But like financial debt, you’ll need to define the parameters of your debt appropriately to your situation. Taking on too much can be dangerous, but so is taking too little. It’s also important to decide when and how to pay the debt back. Keeping a debt too long can make you pay too much interest, but trying to pay it back in large sums can cripple your progress.
As with financial debt, knowledge debt is not only for beginners. Big corporations take on debt as much, and even more, than small business owners. They also take bigger debts. Just as the fourth-grader-me needed to put off learning about compilers, older-me needs to put off learning about the internal implementation of the CPython interpreter.
Being a programmer is about being in a continuous state of learning. Letting knowledge debt accumulate can slowly bring your career and productivity to a halt. If you have a knowledge debt in an area that is essential to your work, you will find that it takes more time and effort to write new features and much, much more time and effort to fixing bugs. The longer you take in returning the debt, the more “time interest” it will cost you.
Putting the time to understand the inner workings of the technologies you work with will let you work faster, with less effort and more confidence in your professional abilities.
I believe knowledge debts is what separates mediocre programmers from great programmers. Great programmers don’t settle on not knowing; but they are also not obesessed about learning right now. They are in a continuous cycle of taking on debt, noting it and coming back to it when the time is right.
Identify your knowledge debts today - find out what you need to understand in order to become better at what you do. Be on lookout for opportunities and pay it back. Get better.
Follow me on Twitter, Facebook or Google+
Thanks to Hannan Aharonov, Yonatan Nakar, Shachar Ohana and Ram Rachum for reading drafts of this.