“Been there, done that” is a dangerous phrase in software engineering.
I recently watched Ben Orenstein’s talk “Refactoring From Good to Great“, and it got me thinking about how easy it is to become complacent with your code, design patterns, and solutions. If “been there, done that” is your attitude toward the problems you’re faced with, then either your project is the most boring project in the world and you’re simply a code monkey, or you’ve stopped learning.
At the beginning of my career as a software engineer, when presented with a problem, I would bang my head against it until I came up with a (usually hack-ish) solution. I would then proceed to implement it and, if I got around to it, I might write a few tests. For instance, one of my first tasks was to write a converter that would take XML in one format and convert it into another format. I had never worked with XML before. I had only been a professional for a few months. I treated it as a series of small problems (How do I read the attributes of a node? How do I convert those into the other format?) without taking the overall design of any part of the solution into account. The resultant code was horrific, but it (mostly) worked. Does that mean that, when presented with a problem involving parsing or creating XML, I now can say “been there, done that”? Of course not. I know so much more now than I did, and it would be embarrassing to produce code of that quality again.
“Been there, done that” is not a pass to be complacent and mindlessly write code you’ve written before. It’s an opportunity to show how much you’ve grown and improved. Because you’ve seen a similar problem, much less time can be spent learning the domain, and much more time can be spent doing it “The Right Way”™. You may be saying to yourself, “But I’ve already solved this problem ‘The Right Way’™, so why shouldn’t I just repeat the same solution?”. My answer would be that software engineering is fluid. It’s an art. No two systems are the same, no two applications identical. “The Right Way”™ of the past, may not be “The Right Way”™ of today. Maybe it is, but you do yourself a disservice if you don’t devote at least some thought into solving the problem in a more efficient, maintainable, and/or elegant way.
“Been there, done that” is an opportunity, not an excuse.
