Today I read an interesting article through emails I receive from talentpoly and as a Developer It felt so right that I couldn’t stop my self to publishing it.
I want to share this good article with all of you. Just check it out at http://22ideastreet.com/blog/2010/02/02/guilty-developer-syndrome/
or below is the post content written by Anthony Panozzo as it is.
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.
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.
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?
Thanks to Anthony Panozzo for writing such beautiful article.