When am I ready for contracting work?
- by Kirk Broadhurst
What skills are required to work on a temp / contracting basis, and how does a developer know when they are ready to work in these circumstances?
I have some colleagues who are suggesting contracting work is 'the way to go'; the pay is significantly better. It appears that when a permanent position pays (X times $10k) per year, the corresponding contract position pays almost $X per hour - which is close to twice as much. I look forward to doing this type of work as an experienced expert, but worry that by doing so right now I'd be turning away learning and development opportunities.
My assumptions about contract work are the following:
less / zero money invested on training and development
less concern for job satisfaction and learning ("they won't be here in 12 months")
possibly less concern about the overall quality of the project ("we won't be here in 12 months")
There are similar questions on stack overflow at the moment but what I've really looking for is:
What does the developer give up by moving to contract work? Is it preferable to have structured learning in a permanent position rather than seat-of-the-pants learning in a contract position?
What skill leve should the contractor have before making the move? Is there still the same kind of growth in contracting that there is in permanent positions?
Rightly or wrongly, I see this as a choice between $ (contracting) and learning / development (permanent). Is this fair?
