Becoming a better developer

I have reflected on how this year was. My goal this year was to work primarily on JavaScript and improve my understanding of the language and be able to confidently work through bugs and features. While I was able to accomplish this, there is still lot of room for improvement. I have figured that the best way to track and account for my growth and learning is by blogging about it. I plan to post resource links, videos or tutorials I read and also some code snippets as I solve bugs and learn new insights.

My manager (GB) shared with me this resource for learning how to do code reviews the correct way — http://goodmath.scientopia.org/2011/07/06/things-everyone-should-do-code-review/. To summarize, code reviews should be looked at for correctness (for code author’s perspective), code reviewer need not feel obligated to say something and review should be done promptly.

To do better code reviews for the team, it is important to understand what their code is doing at a higher level. I often find myself doing lot of nitpicks. While it is good, but it can be annoying to others. I pride myself for always paying attention to details. I am an expert in catching typos and the non-standard and bad practices in the reviews. I am a stickler to rules and I take pride in that. When I observe how my manager does my code reviews, I am amazed by his keen observations and his knowledge of what’s happening overall in my code. He never misses the big picture.

If I gain more understanding and knowledge about the architecture, design patterns and performance optimizations, it will help me in seeing the big picture. Next year, I promise to take time out to do more code reviews and to do them as I mentioned earlier. I think reading code written in libraries will help me learn to read code better.