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.


  1. I’ve had the same experience with every major programming paradigm I’ve learned. OO, design patterns, dependency injection, TDD, functional programming, etc. Way back I even briefly went on a Hungarian notation binge when I was doing win32…

    All these techniques essentially provide a systematic approach to some aspect of development. Each is presented as being a kind of universal design pattern applicable to every situation imaginable.

    What you learn at some point is that working within a system, any system, is constraining. You may be trying to do functional programming, and then realize that solving your problem would be so much easier if you could use an imperative data structure, like say, a hash table? You may be doing OO, and find a solution for which it would just be simpler to use a function and a struct.

    Also, every development paradigm is domain specific, which is not something they tell you when you are learning it. Look at the patterns in the GoF book. They are all centered around the kinds of desktop GUI programming that people did in the 90’s, and how to solve those problems in a particular kind of language. Some patterns, like Singleton, are now maligned as being incompatible with TDD.

    Now, ask yourself this, what kind of limitations are there in unit testing? Are there some domains where unit testing really makes no sense and we’d be better off doing say, static analysis? Maybe even (ugh!) proving the correctness of algorithms? Is TDD domain specific?

    Here’s a hint: check out the Linux kernel tree and try to find unit tests. Ask yourself, why aren’t they there? Is Torvalds just dumb? Then think about the implications that threading, non-determinism, and heisenbugs have for unit tests.

  2. Great article, and great blog. Just wanted to say thanks.

  3. “for e.g.” ?

  4. As a newbie, its everyone’s tendency to use all the techniques that one have learned. Nice post.