It’s the second Tuesday of the month, and as I’m sure you remember that means it’s time for T-SQL Tuesday! This month we are hosted by Raul Gonzalez (b/t) and the topic is Lessons learned the hard way.

I’m going to take this opportunity to talk about the very first lesson I and probably most developers (or database devs) learn (it also gives me the opportunity to tell a funny story).

Save Often!

FYI If it really bothers you that I’m talking about saving code in a blog that’s mostly about databases as I see it you have three options.

1. Realize that T-SQL is code and still needs to be saved.
2. Replace the word save with backup. Same lessons apply.
3. Don’t read it. It won’t hurt my feelings .. really. sniff I won’t mind .. I promise.

 
So years and years ago, when I was in college, one of my favorite classes was Assembly Language. We were working with Mac Assembly in case anyone is interested (yes I used a Mac at school, one of the big ones that had the monitor built into it). Somewhere around week three or four, we were supposed to print something to the screen. I spent several hours (this was only my second programming class so even Hello World was a challenge) and got my program ready to test. It worked! Sort of.

Hello World was written to the top of the screen! Then a second or so later the bottom half of the screen turned into random ASCII garbage. Then a second or so later the computer rebooted. Well, that’s not good. Time to debug!

So the computer comes back up, I take a look, and I don’t have ANY code. I hadn’t saved (and this was long enough ago there was no auto-save). I had to start ALL over again. In the end, I did manage to re-write my code, got it working and even got an A. I also learned that I needed to save my work before running it. Well, learned my lesson for the first time (of many).

The next lesson refined things somewhat. Same class, a few weeks later, and we had to write a file to a floppy disk. If you don’t know what a floppy disk is, either read Wikipedia (link in the previous sentence) or ask someone over the age of ~35. Either way, I remembered to save my code! Yay me! Unfortunately, since we weren’t allowed to save to the PC (I was working in a lab) I saved to the disk. The same disk I was supposed to write the file to. You can see what’s coming, can’t you? Yes, my first pass at the code completely trashed the disk. Time to start over again. Again.

I got better at saving over the years, and things were mitigated somewhat by autosaves. I also tend to leave my computer running overnight so if I forget to save some code I still have the option of saving it in the morning. I’m particularly bad about not saving working code I don’t need long term. Unfortunately in this day and age of Windows updates automatically rebooting your computer (in the case of my work computer post Windows 10 upgrade that would be daily) I’m having problems again. I need to get back into the habit of saving everything, often. Even working code. In some cases particularly working code.

I’m partitioning every table in a database right now. It’s a very manually intensive process but I’ve written a lot of code to help me out. In theory, I should have written the code while working on the development environment, then refined it in test, and I’d have been good for model and production right? Unfortunately, while I saved, I didn’t save it very well. It’s been months since the last effort, so I’m having a hard time understanding some of it. I needed to put in more comments. And that’s what I could find. In a bunch of cases I know I saved something I need now but I didn’t put it in a place where I could find it again. So now I’m re-writing some of this stuff for the 3rd time. I’m being more careful this time though!

So in summary:

• Save often
• Save somewhere that won’t get overwritten or destroyed
• Comment so when you look at your code months later it makes sense
• Save somewhere you can find it when you go looking months later