Measuring Progress as a Programmer
Posted: 06 Nov 2014
Programming is a skill but like many it can be very difficult to measure one's progress. In the beginning, when first learning to program or a new programming language it is often easy to see your own progress as you become increasingly able and independent of others to perform basic tasks within the language. However it becomes much more difficult after understanding the fundamentals of the language (sadly where many will cease to progress), the skill and difficulty will often begin to lie with the scope of software design.
And software design is an enormous field. Encompassing everything from paradigms of programming to design patterns to methodologies all with the goal of providing adequate solutions powered by good code. Now it goes without saying the no matter how good the code is, if the program does not perform the desired task or fulfil the client's requirements it is as good as rubbish. The more interesting part, what is good code? It is often stated that good code is secure, fast, flexible and maintainable. In OO terms, often following the SOLID principles and the many design patterns has become the guidelines for writing good code.
So how to measure one's progress? Well for myself, I learnt this when I was not so pleasantly surprised going back to one of my personal projects from a few years ago. I built NetYelp throughout 2011 and I remember being especially pleased with the final product. However it is now 2014 and just recently did I attempt to make some improvements internally. Looking through the codebase I was not impressed and initially disappointed due to the lack of clarity, duplication and the general mess that littered the project. However I soon realised a striking insight, I myself was not able to see the mess that I created, I wrote code that I deem bad today but during that time, I deemed it good and I was proud of it. Which lead me to the positive conclusion that I had since improved my standards of what I deem good code hence progressing as a programmer.
Now this story may not be applicable to you, but just as guideline, look at some code you wrote previously. If you deem it as good code, perhaps it is sign of yourself not having significantly progressed since writing it.