Guilty Developer Syndrome
I’ve noticed that when developers have worked on a project and then someone else takes it over, they seem to feel guilty about decisions made on the project. When I ask them why certain decisions were made, they might sheepishly say, “Yeah… I know it’s not the best way to do this, and it’s not the way I would do it now.” Some might get defensive, or cite external constraints like schedule pressure. But my belief is that developers should not feel strongly negative about older projects.
Experience
I’ll admit that I got a mulligan. It was a Ruby on Rails project for an internal tool. I hadn’t worked with that technology stack much before. I kind of hacked something together based on the requirements, and it worked fine. There were few tests, and the design definitely did not use best practices. But it worked.
Next, I worked on a six-month-long Rails project using mostly TDD. After that, an opportunity arose to clean up the internal tool and add some features.
It felt really good. I felt like I knew the environment so much better, and could see where problems in the code could be easily solved using better Rails or Ruby techniques. It was quite exciting. At times, I was surprised that the code actually worked at all. I think that most developers rarely get this type of opportunity unless they are on a maintenance project, and I do think it was a valuable experience to see the aftermath of my own coding.
Synthesis
But afterwards I came to the realization that developers shouldn’t feel guilty about producing software. There are always going to be new technologies and practices to learn, tradeoffs to be made, and hindsight clearer than the present view. Should I refactor this class now or later? Should I make this easily extensible, or are we truly not going to need it? What should we work on first to reduce the technical risk on this project?
After every book I read on a subject, I learn new techniques and ways of thinking about problems. But this shouldn’t stop activity in the present. I will never have one hundred percent of the knowledge I need, and the solutions that I come up will only satisfice the problem.
I’m assuming that developers are really putting their best effort forth. This doesn’t absolve the developer from learning from their mistakes or preemptively learning.
I’m just trying to say that developers shouldn’t feel bad because they didn’t know enough to prevent every problem or solve every dilemma in the best way possible. Seeing mistakes in the past for what they are just indicates growth. Getting it right every time implies skill stagnation or perfection. Which one is more likely?
Have you had an experience where you wish you could go back and change something on a software project? A time when you read your own code and cringed? Where’s the balance between getting things right and getting things done? Consider leaving a comment!
next post: How to Write a Work Journal
HAH! This post couldn’t be anymore relevant to my current position. Imagine, if you can, that you worked on a project for the past 3 years. Then, all of the sudden, you are tasked with training someone who you have never met on that product. They are looking at code you have worked on for the past 3 years. There were a few times where they would suggest a different (in their eyes, better) way to do things. But as you’ve stated…at the time, I only knew what I knew then. I never felt guilt when talking about these areas; however, I would feel a little defensive.
Honestly, I think most of my defense comes from the situation that we’ve been put in. But I can most certainly see how a developer would take it personally if someone “attacked” their code. Some of the implementations were called “confusing”…but I think once I was able to put them in the mindset that I was in 1-3 years ago…they understood the decisions that were made.
I’m pretty confident that I could change the way some things were written and improve them. But we got the job done, and it is a very working solution.
p.s. I enjoyed reading this post!!!!
I suppose every developer is in this position at one time or another, but I felt like I may have wrote parts of this for a second, or that perhaps you and I had very candid conversation at Brockway last time.
I work on an internal tool. It’s been around since before Rails version 1.2.3, if I’m not mistaken. It’s been around since before I had an adequate grasp of Ruby or Rails. It was built by myself and another programmer who was just learning Rails. It has some ugly parts. I still apologize for them when working with The New Guy.
The project is a living project that will not soon be put out to pasture. It is basically my job to maintain and improve it. That means I get the opportunity to correct the things for which I feel guilty every day. I think this has proven to be an incredibly valuable (and humbling) learning experience.
Perhaps one shouldn’t feel guilty, but feeling guilty means you’ve learned something. So, relish the emotion as a sign of progress, and then cast it away.
It’s hard to do, but I’m trying to embrace technical debt like in your example.
The reality is that if project X served it’s purpose, then you really shouldn’t feel bad. You could have spent more time on it 6 months ago, but it would have been another trial-and-error learning experience. Coming back with 6 months of experience (and possibly 6 months worth of better 3rd-party tools and libraries), you can improve things a lot more quickly than if you’d just tried to do it “right” the first time.
Even more, in that time, it might have become obvious that you didn’t even need the internal tool.
Of course there’s a balance to this thought, but I think good developers probably tend to drastically lean too far to the “perfect now” side. I definitely believe shipping is a feature
Martin Fowler wrote a post about Technical Debt Quadrants (http://martinfowler.com/bliki/TechnicalDebtQuadrant.html) The scenario you’re proposing would most likely fall under the Prudent/Inadvertent Debt (I did the best I could with the knowledge I had but in retrospect I would have done it this way). I think all kinds of alarms should go off if you look back at old code and can’t identify ways to improve it.
That being said, I’ve learned over the years that you need to let go of “your” code. Once you can do that, you’ll be able to learn more because you’ll spend more time discussing a critique than defending your code.