There are two ways to looking at old code: "I can't believe I wrote this code" and "I can't believe I wrote this code."
I recently tabled a small module for about a month. I came back to it and had trouble remembering what I was trying to do. Why did I name my variables that way? What was the point of this function? How could this ever work? If anyone else had ever seen that code, I would have just crawled into a hole and died.
OTOH, I recently wanted to build a new UI gadget in javascript and remembered once writing something similar in VB years ago. As I went through that code, I thought, "This is really clever! Was I really that smart back then? Why haven't I written anything this cool lately? Am I losing it?" (The answer for me and everybody else is, "If you did it once, you can always do it again.)
Ok, I seriously thought I was the only one who did the second. I've looked back at some of my stuff and thought that that was when I probably peaked and none of my stuff lately is as good.
The second "I can't believe I wrote this code" (in amazement) is a red flag for me. I always like to look back at code that I wrote years ago and think "That's horrible", or "I can write a better/faster version in half the time!".
To me, it's a measuring device that tells me I have not been stagnant and that I'm improving and honing my skills. And since my code will never be perfect I should always be able to look back in disgust, otherwise, I'm not pushing myself hard enough.
I've got 5 years professional experience (and quite a bit more hobby experience) and I have to say I knew all of these already. I'm guessing that after about 5 professional years, there's not many more basic lessons to learn.
I would add one, though:
Have a workflow. Have a default way you do things, like code formatting. Break it when you need to, but if you find yourself breaking it for no reason, clean it up. It'll help you and anyone else working on the code later. (And by 'later' I mean 'soon'.) Also, tend to do things in the same order, so you don't forget them. For example: Unit tests, function outline, function declaration, doc block, code.
Great article from an experienced guy. My two favourite advices :
- "No project is ever simple" : when somebody asks you to solve a simple problem, it really often turns out to be bigger than foreseen.
- "Set a duration of how long you think it should take to solve a problem" : do not spend too much time thinking alone on a problem before searching for help, either on internet or by your colleagues/peers.
Document your code - Whether its documenting a Web Service API or documenting a simple class, document as you go. I've been accused of over-commenting my code and that's something I'm proud of.
This is something I'm "guilty" of not doing, but I really can't. In the beginning I was commenting a lot my projects, even writing Doxygen documentation for every class and method. But I find it really disruptive of my programming process. While I write code my thoughts go on pretty fast, and stopping commenting breaks my flow. Doing it after the code is completed does not work for me, I never do it and these kind of tasks accumulate. Moreover when I read code I never read comments, but just the code.
I believe that very well written code does not need much commenting. I put comments when I do something that can't be evinced by the code because is some sort of exception or workaround.
I've been programming 40 years, so there. Here are some he missed:
- Keep at least two rubber bands around your punched card deck. It doesn't take too many times trying to put your cards back in order after they fall on the floor to learn this.
- Adding a pastry when you submit your job to the operator may mean the results will come out fifteen minutes earlier or more.
- Keep your paper tapes in a waterproof box!
- In Fortran 66, try not to GOTO a GOTO that goes to another GOTO. Keep that code readable.
If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."
The tech platforms and even underlying practices (Web, NoSQL, etc.) move so damned fast that even skipping a few years could leave one feeling quite daunted.
There are two ways to looking at old code: "I can't believe I wrote this code" and "I can't believe I wrote this code."
I recently tabled a small module for about a month. I came back to it and had trouble remembering what I was trying to do. Why did I name my variables that way? What was the point of this function? How could this ever work? If anyone else had ever seen that code, I would have just crawled into a hole and died.
OTOH, I recently wanted to build a new UI gadget in javascript and remembered once writing something similar in VB years ago. As I went through that code, I thought, "This is really clever! Was I really that smart back then? Why haven't I written anything this cool lately? Am I losing it?" (The answer for me and everybody else is, "If you did it once, you can always do it again.)