Let's all go back in time to 2002. I was 11, sitting at the dining room table. There were papers strewn everywhere and a textbook open to the left side of me. It was dark outside and we had already had dinner for the night and my Dad was getting onto me about getting my homework done.

I told him I was done for the night and he came over to look at my math homework. I had completed all 30 problems and was ready to watch TV. Then he asked me ' Did you check your work?' My Dad asked me this every time I did math homework and for whatever reason, I always hoped that he would just forget to ask one day.

You see, I hated doing homework. Every night, there was some type of battle. My handwriting was bad, so some days, I had to erase everything and start over. I'd forget my textbook, so I would have to write 'I will not forget my book' over and over again. I would complete my homework the night before, lose it before class somehow, and then have to redo it the next night.

Now, this was way before I was diagnosed with ADHD and my parents were just doing everything they could to try and help me succeed. Eleven-year-old Courtney didn't see it this way of course. I thought my parents were being too strict compared to my classmates and I would have the worst attitude which actually made getting homework done take longer.

When I got old enough to understand addition and subtraction, my Dad taught me how to check my math. It goes like this:

Math problem:

2 + 3=

My answer: 5

I would then have to reverse the problem:

5-3=

My answer: 2

I was required to do this for all math homework until I graduated High School.

It wasn't until recently when I was trying to debug something I was unfamiliar with, that I realize my father had taught me a very valuable skill.

You see, debugging is exactly the same thing. You are retracing your steps (or someone else's) to try and figure out where things went wrong. Where in the math problem did the solution start to not make sense? I use the same principle as above.

1. Read the error message. 2.Follow the exact same steps as the user to see if I get the same result. 3.If I do get the same result, I find what tool is used to provide the desired action to the user. 4.I examine the formula, flow, workflow, or process builder that is causing the issue. I read everything and try to understand how the current solution works. 5.If I can debug (this depends on the tool you are using), then I grab the record that is failing and run it. This tells you where your flow failed so that you can research it further. 6.Fix what is broken and test it out again, until it finally works.

It may seem like this is different than my math homework, but debugging really is just checking your homework. Everything that we encounter is a problem that requires a solution and it's our job to provide it to our users. That means if instead of 2+3= 5 we get 6, then we must go back to figure out where we made the error.

I feel incredibly lucky that I was taught to think this way at an early age because it has been extremely valuable in the workplace. When you learn to evaluate a process backward and forwards before you execute it, you can find loopholes early and fix them before a launch. You can realize when you've made a mistake and find that mistake easily. You can build better solutions for your users.