Photo Credit: Kalexanderson via Compfight cc
This summer I was lucky enough to get a chance to speak at a conference. I was giving a pretty hands on product oriented talk with live coding and the majority of the conference was pretty high level and abstract, but I like to think the folks that showed up learned exactly what my session advertised.
A little before my talk, I ran into someone I vaguely knew from an old job. I said “Hi” to him, excited that I actually ran into someone I knew. And it didn’t take him long to let me know that something I did eleven years ago was the worst thing he had ever seen. I was probably mentally incompetent. He looked down his nose at me, adjusted his fedora and walked away shaking his head.
I thought back to the genesis of this code that established me as a terrible human being. It was 2003 and I, as the sole developer on some “B2B software” had to integrate with a security product that was being mandated by our security organization. It was the first roll out of this software and the expert consultant we were given to work with didn’t know the first thing about HTTP or websites. (This was a WAM product, which means it controls HTTP access to websites.)
During the project and in previous projects I remember micromanagement of my coding style and approach, something our “architects” found bafflingly necessary. Part of the integration required some SOAP 1.0 and later 1.1 calls.[1] Oh, and the consultant was zero help with that as well. Once the project and the required gnashing of teeth was over, I turned the code over to one of our excellent framework developers. I apologized to her for the state of the code. It worked and was safe, but it was pretty awful.
She, of course, found herself in the position of needing to make that functionality available to a wider audience, but without a test environment to refactor the code against. Three years later I found myself responsible on the framework team, and for the code. Which now had hundreds of apps using it, and now couldn’t be refactored because every app team would scream bloody murder if they had to change the way they consumed an API as part of upgrading.
Fast forward another eight years and I am Idi Amin.
If you’ve worked in software long enough and have the ability to feel shame, I’m sure this has happened to you. You’ve worked somewhere that you have tight deadlines, the organization is in chaos, management are screaming thugs, and you’re not supported by real software processes. The result is bad.
I’ve been on the other side of this equation many times. You open up some source code and say, “What idiot did this?!” I’ve learned after opening my mouth to slam someone’s code one too many times: if you weren’t there, maybe you should lighten up and just try to make things better.[2] Historical blame isn’t doing anyone any good, though you might be boosting your own ego. Often the structure and state of the organization has more to do with the code being produced than the developer and most developers want to do a good job.
If you find yourself in either situation, try to focus on the constructive and making the organization better, it will make more of a difference long term.