(Or: Fail Forward Fast)
It’s said, and said frequently, that you learn more from your failures than from your successes. Given that a lot of us tend to have plenty of failures to learn from, we can certainly hope that that’s true. However, in order to learn from your failures, you have to know what you did that lead up to that failure.
Regardless of your success rate, you’re going to want to be able to replicate whatever you did to lead to that outcome, whether to test it or to be able to succeed again in the future. Instead of just making guesses and trying to remember what the steps were to lead you to where you are, you’re going to need to keep track of your steps.
This is especially important when your job is being watched carefully by others (or, as carefully as others can watch while not being as knowledgeable as you are). When you’re asked to produce a certain outcome, and you’re not completely sure how to do it, it’s critical to keep track of every step – every single step, especially if it’s not something that’s automatically documented, like a block of code is.
One suggestion – if all else fails, document your assumptions. If you expected a stored procedure to return certain values to be used, or a view to provide a specific slice of data for reporting, document those expectations and assumptions… particularly if they appear to be working.
This is because later, if you (or someone else) need to come back and fine-tune, you’ll be able to more quickly get to the right thought processes you need to update your SQL, procedure, etc.
Currently – as always – this is critcally important due to the security risks involved in your job since you work with data. Any security issues that happen will be absolutely vital to have documented, and just as importantly, any successful protection also needs to be able to be replicated.
This is especially true if you’re experimenting with a process to make it better – more efficient, more secure, more informative, whatever. How can you expect to improve upon a process if you don’t actually know what you did to make it better? (Spoiler: probably you can’t.)
Document. Document. Document.
It may seem tedious, but do your best to have every step of unfamiliar processes documented, especially. Those you can do with a blindfold on are clearly not as vitally documented, but always good to write down if you can, in case you have to have someone else perform those processes for you.
This extends beyond processes, too. Think about the ways we arrive at conclusions drawn from the data we’re working with. Think about the ways decisions are made based on that information. If those processes behind those actions are not documented, learning from them is going to be much more difficult. It’s important to remember that it’s not only a matter of “if this is wrong, we need to know what happened…” but also when things go correctly. Great report? Document it. Great query? Document it. Messed up result that you didn’t expect? Fix it, document what you changed, learn from it.
It may seem obvious, but sometimes we get caught up in the process and forget that we may have to come back to it later.
Happy experimenting!