One of the reasons a lot of developers get promoted at work is due to “knowledge of the system”. They know how everything works for a project, company or similar and therefore can perform tasks that brand new developers can’t.

On the face of it this seems to suggest that giving promotions to developers with this experience would seem prudent. I have begun to witness instances where this may well not be the case. As someone who has been promoted in the past where experience is a factor I can see both sides.

Any problems with this approach seem to begin when someone is seemingly able to “make things happen” so they get recognition. Tasks that some developers take a day to achieve can be done in a few minutes by an old hand. Is this person doing the task as well as the other guy and is the system such a mess that only people who have experience know the way through the maze. In an ideal world everyone should easily be able to make most things happen. Maybe a system shouldn’t need one person who knows it all, maybe it should be more manageable. If a system has been well built and the code well maintained, in theory any competent developer should be able to work on a system. The first few weeks of any large system are not going to be the most productive but 6 months in this should be the case.

When you get a situation that a system has been constructed badly and is hard to maintain, the person who has been their a long time has had to have had a part to play, in some cases “blame”. Therefore to promote them is to possibly en-grain more bad practices and reduce chances of the system improving. Thus it could be the worst reason to promote someone?

The counter argument to this occurs when someone has been with a company for a long time and  has been under immense pressure to get something out of the door from management and has had to make compromises to the standards they would have liked to maintain. Maybe they have now acquired the trust that is needed for them to argue for changes and be listened to. Maybe any new changes need a deep knowledge of the system in order to know the gotchas that will mean a restructure/refactor/etc is possible.

Thorough knowledge of the system also requires a very good memory, a skill not everyone has and is why you will meet some developers who have been with a company for a long time and don’t know anywhere near as much about a system. Often people who know systems have put themselves forwards to achieve tasks as well, another good feature.

I guess this post is going to provide little to no benefit to developers judging their peers but I hope someone who is having to make similar decisions from outside the development team, about a developer, might consider things a little more carefully.