Imagine yourself in a new job, eager to impress the higher-ups who made the decision to bring you on. You have all kinds of tools and quick fixes up your sleeve that are sure to cement your coworkers’ high opinion of you.
Before you get too gung-ho on changing everything about the current system, read this list of 5 mistakes to avoid from Why your previous developer was terrible by Shamoon Siddiqui.
- Suggesting new tools, processes, and languages
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.
- Badmouthing the previous developer or team
We’ve all been that developer that’s been blamed for countless problems after we leave — it doesn’t feel very good to know that it’s happening to you, so why do it to others? Take the moral high ground. Even if it is the previous guy’s fault, don’t frame it like that.
- Seeing the current system as poor craftsmanship
[The previous developer] 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.
- Passing the blame
If a developer doesn’t want to work very hard or solve a particular problem, it’s far easier to blame something inherent in the system rather than laziness (or incomptence).
- Making large changes before understanding the system
Developers tend to think that a great way to [justify they’re worthwhile] is by making BIG changes early on. Implementing all sorts of processes that don’t need to be implemented and introducing all sorts of tools that no one else on the team has heard of.
Avoid these 5 pitfalls to become champions in your current company and the developer community. It will pay off in the long run (and keep you looking on the bright side).
Read the full post from Siddiqui over on Medium.
