One of the big mistakes I see young programmers make is writing code that they should never have written. While the code was a great educational exercise, it was a waste of the employer’s money. So how do you decide what code to write and what code to leave out?
Here are some simple rules to follow that will make you an asset to your company. If you want to be the last one they fire, make sure you are the most efficient programmer.
- Only write code that you know is needed today.
This one comes from my own personal experience as well as managing other young programmers. “This code will only take a second, and they’ll need it next year anyhow.” The only problem is, you aren’t a god. While it may look like that code will be needed next year, the entire business may change. You may not need it at all. And even if you do, next year there will be better tools available which may allow you to write the code even faster. Or, maybe you’ll be able to buy or copy the routine from some place and avoid writing it altogether.
- Spend a few minutes on Google and see if anyone has already written the routine you need.
This one seems so obvious to me. Maybe that is because it wasn’t even an option when I started programming. There is just so much code available online these days. It really doesn’t make any sense to write most of it yourself. Find a sample that is close and modify it. Buy something (of course, you may need to talk the boss into this one). Sometimes finding a way to not write the code is really the best way to go.
- Ask others to write the code for you.
Let’s be honest. We all have different talents. If you know that a co-worker could write the code you need faster, it might make sense to have him write it for you. Especially if it is code that would take him 5 minutes and you a couple hours.
- If there are N of something, there WILL be N + 1 of something where N > 1.
While it always makes sense to only write what is needed today, be careful that you don’t ignore the obvious. This rule is particularly obvious when working in a database, but it shows up in other areas of your code, too. For example, in your database, if you end up having multiple fields that all represent the same thing–maybe a pointer to the address record. (HomeAddressId, WorkAddressID)–why not just create a table that links to the main record that has an ID that links back to the main record, an ID field that points to the Address ID, and a description field to describe what type of address it is. Then, when someone wants to add another kind of address, it isn’t a coding problem, it’s a database problem. It won’t take you any longer to code this than if you had hard-wired it for the two types to begin with and it WILL save you time when they ask for that third field.
- Ask for help.
Here’s another one that sounds so obvious. But I hardly see anyone doing it. Especially programmers fresh out of school. If you can, find someone who can mentor you. Find someone with loads of experience that everyone in your shop knows knows the answer. When you get stuck, as soon as you get stuck, give that person a call and get unstuck fast. You may think that you won’t learn anything. But that person knows what he knows not because he has a peculiar thought process, and by getting help from this individual, you will learn the thought process AND the solution to your specific problem. And that will make you a valuable programmer.