Code Quality: Relearning by review and not chasing the new, hotness in Node.js

Programming is funny. There is this idea that you constantly get better at it — the old thing that you coded from a year ago might as well have been written by someone else. Certainly, I’ve gasped at the quality of my previous code. But I think there is more going on here. As we get deeper and deeper into a language (or framework, project, whatever) we get more idiosyncratic about what we are doing and sometimes we get better.

One of the projects I’m working on (Higher Ed Careers Canada) has a lot of admin tools that makes it work. I actually use the admin tools ever day — not as a programmer, but rather as just a user (this is not what you see when you log into the above site). This project is several years old; the admin part the oldest still-in-use bits. It is built in Node.js with Restify with much of the application logic on the front-end in jQuery, while the data is stored in AWS SimpleDB and S3. A static files are served for main HTML file and CSS styles.

I modified another part of the project — the part that puts information into SimpleDB, upgraded some packages and went on with my day. When I went to use the admin app a few days ago, I was not happy. All of my testing around the time I made changes passed, however I was only testing with English language sources — when French language strings came into play, bad things started to happen. The upgraded module seems to now handle html entities differently and it was choking the other parts of the app. Rolling back those upgrades wasn’t an option in this case. I needed to modify the stable, long-running admin tool. The problem was that I no longer write with these tool or in this style anymore (I generally use Express nowadays and some fancy Jade templates, and AbsurdJS for styling). Time for relearning.

Bracing myself for the worst

“Here we go,” I thought. I knew if I saw terrible things going on I would be compelled to fix them. First, I started looking for some application logic in the Node app. It just wasn’t there. Finally, I realize that I put that sort of thing all on the front end. It was a bit of an odd choice, but it wasn’t bad.

One thing I did notice is that I’ve gotten holy-crap better at regular expressions. I had a weird and complex 3-line RegExp that I simplified to about 10 characters.

But going back through the code, I did see some things that were rookie mistakes. I had the realization that the project, on the whole, wasn’t half bad. The code was concise, got the job done, was stable, and had a tiny memory footprint. Maybe I wasn’t an idiot a few years ago. Although it didn’t look like my current code, it wasn’t bad.

So, after an hour of fixes of “bad” code and then another hour of solving the problem at hand, I had a refreshed admin app. I also had a better understanding of how a problem can be solved in multiple ways — we have lots of tools at our disposals and with the modularity of Node, you can mix and match to solve just about anything. I think when I review something online, I’m going to be a little less judgey if the code doesn’t look like mine or it uses tools that I don’t currently use (or have fallen out of fashion).

Show your support

Clapping shows how much you appreciated Kyle’s story.