Eric Le Merdy

Learned today: do not blame non-agile developpers

Published by Éric Le Merdy

Do not blame non-agile developers

When welcoming a new team member, you could have this feeling that this guy could address a load of reproaches to your team previous work. For example, on the non-perfecteness of the development environment documentation. In this case, I am not pleased because 1) I do not believe in documentation that never get updated (I believe this is ood) and 2) I get my work in too much high sake to start hearing that it could possibly sucks (this is a personal defect). I prefer pairing with this new team member to install its development environment. This is has benefits in several ways:

  • to you, old developer on this project for too long, it reminds how painful it is to start with your poorly documented project where nothing is standard. You could be find yourself justifying your configuration crap and “we live with that until today so, you should be doing the same, new guy.”
  • this is the moment to get a brand new feedback on your configuration, your project sources organisation, your development platform. Listen carefully. Seems like this session can be more instructive for you than for him.
  • this is the moment where you meet someone, the moment where you do not know him enough to begin joking with him or hating him. This key moment to get acquainted before entering into a real pair programming session should be the moment to evaluate the developer’s culture compliance with your team's. From this first statement, you can guide further actions.

I have been find to be not tolerant enough with the team member today. I should be more comprehensive in respect with all the above benefits. From my experience, do not give the new team member a chance to not adhere to the team rules, especially when you use some XP practices. Enrol it to your very next task by pair programming. He will learn the project very fast and you will learn very fast from his experience.