Because developers don’t get “do-overs”

On Friday, at 3:30pm, having completed all of the coding tasks that had been asked of me, I decided to start investigating a new item upon which I planned to work on Monday.  This week, however, was a special week – a turnover week.  This meant that within the next 12 hours, all of the major code changes that had been written, tested and approved would be migrated to the production systems.  As part of this special week, my project lead asked that we refrain from checking in new changes, in case they had a last minute issue they needed to debug during the turnover.  This always makes me nervous, since the source code management system (Subversion, in our case) is used to track and preserve code developed by the many contributors on the various software projects.  It would seem to me that use of the Subversion system is sacrosanct in any software development environment, but who am I to disagree with folks more experienced with the turnover process.  Well, you can probably guess what happens next…

At 3:40pm, after opening up one of the files I would be modifying next week, I noticed that there were changes to this file.  Visual Studio occasionally injects unnecessary changes to files due to the code/designer file relationship.  I hate to maintain these changes and often revert the file back to its original state after I open it.  Almost instinctively, I right-clicked, selected “Revert” and happily began to inspect this code… until I realized that this was the key file that I had been modifying over the course of this week.  Subversion does not offer a way to “unrevert,” assuming that explicitly reverting is always intentional.  Visual Studio doesn’t recognize the “Revert” command because it is the result of an add-in tool, so there’s no “Undo” at the application level.  In one second, I obliterated several hours of code that I had written.  To add to the irony, I had just read this Dinosaur Comics strip during my lunch break.

The clock was on now.  To save face and avoiding looking like a jerk, I had about one hour to review the file, remember where and what I had changed, recode and validate.  Happily for me, most of the work time involved in this task was still in my brain, so I managed to get a working version of the file wrapped up by 5:05pm, just shortly before I had hoped to leave for the weekend.  Yeah, I know, you’re probably thinking that my story turned out rather anti-climactic, but here’s the kicker – this wasn’t the first time I had lost code like this.

Like all other developers, I am fallible… and hate to admit it.  I am sharing my story today because I believe that there is something to be learned from this (aside from the fact that I was a bit of a dumb-ass).  It has not yet come to me exactly what that lesson is, but when I figure it out, you’ll be the first to know.