I looked at my sprint and saw that a story was ready for testing. So I opened the story, read it and saw that the acceptance criteria said: "All you have to do is open x SQL script and run it." So I grabbed the script and ran it, and it worked perfectly... with no issues... the first time... WRONG!!

Here's Everything You Didn't Tell Me

You didn't tell me to run this script it required:

  • x database
    • y schema
    • z table
    • me to do a handstand and sing the National Anthem and then click the execute button

    Next Time You Want to Give Me a Script Here's What You Do

    First: Ask yourself the question, "What is this script trying to accomplish?". I know this sounds extremely basic, but a lot of people skip this step which leads to piss poor scripts. Sit down, think about it, and write it out.

    Second: At a very high level write out all the steps it will take to accomplish the goal from start to finish. I like to do this so I can see everything that needs to be done. This also allows me to quickly define what steps I am missing.

    Third: Start fleshing out each piece of the Second step. Finish your script one section at a time and check it as you go. Make sure you getting the result you expect. And write clean code. Remember... less is more.

    Fourth: Create this script so ANYONE can use it. Create parameters for the values that will be changed. Write good, clean comments that are understandable. Do not cater this to your situation, generalize it enough, so it will accommodate multiple paths.

    Fifth: As much as you can to the best of your ability, make this script self-containing. There is nothing more frustrating than running a script that has all of these unnecessary dependencies that could've just been a part of the script in the first place.

    Lastly: If there are indeed dependencies that cannot be a part of the script, in the name of everything that is good and pure, document the hell out of it. Don't make people have to guess or come ask you questions. That is time-consuming, frustrating to the person trying to use it, and annoying for you to have to explain it.

    If You Really Wanna Blow My Mind... Test It...

    Now I know that I could've just included this as a step in the prior section. But I really want this to sink into your brain.
    TEST TEST TEST your scripts. I can't stress that enough. Test every way it can be used. Test it on another machine. Test every output. Test every input. Please just test the dang thing!!! I am amazed at how many scripts I get that when I have issues with it, the person who wrote it says, "I didn't test that." Oh you mean you didn't test that this script does what you indented it to do ... FACEPALM!!!

    It Is Harder To Regain Than Maintain Trust

    This is the last piece I want to touch on this page. When you send garbage to someone, what do you expect them to think about you? If you received the same exact script from someone and had the same issues what would you think of them? How many screw-ups does it take for your boss, co-workers or friends to stop trusting what you are delivering?

    You never have to worry about those questions above if you start seeing yourself as quality. If you see yourself as quality, you will deliver quality. Stop settling for mediocrity. Stop gauging how well you are doing by the people around you. So what if another employee is doing seemingly good in the eyes of management. If that employee is delivering junk hold yourself to a higher standard. Be the standard that people need to catch up to, not the one catching up!