My past experience with recruiters has been at a level that I put on par with my recent experiences with newbies to my team.  Today I got this from a guy I know who just changed jobs through a new recruiting firm.

Recruiting Firm X is smart.  They sent me a giant gift basket to my job.. one branded coffee metal big mug thinger.. two glasses and a bottle of wine.. total cost probably not very high.. but it got noticed by my co-workers and more importantly the coffee mug has their name in a fairly noticeable fashion on it.

He's right.  It is a great advertising move on their part.  Especially if they had it sent to the front desk.  Inevitably the overworked, under appreciated receptionist had it sit there for an hour or more.  That whole time people came and went and saw the recruiting firms colours and name.  Once the receptionist found the time, the basket had to be packed through the office, past a bunch of prying cubical gophers who wanted to know one thing only: who got the pressie?  By the time that basket reached my friends desk, the recruiting firm had generated a great deal of buzz...which is exactly what advertising is meant to do.

What I like the most about this is that they sent booze to the work place.  It's almost a free ticket to get drunk (or keep your morning vodka and Cheerio buzz going) at work.  This guy was talking about how great a marketing idea it is that the recruiting firms name is on the coffee mug when he walks around the cubicle maze during the day.  I say, what a great marketing ploy to have a developer walking around the cube maze all day with a glass of wine in his hand!  Who doesn't want to be associated with a group that empowers you in that way.

Anyways...I had to get a positive story about recruiters out there on the web.  There's more than enough bad ones, let's not forget that there might be one good one...is Agile Recruiting in Calgary it?  I dunno, but I like the booze part of them already.

I had an experience today that made me...well...flat out fucking angry.  When you start working with a new team, on a new project, at a new company...heck whenever someone can point at you and call you the "new guy", you need to be very careful with your desire to impose your belief system onto the group.  The only time that this is acceptable is if you've been brought in to impose change, but even then you usually will want to wade, not dive, into the pool.

Today I had to work with a relatively new-to-our-team person.  The previous work that this individual had been doing was being raved about.  I believed it.  Last week was my first time dealing with this individual and the experience was mixed.  I don't mind a good throw down verbal argument about different ideas.  I certainly don't back down from them if I am passionate about the topic.  We had one last week.  The topics is irrelevant, but I was disappointed when he simply walked away from it after making his point, but not defending it when I challenged it.  Maybe it triggered some kind of carnal notification of weakness because today I had the need to get aggressive with him and I went after him like he was the falling behind, sickly gazelle you see the hyena grabbing on Animal Planet.

There are some things that get me excited.  Some get my hairs to stand on end.  Others, well, they just make me flat out mad.  One thing you never do is spend 2 days on a successful project and then declare that it's practices are incorrect *unless* the practice in question is impeding the project's ability to improve on it's current state.  This individual today declared that an automated build script was a waste of time, that he wasn't going to maintain it and the fact that his most recent checkins breaking the CI server weren't his problem.  Like I said, there are some things that just make me mad.  By this time all the buttons were pushed and I was in full hunt mode.

The things that he was fighting for were fundamental practices that many of us won't do without anymore.  Automated build scripts, Continuous Integration, checking in code that isn't broken, having succeeding tests.  All of his arguments for why we needed to remove this standards from our project boiled down to him not wanting to change his ways.  The F5 compile and one assembly per csproj file was the only possible way to do things.  These are practices that I hold near and dear since they have helped me to significantly improve the delivery of every project I have used them on.  So that made me mad.  But I turned irate when any challenge to his belief system was met with either silence or "This is what VS is for".  If you're going to show up at a gun fight, you'd better be willing to shoot bullets, not blanks.  Simply having cartridges ejecting from the rifle doesn't mean that you're in the fight.

The thing that really set me over the edge was when I was told "I'm really surprised by you."  When I asked him to elaborate (in my own special profane way) he wouldn't.  If you're going to get me mad and then call me out, please step up to the plate with a set of fucking balls.

Since ending the call the thing that has fueled the anger more is that I just spent four days training on these things and this guy was in the room.  It's obvious that he didn't pay any attention.  Note to never have internet access in a training room again.

Anyways, nothing good came of it other than the fact I reverted back 3 checkins that this guy had made and told him to spend the weekend learning nAnt and TortoiseSVN since we weren't changing what was already working.  I'm pretty sure that Tom is regretting leaving work 30 minutes too early now too.

That should be enough venting for one day.  Thank god it's the weekend....and that I have a good scotch.

I had a conversation the other day with Tom Opgenorth about the trends you see when you're ending a contract with a client.  Our experiences both show that during the life of a project the client will usually (painting with broad strokes here) talk like they want to learn, understand and be competent with the project.  Most claim that they want to grow that knowledge during the life of the project so that, at the time of your departure, they will have the ability to smoothly transition the work.  Rarely does this seem to happen. Instead, the end of your tenure on the project comes and the client scrambles to ensure that some knowledge is transferred so that they have the minimum level necessary to start getting up to speed.  It's always a mad scramble and the client is left with a huge disruption in the project as a result.

This is where bricks and sponges comes in.  It seems that the client (or the employer if you're an employee on a team...it happens their too in our experiences) is a brick while they're on the project.  They're porous and quite capable of absorbing, but for some reason they also repel the knowledge they need to absorb.  When it comes time to transition off of the project, the client all of a sudden transforms in to a sponge and tries to saturate themselves as quickly as possible.  While the metaphor doesn't work a hundred percent, it does fit fairly well.

I've not seen one project successfully transition with minimal knowledge disruption when a team member departs.  I think it's one of the major problems that we have, especially if we're working as consultants.  We have to find better ways to make our clients sponges through the entire life of the project so that we can pour the water to them gently instead of from a fire hose.  Some of that responsibility does rest with the client though, and there's not a lot that we can do to mitigate active unwillingness to constantly transfer knowledge on their parts.  If they don't have the desire or the correct motivations to learn during the project's live, all we can do is keep pouring the knowledge to them and let them do with it what they choose.

I know some of you are thinking that knowledge transfer problems can be mitigated by creating a lot of documentation or transition papers.  I say that it doesn't work.  Every time I've arrived onto a project that has claimed to have these documents, they have been woefully inadequate.  Worse yet, many were flat out incorrect.  Writing transition knowledge into a persistent state means that you have to continually update it to ensure that it's current state is correct.  Development teams are not prone to doing such tasks if they don't see any immediate, or very near, benefit from it.  That would indicate that writing transition documents at the last possible moment would be something that a developer would be willing to do, and that's true.  But leaving the creation of this type of document until the last moment is like trying to write a book about your project during the two week period between when you've given your notice and you depart.  There just isn't the time to do justice to all of the information that will need to be collected, organized and transcribed.

The only answer that I have for this is pushing the client to actively participate along the way.  Don't just say "We're using nAnt to do our build scripts."  Say that plus put the responsibility for changing, maintaining and enhancing the build scripts into their hands very early on.  This allows you to mentor them through the process of learning and absorbing the information that they will need to succeed in your absence.  If they consistently push back at you that you should be doing it all since you know it best, you have to push back.  If they can't see why you're forcing the learning experience on them, then you have to leave them to their own devices when the time comes.  You can't bear much responsibility for the success, or failure, of a project after you have left it.  All you can do is work hard to set it up to succeed when that time comes.