Developers wear too many hats. It’s unavoidable in small teams. And three months down the road, when you have an emergency with the database you haven’t looked at since you created it? You won’t remember how to get it running. You might get 9/10 steps correctly, but you’ll miss one and spend hours screaming trying to figure out what’s wrong.
Write yourself detailed notes – even better, write utility scripts so you don’t have to relearn it every time. The 30 minutes it takes will save you hours down the road.
Some tips when writing rarely used but mission critical utility scripts:
Don’t directly modify the database.
Big no-no if your script has anything to do with database structure or administration. Odds are, database tables will change in the months between running the script. Output SQL statements to text files instead. Then you can check them over and execute them manually.
Keep framework usage at a bare minimum.
Keep your script as framework independent as possible. This is especially true if using an in house framework or a framework that is still under heavy development. Framework dependent scripts won’t be kept up to date properly when they’re not being used.
Write command line help.
Treat yourself like any other user. Take a few more minutes to add a -h parameter and print usage help. It’s too tempting to rewrite old code when you have to sift through it to remember how to use it.
Make it verbose.
When you run the script and find yourself staring at a blank screen for 5 minutes, you’re going to get annoyed. You’ll want to know what’s going on when you run a script for the first time in months. Make your script tell you what it’s doing.
It’s pretty straightforward, really: always assume you’ll forget everything you know, and do everything you can to make your job easier when you do. Force yourself to do it and even worst case scenarios won’t keep you up at night.