Skip to content

My Getting Better Moment

June 26, 2015

Many years ago when I was a young programmer, I screwed up. It wasn’t a normal “I spilled coffee” type of screw up, it was the kind that makes you dizzy when you think about just how much money it cost the company. This is the story of that screw up, and how it changed my mentality as a software engineer.

My first job out of college was for one of America’s big financial institutions. I came on board in the Spring of 2007. For those who don’t recall the events of 2007, do you remember the boulder scene from Indiana Jones and the Raiders of the Lost Ark? That is a perfect metaphor for the economy at that time. Indiana Jones was your average financial institution, and the credit crunch, congressional bills, and share holders are traps that could trip you up and end you at any moment.




In my first year, I spent most of my time reacting to financial regulation bills. I was given tasks, and I dove right in. The systems varied wildly. Each project had its own technologies and tools. One day I would be working in COBOL, and then next in C# (and yes, in 2007 COBOL systems where still being developed!) I would make a change and I would kick it over to QA, who would of course tell me if anything didn’t work as expected.

The cowboy approach paid off. I was praised for my ability to get things done quickly. Perhaps worst of all, it worked; At least for a while.

About a year in, I was given a task to write a data import process for one of our new systems. The system used a proprietary language written by a small company, which I’m convinced must have had the best salespeople in the world. The language itself was derived from VB6, and used a Caché database. I completed the task with little thought, and moved on.

Days passed, then weeks, and months. One day I was called in to my VP’s office. The VP was there, along with my team lead, manager, one of our senior programmers, and several programmers from the company that wrote the proprietary language used for the system. The second I walked in the room I knew something was very, very wrong.

Apparently, the data import I wrote, which originally ran in about an hour, was now taking about 10 hours to run, getting slower each day! After much research by the external company’s programming team, they found the source… my import. For each record that I was updating in my data import, I was also creating a new empty record in the database, and this was slowing the system down to a crawl. My hastily thrown together program had created hundreds of millions of empty records in the production database.

While the company placed the blame at the feet of the language and its vague syntax, I knew that I should have caught it myself.  My days of “conquering” a problem as fast as possible needed to be end. Code organization, architecture, readability, and testing needed to become my priorities if I wanted to continue to grow as a software engineer. I let books like “Code Complete”, “Clean Code”, and the Gang of Four’s “Design Patterns” help me redefine what being a good software engineer means to me.

So that’s my Getting Better Moment. What’s yours?

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: