On the lines of Peter Norvig’s article about teaching yourself programming in 10 years, Mike Lewis (“Apoch”) writes a nice post about how to become a good programmer in just six "simple" steps:
- Get in it for the long haul.
- Write Lots of Code.
- Read Even More Code.
- Learn Many Languages. Master a Couple.
- Create a Language.
- Learn Something That Nobody Else Has Learned Yet.
There is lots more in the details and I agree with most of them. Learning about recursion, understanding a declarative language like SQL or XSLT, understanding functional programming, etc. all expose you to various ways in which you can solve programming challenges. You may think that the “creating a language” is hyperbole, but having done that (a toy language) myself, I would say it is a particularly interesting exercise to go through. For example, if you write an interpreter to execute a program in your language, you will learn about computer internals, say for example, how to handle variables, constants, loops, etc. instead of just using them.
Sometimes these kind of articles invite the comment that programming is not an end in itself. But it could be. Programming can be a hobby and a lifelong pursuit. You could keep learning, keep tinkering with different concepts and ideas and perhaps not release most of what you code to the general public. Learning can be its own reward at times. You don’t have to be a great programmer for the world.
Also, this kind of attitude, while seemingly all over the map, can come in handy even in the short-term. In a recent article, Alan Skorks wondered why developers do not use state machines even though they are pretty useful and suggested:
We seem to shy away from state machines due to misunderstanding of their complexity and/or an inability to quantify the benefits. But, there is less complexity than you would think and more benefits than you would expect as long you don’t try to retrofit a state machine after the fact.
If you are in the habit of playing around with tools even they do not seem directly relevant to your work, you will soon find some tools that *are* relevant to your work. Or as you get new challenges, you will be already prepared for them with techniques you learnt along the way. This is what comprises useful experience more than the usual metric of “years since you wrote your first program”. As the years go by, as a programmer, you have to grow, expanding your knowledge and learning new techniques.
This is not to say that you cannot create something useful with very little knowledge or page fault programming. As I have written before, young startups with programmers just out of school are creating applications of huge value, both in financial terms as well as to end users. And one should strive to create programs that are used. But professional improvement is positively correlated to that. Very few bad programmers manage to create something of value to others. So keep learning you must.
[CC Photo licensed from Rachel Johnson]