Automate, Automate, Automate
This is what computers are good at. This is why they run the world today. If you find yourself doing something for the second time, then look for a way to automate it. Take the extra time to try and remove the human element from your software. If you have to involve the human, then ask all of the questions up front so that they can leave to do something else while the software you’ve created does the dirty work.
Test, Test, Test!
Automated testing is worth the effort. The time spent creating the tests is more than paid back after the 2nd or 3rd release of the software. Software spends most of it’s life in maintenance mode. Unit tests help other programmers be confident that they haven’t broken the existing code. Unit testing eliminates a significant amount of the effort required when re-testing before a release. Why repeat manual tests at the end of each release cycle when you could have followed rule #1 and automated it!
Your error messages should be “how to fix it” messages.
Whenever you see an error message, ask yourself – does this error message tell me how to fix the root cause of the problem?
“Can’t connect to the database” is not helpful.
“The database server didn’t respond. Usually this is caused by insufficient permissions (you are not currently allowed to connect), a firewall issue or an in progress database restore.” is much more helpful and gives your support team something to try before they escalate. If you’re in a situation where this much detail is not wanted, then make sure it ends up in the application’s error log.
Little improvements such as changing “The key DbName was not found.” to “The key DbName was not found (note this is case seNsitive)” can save minutes and sometimes even hours of debugging time.
Your error logs must contain as much debugging information as is reasonably possible.
If you call someone else’s web service, log the parameters that you sent. Log the exact date and time of each transaction. When something goes wrong, you can tell them exactly what was sent, and they’ll be less likely to tell you that the problem is on your side because you can prove that your software functioned properly. If the problem is with your code, you’ll be able to tell without having to guess what happened.
When two systems integrate, don’t blindly trust the data that was received. Validate it. When possible design the data contract in a way that makes extra validation possible. Doing so will help prevent bad data from entering your system; and will help the folks who maintain the other system ensure that their data has high integrity. It’s a win-win.
After fixing a bug, look for identical bugs elsewhere in your source code
When you finally figure out why a piece of code isn’t working, check around the rest of your code base for the same coding mistake. You’d be surprised how many times the thing that you’ve just fixed is broken elsewhere. Don’t waste the work you spent debugging the original problem by ignoring similar problems.
Refactor, Refactor, Refactor
Good software is always organized well. Your goal should be simplicity and re-use of existing code. Your motto should be this: “Do one thing, do it well.” Remember algebra when you had to simplify functions such as 3x=2y+x? The mentality is the same with software. You might start with something a little more complicated, but you always need to refactor that code and “boil” it down in to its most essential parts. Less code is always easier to maintain!
Leave things better than when you came
When you work on code, don’t be afraid to make small cleanups, improve the organization of the code, add comments to further explain things that are not obvious.
Read about your profession and learn from those who have been around awhile
Read How to be a Programmer at least three times.
Do you know who Fred Brooks is? He’s written papers about many problems you have today and thought were new. They’re not, and he’s already thought about them for you – years ago!