Have a plan — My biggest Software Mistake
In continuing my blog series, I feel like it would be appropriate to rip the bandaid off and share a failure that has haunted me ever since it’s happening. This will be a less technical, straight to the point, post.
It all started at a summer internship. I remember feeling so mature: working in an office, getting paid, and doing what I love! A month into the internship my boss came up to me and said “Hey Jake, we have this in-house software written in Visual FoxPro that we would like to update into .NET, think you can handle it?”
Me: “Yes!”
My boss turned around, and the start of a crazy adventure pursued. Up to this point, I had never been tasked with creating an application from scratch but was beyond excited to begin!
The thing was, this was a summer internship, time was not on my side. I opened up the FoxPro source code and my jaw dropped. It was complete gibberish. (It might still be a useful language to some but please never again)
I also hadn’t worked with .NET before but it was similar to C++/Java so I figured out the syntax pretty quick.
In an effort to save time I thought, “you know what… I don’t need to translate this Hebrew-FoxPro source code, I can just make it from scratch with .NET!”
And so that’s what I did.
My ego was definitely at play here too — I wanted to prove to myself, as well as my boss, that I was a competent programmer. In my mind that equated to making this application as quickly as possible! I didn’t make a plan and went straight to programming.
Each day I came into work with a mental note of what needed to get done. “I need to make this query to get that data” or “This button needs to have a flashy design” or “This table needs to be saved to a CSV file”. I would set little goals, accomplish them, and move to the next mini-goal.
This strategy ultimately worked, I remember reporting back to my boss that I was “95% done” and just had to fan out a couple of bugs. He was impressed… I was impressed. But for the duration of the internship, the words “100% done” never rolled off my tongue.
I was 95% done, the application performed its responsibilities most of the time — however, every so often something would always come up.
It might be worth noting that at this point I didn’t know about the existence of Unit Testing.
With Unit Testing, a programmer can formally test routine, boundary, and challenging inputs into their code. In my case, I was lacking white-box testing.
Whitebox testing can guarantee 100% code coverage. This is possible because, with White-box testing, we conceptualize the outcome of every possible path.
Because I lacked this critical knowledge, I did not have the awareness to make my code efficient, cover edge cases, and most importantly — guarantee the outcome of the program.
As a result, I ended my internship with an incomplete project. This can be directly correlated with the fact that I “coded first, and asked questions later” (which should be considered a deadly sin amongst Software Engineers). I was fortunate enough to be surrounded by great leaders who were not harsh on me for my shortcomings, but I certainly learned a valuable lesson about Software Development.
Plan, ask questions, plan some more, and above all… code last.
