Give the Previous Dev a Break
Developers don’t always get to start on a project from the ground up. Often times they inherit an unfinished project that was started by another dev, or they are in charge of fixing a bunch of bugs that the client found in someone else’s code. When a developer is in this situation and starts diving into the code to add a feature or to see what’s causing a bug, they are bound to find code that might not meet their standards. For instance, they might notice there is a lot of code duplication. Maybe they discover the entire application is crammed inside just a handful of files with no sound file structure. Or they might see a few large functions that contain several nested if statements making the functions extremely hard to understand. You get the idea.
For some reason, a lot of developers’ first instinct is to begin trashing the original developer’s code. They will immediately look at the git history to see who committed this “travesty” that has supposedly made their life almost impossible to live. They might call over their fellow devs and point out how awful of a job this person did. They will ridicule the previous persons inability to make functions with one purpose, or they will crack jokes about the “inferior” language chosen in which they wrote the project. In short, they treat the previous dev as if they were a complete idiot and they should be banned from the development community for life. They act like the previous dev did it on purpose to spite them. This practice is extremely unhealthy.
First of all, if you do this sort of thing, not only will it make you look smug and arrogant, it will cause team collaboration to come to a screeching halt. While your cohorts might laugh at your observation initially, eventually they will start thinking of how un-compassionate and unforgiving you are. I know when I hear someone raking another dev over the coals in this manner, I start to wonder what this person is saying about my code. Your co-workers will avoid asking you questions even though you might be the only person that can help because they either don’t trust you or want to risk the chance of you bashing them when you’re not around. They’d rather spin their wheels and get more frustrated on an issue than get help from a fellow dev.
Publicly trashing a previous developer’s code also creates a toxic environment. Younger devs (and maybe even some veterans) who are within earshot might pick up this habit or even worse think the industry is full of smug know-it-alls and will decide to bail on developing as a whole. Who wants to work with a bunch of egotistical jerks who think they are god’s gift to software development. I know I don’t. I want to work with respectful and helpful devs who will provide constructive criticism and help me grow as a developer and person.
Another reason you shouldn’t do this is because you wouldn’t want someone to call you a hack or a moron after you move on from a project. I guarantee there are several examples where you have contributed less-than-stellar code to a project. You might have been under the gun to get a feature out in time for a deadline. Sometimes you plan on refactoring some code that you’re not proud of but you never get a chance to go back due to budget constraints or you simply got burnt out on the project. The point is: We all make mistakes so give your fellow devs a break and fix each other’s code without the snarky remarks.
I can almost guarantee that every developer has been a little harsh to a previous dev on a project at least once in their career. We are all human. But the next time you open your IDE on a project that you are inheriting, remember you don’t know the circumstances in which that dev was working. Be compassionate and give them the benefit of the doubt. Realize that you’ve been there and you would want them to do the same when confronted by your code. Remember they didn’t check in that 40 row function to make your life miserable. Don’t forget that code standards change and evolve. Maybe the standards by which you abide weren’t the standards when the code you’re viewing was written. Or maybe the dev was new to the framework they had to use and didn’t have anyone to review their code.
There’s a famous programmer adage telling us to make the code cleaner than we found it. Let’s use that idea and make our work environment a better place than we found it by passing on the practice of being respectful and kind to those who programmed before us.