Why your previous developer was terrible

And why your current one seems so amazing

Shamoon Siddiqui
Mar 24, 2014 · 4 min read

You hired a new developer for a project you’re working on and she seems to have solved all of your problems. She’s been on the job for 3 days and she’s already suggested upgrades for 5 of your libraries and re-organized your JIRA issues. At every turn, she seems to validate your choice in hiring her. She’s found 8 bugs that were glaring and would have caused a critical meltdown. How terrible was your previous developer that he couldn’t have spotted any of this?? She’s baffled by his decision to use the XYZ framework and doesn’t understand why he chose to use Postgres instead of CouchDB for this particular application. She complains to you that the lack of a CDN is costing you HOURS in needless content serving. How could you have been so blind to not see any of this? Well, it wasn’t your job, right? That was your previous developers’ job and he seems to have failed miserably. Good riddance.

The curse of the present

It’s what I call the “curse of the present.” When you, as a developer, look at the choices used to build a particular application, you’re blown away at the poor decisions made at every turn. “Why, oh why, is this built with Rails when Node.js would be so much better?” or “how could the previous developer not have forseen that the database would need referential integrity when they chose MongoDB?” But what you may not realize is that you are seeing the application as it exists today. When the previous developer (or team) had to develop it, they had to deal with a LOT of unknowns. They had to make many decisions under a cloak of opacity. You are cursed with the knowledge of the present, so the system seems like a hackjob of bad decisions.

Pass the blame


End it

Be a hero in the long run by being a solid team player that makes good judgement calls whenever you can. Don’t be the short-term hero that throws people under the bus. You’ll probably get away with it, but we (the developer community) won’t like you very much if you do. Now, granted, there are certain cases where the previous developer was a truly terrible developer. In those cases, make the stakeholders aware of everything all at once, rather than as a convenient excuse for you to use whenever you either don’t want to do something or can’t.

That’s my rant, and I’m sticking with it.

About the author: Shamoon Siddiqui is a serial entrepreneur, software developer, investor and public speaker in the NYC area. To get more awesome content like this, just sign up for my mailing list.

Things Developers Care About

My thoughts on the state of software development

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store