I’ve been doing a fair amount of freelance/consulting work recently, and I had forgotten about the upsides/downsides of this type of work vs. a full-time job.
My first career – as a photographer (commercial photography, no weddings thank you!) – saw me working both sides of the employment fence (self-employed vs. employed, let’s say). And as in that field, as with computer work, there are pros and cons of both.
I had forgotten.
Leaving aside the monetary considerations (self-employed: worry about next paycheck, can decline jobs; employed: steady paycheck, have to worry about company politics to get ahead etc.) and focusing in on the technical/environmental issues, this is what I’ve found.
Some general observations:
One of the nice things – for me – about self-employment is the variety of work.
While one is obviously hired for projects in a targetted manner – often more targetted than full-time employment, where “the ability to learn” may be important – the target is often broad. You many be a Unix guy vs. an NT guy, or database person version desktop application developer. And so on. Usually some leverage, and often you’re hired to help provide a solution with no specifics mentioned beyond use this technology to do this.
The bottom line is that, since you’re exposed to more companies, you’re exposed to more technology, even if it’s the same technology (example: Do ASP at two different places; one may have heavy in-line queries and hand-coded pages, another may rely heavily on COM and have a handful of templates that params are passed to).
And that’s nice. I like that. I like to learn.
The downside is that if you’re employed at a company, there is usually an handful of technologies that you personally may or may not get to play with, but it’s a narrow scope.
So, if there is a call for, let’s say, a “randomizer” for something, odds are that:
- You already have code for this process from another project, or
- You have a pretty good idea of how to do it – at least a starting point – and it’s just a little messing around
Either way, the work will be done fairly rapidly.
On freelance projects, where there may be oddities to the technology (say, using mySQL, so the straight-forward use of a subselect to solve a problem is not available), things can be trickier. Sometimes it’s very time-consuming to get a solution to a trivial problem if one is not exactly highly familiar with the technology.
I ran into this a week or so ago, as I was putting together a proof-of-concept application in Visual Basic. I needed to write out some Word documents, but I kept throwing errors. Books, Web searches and all were not clear until I ran across something that explicitly said I had to make this (invisible) control part of the project or things wouldn’t work.
Added that to project, and life was sweet.
No I can do that without thinking, but it took me over a day to solve (no, I don’t have any VB friends…).
Familiarity is a good thing about full-time employment: Regardless of the technology used, you get very good – at least very familiar – with it.
At SBC, where we used Cold Fusion (NT) and MS SQL Server, I got thrown a curve one day way into an application. It fundamentally changed the way the system should have been designed, but it was too late for that. However, by the time the conference call that broached/confirmed this new, uh, “functionality” was over, I had framed out in my head how to do it and was well on my way to deploying it.
Just some typing and testing.
(Note: The curve thrown was so stupid and embarrassing [to me] that I’m not even going to mention what it is. But that’s another story….)
There are trade-offs to each mode of employment; for every pro you can probably come up with a similar con.
By working exclusively with, say, one database, you gain insights that you would not have if you only worked on it occassionaly. Say tricks with date objects, such as getting date differences. On the other hand, if you’re exposed to lots of databases, you’ll approach a problem saying “Well, in Oracle you can do this, maybe that would work here….” – something you’d never say/look into unless you’d worked with Oracle.
Working exclusivly with one technology may trap you in a certain mindset, but it puts you in the mindset to think productively that way. You can quickly fix a problem/extend an application. On the other hand, there is Abraham Maslow’s contention that “If the only tool you have is a hammer, you tend to see every problem as a nail.” And there is truth to that: You might be missing the obvious – to go back to the randomizer example, you might start constructing an elaborate script around a given language instead of just grabbing digits 6-10 [or whatever] of the time in milliseconds. Stuff like that.
Exposure to more technologies keeps you fresher (I think), but it also tends to make you less productive. Reference my stupid VB error.
Ironically, the prime benefits of self-employment – broad knowledge, ability to adapt and so on are exactly what are not needed on most freelance/contract jobs. These demand quick, solid, informed solutions (usually paid per hour or per project, don’t dawdle and play “what if”…). And companies are not really interested in “new ideas” from contractors, in general. They have a spec, they want it done in this technology buy this date for this amount and … that’s the end of the story. (Which I totally understand.)
And – ironically still – the prime benefits of full-time employment – such as deep knowledge in one area, familiarity with product you’re developing the technology for (cash register app for restaurants – food service experience is helpful…) are exactly what are often not needed in full-time positions. Often salaried, so overtime is not an issue, there is time to “think outside the box” (yes, I hate that phrase, but at least it communicates a concept well to most). Which is what is often needed – just because the company has always shared data between databases with scripts and FTPing files is no reason to not experiment with scheduled DTS packages or live replication. Contracters will see that; full-timers often won’t (or won’t want to try something new, because then they won’t be experts anymore…). Someone has to embrace new concepts – some that, admittedly, will turn out to be dead-ends – or companies will be running FORTRAN forever…
Hmmm….
As is often the case, I did not go into this blog entry with this ironic ending in mind, it just happened.
Interesting. To me…