I have picked up the pieces after some other programmer left a company in bad terms way too many times. Even though it has been a good thing in the long run because I have been able to make things work out, it did end having one horrible experience where there was just no saving the situation. The only constant during this process has been the time and money wasted during a painful transition.
I have yet to understand why companies will let a relationship deteriorate this way with one of their key players. Even worse is when an employee becomes disgruntled and ends up hurting not only the people that work at the company but everyone that will have to come after to clean up the mess.
On almost every one of these situations there was fault to blame whole departments. The worse example of these situations is when programmer X was there. I remember the blank stare on the manager`s face, he believed the last programmer was the ultimate guru that could solve any problem and deliver things on time with no plan. He needed no direction, only a problem and he would give you a solution. He was the lone ranger, a rogue programmer, why is he gone? Where did he go? Trust is a precious thing, but in a work environment it is difference between a successful project and a huge failure.
I am not sure if its human nature, but it seems that we are more willing to bury the truth than admit we are wrong. I actually was able to identify a programmer X once while he was still employed by a company and no matter how hard I tried to warn my manager he would not hear it. He is a genius I was told. He single handedly saved a project. The problem was that every single project after that “excellent success” had mayor problems. Actually even that brilliant gem of a project was a house of cards that was just waiting to be given a little nudge.
Be very afraid of a developer that does not care for the users. While we all have some issues with users at times not using the functionality that we work so hard to put together, they are still the ultimate consumer of our product. Be even more afraid if someone in upper management refers to users as pawns.
The most successful projects in my career are closely tied to making a product that not only managers liked, but that users thought was easy to use and made their job better. You have to be smart about the code that you write and understand how it is going to be use. There are rare instances when someone in upper management understands the business better than the people that perform the tasks, but unless they are still closely involved with the day to day make sure that you still have a way to check your product`s performance with the actual users.
That is one of the basic principles, beyond that you still need a solid plan to make a project work. I was very surprised when I experienced that a lot of companies are willing to just execute without a clear road map. A flawed database design overcomplicated code inside a program can spell trouble for the future of a company. When a company is willing to compromise testing time for unrealistic release schedules programmers will cut corners. Programmer X will most likely deliver, but they will be the only ones that can produce those seemingly magical results.
When a manager start believing that this programmer has magical powers is when we you know that trouble is just around the corner. Timelines become so short simply because the Programmer X is on the team that projects have no planning stage or testing. Pressure to deliver starts rising and not just for the Programmer X but for the whole team. This might be just my experience, but it seems that another quality of Programmer X is their ability to destroy teams. They do that when they talk in circles and shut down everyone else`s ideas. Also they point the finger on how their team just cannot deliver at his level and what is worse some managers actually believe them.
So here is my rant to Programmer X, funk you man! I am sick of finding out that you used technology you did not understand, tired of cleaning code that was complicated just for the sake of job security. A job security that you ended up leaving when the pressure of unrealistic expectations that you set yourself was too much to take.