Malcolm Gladwell has this now-famous metric about how 10,000 hours of practice in a sport/trade/etc. is roughly the amount of time required to become a master in that area. Under a certain set of assumptions, this is about 5 years of full-time work. I’ve been working as a pseudo-journeyman programmer for about a year now, so I’m on my way, but I want to establish another somewhat arbitrary milestone: writing your first 10,000 lines of code.
Every Friday, I spend about 20 minutes taking stock of what I did over the course of the past week, update a running document with high-level summaries of projects I’ve worked on or am currently working on, and make a general plan for the week ahead. As part of that routine, I also do a quick linecount of the code I’ve written for various ad-hoc projects, data analytics research, and the small application I build and maintain at work. A few weeks ago this linecount breached the 10,000 mark. Thanks to the publicity-engine and PR aptitude of Gladwell, an immediate bell began going off in my head. My first thought was a bit of shock that in such a short time (around 9 months) I had managed to build up that much code. My second thought turned into a long silent trip down memory lane as I started to reflect on how much I learned – sometimes the hard way – in the course of writing those 10,000 lines.
Start small, think big, then get back to starting small I am pretty sure
that I’ve seen a T-shirt, coffee mug, or meme somewhere with the phrase “Think big, start small”, or some derivation thereof. I want to amend that slightly by adding “start small” to the front of that advice. Perhaps it’s only a certain type of personality, but if you start by thinking big, it can get overwhelming how distant that end goal may be. The best way I’ve found to get around this is to start a project by actually writing some code. Anyone who has had to write papers in school knows the fear of a blinking cursor as you start an essay. Likewise, every seasoned programmer knows that a blank text editor is one of the scarier things you’ll face. However, the second a little code is on the page, things tend to snowball ahead. Now, if you forget to step back and go to step 2 (think big), it’s easy to get caught in that snowballing code base and not think about whether or not where the code is currently going is in fact where you want it to go. After re-acquainting yourself with the bigger picture, it’s time to get back to the details and get that snowball rolling again. Rinse and repeat.
Read good code Ever wondered why the younger siblings always seem to be the
‘better’ athletes? There is a strong case to be made that it is because they are constantly playing-up, i.e. being mercilessly defeated (or not) by older siblings. This sort of constant challenge pushes them in ways you simply cannot get if you are surrounded by people of similar abilities. I think the same holds true professionally. But, if you are lacking mentorship, turning to the vast swaths of open-source code bases available online can be a fruitful second-best. Digesting that well-written code and borrowing from not only the code style but also the techniques can yield great benefit in your own projects.
Develop good coding habits early Sadly, nothing new here again. Bad habits
are hard to break. I remember reading this advice relatively early on in my transition to pseudo-journeyman and it’s kept me honest and relatively anal about code style ever since. Not to mention, once you’ve written a significant amount of code with those bad habits shining through, it is a lot more painful to re-write than if you started with at least some good habits. No idea what constitute ‘good’ coding habits? Here are a couple of resources I’ve found incredibly useful as I’ve started trying to develop my own:
Understand why code works, not just that it works It is all too easy
to get caught up in the excitement of a snowballing code base. This is especially true when writing code in a high-level language like Python where you have to do much less thinking about the nuts and bolts of a program than if you are writing at a lower level in C/C++ or even a language that enforces OOP like Java. However, at some point, there comes a time where you end up needing to know why something worked and not just that it works. If you have to go back to square one and try to understand your program from the ground up because you got too caught up in adding new features/enhancements/whatever, it is much more painful than if you have been building upon your knowledge of why it works the whole time. In short, if you ever find yourself saying “Wow… I’m not sure how that just worked, but that’s what I wanted it to do.” then stop right there and take the time to understand what is going on. In the best case scenario, the code is right, and you got lucky. Equally likely however, is that the code is wrong, or subtlety wrong, and you’ve just introduced a bug that is going to come back and bite you.
Learn the hard way sometimes: it is good for you Personally, I learn best
by doing. In my experience, it also seems that this is true for the vast majority of people. Even if you are someone who can ingest a lot of information just by reading or listening, it still seems to be the case that a deeper understanding is gained by actually writing code that does what you’ve been reading about. This does mean that you will occasionally find yourself re-inventing the wheel. If you are re-inventing because you don’t know that wheels exist, then that is a problem. If you are re-inventing it because you need to know how a wheel works to build a better one, then that’s A-Okay. After all this isn’t a new philosophy. School is really just one very long exercise in re-inventing the wheel and it happens all the way through coursework in PhD programs.