Years of Experience
I’d like to point you to a blog entry by Johanna Rothman, What’s a Year of Experience? that clearly articulates a piece of a puzzle I’ve been having for several years. In recruitment and contracting, often a lot of emphasis is placed on how many years of experience a candidate has with X, where X is often a technology (less often a skill). Johanna gives the example of driving:
There are people who never learn from their driving experience in snow or ice. Every year, they’re surprised by the snow or the ice, and they drive too fast (or too slow). These people may have plenty of years of driving experience, but it’s the same year repeated over and over again.
I once worked in a group that had many years of experience programming C and C++. As I was a relative rookie at the time, I felt impressed at first. Until I found out that it was the same year over and over again… Yes, they were very familiar with the ins and outs of the language (those ins and outs haven’t changed in the eight years sicne that project, I was surprised to find out recently).
Unfortunately, they did not seemed to have learnt to work better as a team. At first, I was relieved that we didn’t have that many meetings, and I could ‘just do my job (programming)’ ( I’m different these days….). Until after a few months it dawned on me, that the team was chasing the same defects over and over.
This was easy to trace, as the group had nailed down several practices quite well. Every night an extensive suite of integration tests was run, and defects were collected in a defect tracking system (do you notice how I refuse to use the magical word ‘bug’ here?). Defects were closed and then later on re-opened. Sort of teh same defect repeated over and over again. In the end, the company was taken over, and this particular product was never released, because the new parent company preferred their own version of the product (how strange).
The group was very good at what they thought was their task – programming C with some ++. That is how they recruited new team members as well. I remember a conversation with my boss about a job interview. One of the things they did was see if the applicant understood certain language constructs. My manager exclaimed in surprise to me, ‘this guy did’nt even understand … (some obscure use of the C union construct)’. The uninon construct had at that time been made entirely obsolete by classes in C++. I was smart enough to keep my mouth shut, as I had never used the union construct much, and did not know about this particular use of it either. My manager was very happy about my performance nevertheless….
Years of experience had given her detailed understaning of the C union construct. What the team needed was detailed understanding of team working. Despite the groups individuals being highly intelligent (individuals had MsC’s, PhD’s, patents granted, creative testing skills), the group as a whole had years of experience of the same thing and did not function as a team.
What this group needed was not a new recruit intimate with language details… People can pick up details or entire languages quickly from working closely with teammates.
