You Can Teach an Old Dog New Tricks

A lesson learned a little late is better than never having learned it

I’ve been writing code in one way or another since I took my first programming class as a high school senior in the fall of 1982. Wait, did I say first programming class? It is the only programming class I have ever taken. The Computer Programming class that I was in was the first computer programming class ever taught at my high school. The teacher had just learned a bit about programming over the summer, so we were his guinea pigs. I’m pretty sure it was using the Apple IIe, and we learned to write in whatever flavor of BASIC Apple was using then. Looking at it through today’s lens, the Apple IIe looks like an abomination, but back then? They were like magic to me.

I bought an Atari 400 in 1984 while I was stationed at Ft. Lewis, WA with the US Army. In those days, the consumer-level computers hooked right up to the TV and this one boasted a whopping 16k of RAM. I would spend hours programming a video game on that thing. I had to write out all the code in a notebook as a backup because the tape drive that I used as the primary persistence would fail so often. I didn’t even have a disk drive, so forget about a hard drive! I’d stare into the screen looking for bugs in the code for hours on end. But I learned to love the process.

Side note: A television sucks as a monitor, and when your roommate would rather be watching something on TV, I had to be pretty annoying. But hey, it was my TV. Sorry, Chico.

When I left that duty station in 1985, I sold my Atari 400 and didn’t own another computer until 1992, shortly after our second son was born. I sort of always wanted one, but it wasn’t fitting into my budget. But from that point forward, I’d always have a computer at home. I did some programming here and there, but it was always for fun. I did make a little money on the side when I was stationed in Maryland (95-97), making a website for a dude who ran a business doing video game console modifications and also sold video game CDs on the internet. People would ship this guy their consoles, he’d make the mod, and ship them back so they could play foreign games on them…or something along those lines. I think he was doing rather well for himself. But the website I made was all static content. No database, just a slew of static HTML pages linked together. Hundreds of pages. No style sheets, no JavaScript. It was the early days of the web. This too, looks like an abomination by today’s standards!

I was then sent to Korea in 1997 and had to stop working on the website. I did do a few updates from Korea, and the ISP that I was working for wanted me to keep it up! I set up my first webmail address to communicate with them, but it was only a matter of days when I told them it wasn’t going to work when I had so little idle time. I did write my very first VBA scripts using VBA for Excel while I was stationed there. It was at the end of my tour when I worked in an admin area while I was waiting to leave for recruiting duty. I made some shortcuts for the KATUSA Soldier who worked in our unironically named Orderly Room.

I’m not a particularly good programmer, but I have designed some real-world applications as part of my profession over the years since I retired from the Army in 2003. But in all of those years, I have never learned the lesson that I am forcing myself to learn on the project I’m currently creating. I’m talking about leaving comments in code. The sort of comments that you would want some future programmers to have so they would understand what your code does. There are probably many schools of thought on when to, or when not to leave comments in code. I think I have found one case that most certainly deserves consideration.

Sometimes, when working on a program, you’ll come across a case where something doesn’t quite work the way you want it to work. It could be a lack of understanding, or it could be a limitation of the tools you’re using. You can use a technique that will technically work, but you’re sure there is a better way or a more standardized way. Sometimes, or probably often, there are standards for a reason. I can spot some obvious issues when it comes to performance issues, for example, but I am nowhere near an expert. So I’ll usually defer to convention. If you go down too many rabbit holes when it comes to understanding, you’ll never get anything to production.

Here is a case I had today:

This gets the information for a View, which is the component that is displayed to the user in a browser. Unlike the static pages that I worked on in the ‘90s, pages are very much dynamic today. The return structure of this function is what’s called a View Model, and it’s a representation of the static part of the View, or web page.

In this case, we’re getting the details of a specific item, and then along with that item, there is also a list of comments related to that item. This information is all in a database that the website is getting the dynamic content from. In this case, the total of the information is stored across several tables. As long as programmers understand how the data is structured, what the relationships are, etc…we can write queries to read the data and use it on our websites. The data structures (objects) that we use to arrange the data from the database into our code are a direct representation of the tables, views, functions, etc., of our database. What this code does, is gather the information, then transform it to our View Model using a tool called AutoMapper.

What I initially wrote doesn’t work the way I thought. It was initially just two statements, but I realized that it returns the details for my item, but it isn’t returning the related comments of that item. It isn’t returning them, but it is retrieving them! The initial statement includes the comments, so it was in the AutoMapper statement where the comments were getting dropped. Since I spent more than a few minutes trying to get it to work I decided to use a technique I thought of right away, but wanted to hold off for at least a few stabs at it fixing it. This is one new trick I learned along the way:

Know when to move on. Come back later. It’ll still be here. But it works now, and it isn’t making another database call. Which leads me to the second new trick:

Put the damn comments in the code! Like I said above, this has been a weakness of mine forever. I have left a few here and there, but nothing consistent. But this project is going to have comments, mark my words! I won’t put comments just to have them there, but if there is something noteworthy, put it in there! It’s probably you that’s going to need it anyway!