The Enlightened Newbie Syndrome

Recently I was reviewing some code written by a new programmer, this person had demonstrated good knowledge of his domain and was quite well regarded by everyone. However when I looked at his code I saw a familiar pattern that I had seen before which I like to call the “Enlightened Newbie Syndrome” (ENS).

You can detect ENS when you see code that is a mish-mash of good code intermingled with overkill on “best practices”. The Enlightened Newbie will focus on making sure that his code adheres to the latest naming conventions, follows TDD but doesn’t test the right things and applies design patterns too liberally 🙂

In this particular case the programmer had used different naming conventions for variables based on it’s usage, so for e.g. pascal case for params, all caps with underscroes for local variables etc. Another classic sympton was the elaborate comments about assignment statements complete with box decorations around the comment. Further the variables if named properly would have been enough to indicate their usage but instead the variable names were extremely generic and then had big comment boxes near them to describe what the variable was used for.

The saving grace of the code was that logically it was setup correctly, but it was clear that the programmer had not unit tested his code at all, my first invocation of the code gave me wrong results and upon further analysis it looked like a lot of the edge cases had been missed out.

I remember being an enlightened newbie once, I had read all the books on design patterns, refactoring, TDD etc. but had not yet written a lot of code. So when I worked on my real project it was very tough for me to find the style that worked for me and I ended up with a bit of everything at the start. However as I worked on that code for the next 3 years all the things that I had read started to make sense and I realized that the essence is to not follow a practice religiously but to make use of good judgement to see what applies where.

So in my mind there is only one cure for ENS and that is to just write a lot of software in a team environment. Note that I am not talking about just chruning out code but actual working software, and again not in isolation but in a team. Because

1. You can write a lot of code and only improve your typing and not learn a lot about programming, however when you build an actual product/service and then have users or other systems interacting with it, you get a lot of feedback on what works and what does not. Based on the feedback and other external requirements the software usually goes through a lot of changes and when you have to go back into your code and make changes then you really appreciate brevity, simplicty and the DRY principle.

2. Working in a team environment exposes you to code that is both better and worse than you, it gives you more exposure to the different ways something can be done and all the different ways you can use tools to make your work easier. Teams are just fantastic platforms for improving your skill, knowledge and productivity.