A few people have asked me lately about what I think about the working life of a contractor; having worked as a freelance .NET “person” for a little over a year now, I am by no means qualified to give a definitive answer to the question, but I tried my best. I have at least worked on the other side of the fence for a number of years as well, as a permanent member of staff hiring and working with contractors, so I do have a little perspective there.
In my discussions, I continually came across with what appeared to me at first to be contradictory statements. Some were related to job security and finances etc. – I want to ignore for the moment. Others revolved around the more day-to-day job role contradiction, a simplified version of which essentially is something like this: –
Contractors get the donkey work whilst permies do the fun R&D stuff
Permies often have to support existing brown-field apps or get bogged down in management stuff; contractors work on green field apps, often on the latest technologies
The two statements appear to directly contradict one another; how can this be? You probably have experience of both of them yourself (either personally or with others). In my experience both are true, but for different circumstances: I believe that there are actually two types of freelance developers. Both appear initially to be the same animal but on closer inspection there are subtle differences between the two. I like to distinguish them by calling the former description the role of the Contractor. The latter one is (or should be) the role of the Consultant.
The Contractor has no ego at all, and is willing to do any role required of him by his client. He or she will (or should!) not complain about doing the aforementioned “donkey work”, but nor will he or she often get involved voluntarily in offering suggestions for ways in which to improve process or code base etc. They may occasionally do a sort of work-to-rule, where they do their core hours and no more. Their primary role should be used for manpower as needed when short handed etc.., on short notice and as such their role will last as long as required by the project. Avoid giving these individual key business knowledge and ensure that they work closely with a permanent member of staff for supervision. If the project is long enough, where possible they should be supplanted by cheaper, junior permanent developers who will grow within the company.
The Consultant should be used as required on projects / in companies in order to bring expertise to the team – perhaps in a particular technology where there is a skill shortage in the team, or to help with improvements in process etc. They will actively voice concerns and raise suggestions within the team where they notice room for improvement; likewise, they should not be used as a “code monkey” developer. Their primary function is to fulfil a particular skill shortage in which they are an expert, and transfer skills to the team in order to improve them, whilst also offering a talented development resource as a secondary. They should not be used in a long-term role for a single team.
I would consider neither role to be “better” than the other one; rather say that each one fills a different need of any given project. Part of this may only become clear after the freelancer has begun his role after they have settled in and evolved into a position; other times the role will be clearly defined beforehand.
If you work with contractors, you will most likely have noticed the above two roles. It’s not a hard-and-fast rule – sometimes they get reversed due to circumstances or poor resource management etc., and all freelance developers have aspects of both the Contractor and the Consultant in them, but generally over a long enough time the two groups do separate.
So, if you’re a permanent member of staff and see a contractor doing “cool stuff”, don’t get the hump immediately – there might be a good reason why they’re doing it!