Are you really as good a developer as you think you are?
Last week was a travel week for me which means I spent the majority of my week in Denver speaking with the architects and developers I work with. This trip was a big deal for me because I live in sunny Jacksonville Florida, and while I was in Denver it hit record lows, getting to -15 one night with plenty of snow. Now -15 might not be a big deal for those of you living up north, but here in Jax our lows rarely even hit freezing, let alone negative numbers. Most of us here in Florida can’t even comprehend what it means to live in temperatures like that. When I left Denver on Thursday it was 5 degrees, and I swore I wouldn’t return until spring.
While I was in Denver one of the developers pulled me aside, quite frustrated, and proceeded to tell me how bad the code base is for the product we are delivering in just a few weeks. The product we are delivering was built using an existing code base, more of a renovation project than a new construction. We made the decision to use it because the existing product met a large number of our requirements and to me it made little sense to develop a product from scratch when we had one that was already built. It wasn’t a stretch either; the product was originally built to do exactly what is needed – the problem is that it was built a decade ago.
The developer felt very strongly that we could have built the product from scratch by our deadline and that it would have been as good, or better, than the one we renovated. I listened for quite some time and, to be frank, he made some really valid points that made me question the decision to use the existing code base. In the end I explained to him that we chose to use the existing code base because, while it was dated, it provided a large amount of the functionality we needed for the project. I also believed at the onset of the project that there was no way we could deliver the functionality needed in the time provided without using the existing code base. I went on further to tell him that while his points may be valid, we need to just bite the bullet and wrap up the project on the existing code base. I let him know that I appreciated him sharing this with me and that I would take his opinion into account when evaluating the framework in the future, but nevertheless, we were committed to using this code base and would need to move forward with it.
Now while I feel my decision to use the existing code base was the right decision, I continued to think about our discussion for most of the 4 hour flight back to Jax. What kept bothering me was why this developer thought he could do such a better job than the developers that preceded him. His complaint was not that it was an old code base, but that the code itself was just poorly written, buggy, and difficult to work with. He felt that if he had written it himself it would have been much better. Could this developer have done a better job than his predecessors? Perhaps, as he is a pretty strong developer, but the question I kept asking myself was: why is that we as developers always think we can do such a better job than our peers?
Let’s be completely honest: have you ever met a developer (yourself included) that was happy with someone else’s code? Thinking back over my 20+ years of coding I can only think of a few occasions where I heard a developer, myself included, speak positively about another developer’s code. I wish I could tell you that it was my code that the other developers were raving about, but that’s not the case. Now think back about how many times you remember looking at someone else’s code and saying, “Wow, this is bad.” “Why in the world would he ever do this?” “What was she thinking?” “This makes no sense.” etc. It’s most likely quite a few times. Why is this the case? I think the answer is that developers have unrealistic views of their coding abilities. Now bear with me for a moment while I explain.
There are two types of code. There is the code we are capable of creating, our potential code if you will, and then there is the code that we create when we actually need to get things done. When we assess our abilities we always believe we will work to our potential; no matter what, we will write the awesome code that we know we can. But if we are being truly honest with ourselves, we must admit that sometimes this does not happen. There are times when we cut corners to get things done, to make our managers happy, and to meet deadlines. There are also times when we get to a point on a project where we just don’t have any more to give. There are even times when we know that there is still a bug in there somewhere but, the deadline is here, and we need to ship it. QA will catch it and we can fix it later. Sound familiar?
Programming, like anything that takes a lot of creative effort, is really hard, and can sometimes even get a bit tedious. In an ideal world where there are no outside pressures, then perhaps we are always awesome developers and we code to our potential. But in a world where there are deadlines, customers, project managers, meetings, more meetings, ongoing support and endless interruptions, then maybe we aren’t as good as we think. When we overestimate our coding abilities it isn’t ego or denial, it’s often because we just don’t consider the outside factors that will affect us. We always think of ourselves as the developers we want to be or could be, not the developers that we actually are. The developers we are rarely get to code all day without regard for outside considerations. We deal with the pressure of deadlines, meetings, customers and endless interruptions. Sometimes we don’t code to our potential.
So can we write better code than the developers that came before us? Well, perhaps we can, but the question is, will we? The next time you look at someone else’s code, put yourself in their shoes for a moment and don’t be too hard on them. Perhaps there were factors, other than skill, that impacted their code.
