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.

I am in another recruiting phase for a particular website. It has been a mixed journey so far. For technical types this will be a ASP.NET MVC website using TDD or BDD.

For cost reasons collocating in the UK would not have been feasible, I still think this is the most ideal solution if you have enough money. Therefore I have been trying to outsource the development.

I had started working with a company in the Philippines but their interest in the project waned when the necessity for TDD became a blocker, they had tried to recruit experienced TDD of BDD developers but seemed to have very little success. The next conversation was about training their existing developers but that proved too tough to pull off.

Since then I have advertised the job on odesk and had floods of applicants! This was not that surprising but showed the level of talent out there. The next challenge is working out the best value developer on the site to do the job, do you get what you pay for on here? At the moment I have some good candidates.

Another route I have taken is try to and find suitable candidates through linkedin.com. At the moment I have not had much response but I have been able to target the exact skills in certain of their groups. Recruiters have long targeted the groups I have been a member of and I will see how that route goes.

One other successful route I have taken, more for the design elements of the project, is my existing network. I am having the design done by an old employee in India. This is great as I know I can trust the level of work, however he is not able to work full time for me.

I guess this is not of much specific interest but hopefully will be of some interest to anyone looking to explore the different technical recruitment avenues available.