The main reason one should go to graduate school is to do research. To earn a PhD you must have advanced the state of your field. In fact, your PhD defense is all about convincing the guardians of the frontier that the frontier has been moved. That being said, I have a personal goal of improving myself as well. I’m surrounded my brilliant professors and peers and it would be downright stupid if I didn’t take this chance to learn from experts in their fields.
While I want to improve as a computer science researcher I also want to improve as a developer. For me, the fact that we must take our beautiful algorithms, logics and abstractions and express them in terms understandable to a dumb machine is not something to be despised. In fact, I consider it a pleasant challenge and a source of infinite creative joy. I would like my job a lot less if it didn’t involve a significant amount of programming. That being said, how exactly do we level up as a developer? In fact, what does leveling up even mean for a developer?
For the last few months (years?) I’ve been a growing fan of the idea of deliberate practice – the idea that the best way to improve is to take well-defined measurable steps towards getting better where at each step you get feedback as to what you did wrong and how you can do it better the next time. Deliberate practice has been applied by athletes and writers, can we apply it to programmers? In particular, can we come up with something more detailed than “Read code. Write code. Repeat”? Luckily for all of us, Jason Rudolph took some steps on that path a few months ago.
Remember that deliberate practice requires that we have a list of well-defined, actionable goals on our path to excellence. We must know clearly what the goals are and also be able to unambiguously tell if we’ve achieved them or not. Jason came up with a list of simple yes/no goals that will exercise your programming muscles. What I love about Jason’s list is that it combines a lot of what it means to be a good developer. There are goals for learning tools of the trade (different languages, environments and frameworks), goals for learning core concepts (different paradigms and parts of the software stack) and social goals (open source and community involvement). There are a lot of things on the list, but then again, computer technology is a vast field.
Jason’s list is also necessarily incomplete. I’d argue that it’s practically impossible for one man to know all about the computer technology field today. But the good thing is that we have the technology and the community to take one man’s starting point and extend it for our own purposes. Jason’s list is available as a gist on Github and has already been forked many times by people who are using it as their own deliberate practice guidelines. I have my own fork where I’ve fleshed out sections on uncommon programming languages and more theoretical learning goals.
It might be a bit naive to think that just going through a list of programming challenges will make you level up. However, I think the list is a good head fake. The point isn’t really to go and do everything on the list. The point is everything that comes as a side-effect of completing the list. You’ll definitely put in a few thousand hours and churn out thousands of lines of code in a variety of different languages and environments. You’ll expand your mind by learning about programming styles and tools that you would have missed out on otherwise. As you encounter problems you’ll have to ask around on forums, mailing lists and IRC for help. This is important because deliberate practice is useless if you’re practicing the wrong things. In the absence of programming coaches, the global communities of programmers are your best bet to find mentors and guides. If you release your code to the world you’ll gain some street cred, get valuable feedback and maybe even provide something of lasting value to fellow developers. If you follow through on the social and community goals you’ll gain non-programming, but useful skills and meet a lot more people who can point in new and interesting directions. You’ll discover interesting new problems and come up with applications and solutions you might never have thought about otherwise. Maybe, just maybe, you’ll learn enough to level up as a programmer.
As a parting note, let’s all keep in mind that this will not be easy. It will take time and effort. I’m in graduate school so I might be able to make it part of my day job to do some of these things. But a lot of it will have to happen on my own time and energy, when I could be exploring Ithaca’s gorges or watching infinite Star Trek episodes on Netflix. This is even more true for people who have legitimate day jobs and families. We all need to come up with our own reasons for why we want to invest all this time and effort in deliberate practice. But one thing I keep telling myself is that the time will pass anyway and my energy will be spent somehow. I would rather spend it on writing my own operating system than on Star Trek reruns (no matter how much I love Star Trek).
