July 2024 Challenge: Learning from Mistakes

@Crystal Bruce so many examples! When I was first learning “OnBoard”, I was creating application forms, inquiry forms, contracts and checklist. I can't tell you how many times I had to test them out and fix, fiddle and change forms to make them work. I test test test now before I publish!

@Spring Velazquez, what a beautiful story and learning experience! Your boss showed that she was big enough to forgive and “not sweat” a learning mistake - as well as teach responsibility and stick up for her team. I always think back to my various bosses and which ones have been roles models for me. It's a rare treasure when you find that someone and you think, “That's the kind of leader I want to be.”

@Crystal Bruce When I first started in this field, I accidentally deleted a group of records that I thought had zero giving but in fact included a handful of our major donors! It was probably the biggest oops I have ever made on the job. Thankfully we were able to get a backup of our database and were able to enter everything back into the database but whew that was moment where I realized that I should always spot check lists before thinking my inputs were correct.

@Crystal Bruce This isn't a major blunder, but it's a learning moment. When prepping for a mail appeal at the end of last year, I exported a query of potential constituents to include in the mailing. Then from the exported excel spreadsheet I went thru about 3,000 names one by one to fine-tune the list, remove some names, correct any capitalization, punctuation, salutations, etc. After finally getting the list all sparkly clean for the mail house, I realized I failed to include the Import ID field in the query! There must be a simple enough way to import the final mailing list back into NXT so as to track who received the appeal and update the other data in the records but I haven't found it yet. Since then, I always include the Import ID as well as the Constituent ID in every query just to be safe! ?

@Crystal Bruce and everyone who's responded so far, there are indeed some great lessons here.

I am sure I have had an oops and learning moment related to the database, but none are coming to mind (my role is more limited and I don't handle imports/exports or global updates all that often.)

So, I'll share a lesson from my newspaper days. It was announced that George Stephanopoulos was coming to speak at an event, and I was the copy editor working on the front page (it was a small daily newspaper). I was so concerned about spelling Stephanopoulos correctly that I misspelled George (Geroge)! And no one else noticed it, either, until it was coming off the press. Oops. Lesson learned: proofread even the “easy” words!

@Crystal Bruce hopefully somebody else has hit on this but having an idea of proper test values when testing imports or any other functionality. I was doing some tests on our data intake software. To test this software I needed fake data; the fake data that I generated was maliciously interpreted by a colleague. though I did not experience much fallout because I had taken the steps to notify the stake holders what I was doing, I do know that there was quite a few discussions held without me.

string :Test

integer : 123

Date: 14/32/9999

make sure your test data will properly create expected validation errors (and will be obvious when it does not; indicating a validation problem)