Sometimes I Screw Up... And That's Okay

 So, a recent project I worked on... 

So recent as in, MANY MONTHS AGO. 

So I worked on this script to assist with an installation process and I modeled this based on the involved components but there were a very few systems to perform a full process test because we don't have "spare and expendable" test environments. This bothers me, and I really need to do something about this. 

Aside: TIME! It's precious! 

The components and testing worked and I worked with the team to get this ready-to roll. It was working...

BUT! 

Some version changes occurred, the data collected by my processes changed, and it broke. This is expected on an involved system and siloed teams. Communication and feedback are essential and sometimes a change to a product upstream will impact the downstream in unexpected ways, even a small and trivial change like the way a version is displayed in a report.

This is expected, I knew about it after the fact and expected it but had not coded for it, - < insert joke about installing esp.dll here > - this perhaps unavoidable but... its fine. What I didn't do it remember every aspect of my code and how I assembled it! This is why you comment your code. So the next guy who will be working on it can read and understand what you were thinking, even if the next guy is you.

So, we had this data issue a couple of weeks back and it broke the process. I fixed it, or thought I had, but it was failing to pick up version numbers properly. I connected a few dots and it looked functional, but because I didn't have a full environment to run this implementation against I didn't catch that I screwed up and read the wrong file for the data, not finding the information I needed and leaving it equally as broken. This is on me. 

Admit your vulnerabilities and learn from your mistakes.

My vulnerability is that I sometimes forget what I was thinking when I coded something the first time. Again, this is where documenting your code comes in, but there's more you can do, and I do this for the most part but not this time, document your code on a shared resource like Confluence so that the people around you and the usage can understand what it is, how it's built and will understand what the components and requirements are.

Some coders are masters of self-preservation by obfuscation or writing code that's intentionally convoluted and cryptic, there's a time and a place for that (NSA), but in general you are not an island unto yourself, you are part of a team and documenting what you do in the event that you're hit by a bus is important.

Or, when you coded something and went on to other projects that supplanted all the processes and inspiration you had in mind and just don't recall the code under a crunch.

So, I fixed the code last night, but the time it took to re-discover the data flow between the moving parts was too long and my screw up, not recalling all this, could have been solved by these things.

• Always build and ensure you can destroy and restore a development environment.
• Always document, perhaps even workflow if not draw out a data flow model if there are moving parts.
• Always forgive yourself for screwing up as long as you can apply the lesson learned to doing things better next time.
• Also, OWN IT! When you make a mistake, own it, report it to your management as necessary, but take responsibility for it.
  

So, my next step(s) are in the insight above. I'm going to review the code and document the code itself better. I'm going to document the code at a high-level to explain the interactions with other data sources and dependencies on our Confluence system. I will build a test environment that I can build, update, destroy and recover so I will not be caught out again.

Have a great day and keep coding.