Today I had a new one; I bid to work on a project. It was short duration and limited hours. I won the bid … and I received an employment offer instead of a contract.

Obviously, there was a miscommunication somewhere. I’m not sure how but what’s done is done. At least they wanted me.

I’ve never had that happen before. I’ve had many clients seek to “convert me” to an employee (to hire me). I’ve had places that indicated they only wanted employees, but not this.

But it does bring up an interesting point. When should one use employees and when contractors?

Conceptually, contractors should provide resources for a duration. Otherwise, they’re an employee.

When contractors are re-classified as employees by the IRS the harm to the employer is severe. The IRS says “These were really employees, and you didn’t withhold the right amounts on time so we’re going to charge you penalties and interest.”

Microsoft was burned on this in 2008 and it sent ripples and fear throughout many major contracting consumers. I suspect it is part of why I don’t get to teach anymore as a contractor (and thus stopped being an instructor).

Trying to make sense of the taxes and legal risks is for a lawyer to talk about. I’m interested in the crafting side.

In building a large building such as a skyscraper contractors are brought in to lay foundation … and then leave; to erect the steel frame … and then leave; to place the glass … and then leave. There’s a recurring theme here: the contractors do a part of the work and then leave when their part is done.

This is the ideal use of contractors. They are specialists who do a specific task with a start and end … and then leave.

Once that building is built, there’s a maintenance crew who takes care of it. They hire contractors as needed for things they can’t do (such as replacing an air conditioning unit). But the employees have the recurring and unending job of maintenance and upkeep.

That analogy makes sense with software development as well. In fact, it’s also one of the fundamental distinctions of a project (projects have a start and end, whereas “operations” are unending).

As a metaprogrammer I routinely extract (or create) new frameworks, libraries, and tools for my clients. The software product that my clients are building use what I do (much like scaffolding) but they aren’t in the business of building or selling those things — they are in the business of serving their customers. My expertise fills a useful gap, a speciality.

I am always willing to train customers in how to do what I do; if they are a software organization that makes a lot of sense because they can task those employees to move between teams (on internal projects) to metaprogram. For a company that uses but does not sell software, it’s hard to justify developing one or more employees into dedicated metaprogrammers.

Employees should be the owners and caretakers of the company’s digital assets. Contractors can assist in creation and they might do very specialized repair work as needed but they should then leave.

This is often not how our industry uses contractors and it’s why Microsoft had many of their contractors re-classified in 2008 as employees.

Our industry has a habit of using contractors as if they were employees and paying via 1099 or direct corporate billing. This means no payroll deductions, no unemployment insurance, no vacation pay, no sick leave, all sorts of “benefits” to the company. You see this when the contractors don’t have a transient project role but are “continuing to continue” for long periods of time (or indefinitely).

For the contractor, this often seems at first like manna from heaven. They have a client that never ends and so they aren’t continually moving from project to project and going through bids and interviews and such. Who wants to market, right?

However, there’s a dark side for the contractor. They have an employee profile … same job and technology years on end. They often don’t practice continuous learning (since they’re “booked solid”) and when eventually they are let go (which is  inevitable) … they are no longer capable of earning high rates because their skills are outdated.

My value to customers absolutely hinges on my nomadic continuous learning caused by serving on a variety of projects.

I have been required to learn adversarial thinking when doing cyber-security work so I automatically now ask “How can this be attacked or exploited? What are the vectors? What are the consequences?” If I’d spent a decade doing cyber-security instead of a project I would be an awesome nuclear cyber-security guru … and unable to translate my work easily to asking “What might the SEC might worry about?” when moving on to a financial company.

Many people are very uncomfortable with constant uncertainty, even indirectly! I have been asked “What will you do if you can’t find projects?” They were honest questions, the people were worried for me. I mean, wouldn’t it be bad?

Well … I’ve been doing this for decades. There’s always awesome new projects over the horizon. I’ve been on many and will be on many more. I know that … not just “hope for it” but I know it. I make it happen. If I didn’t know it and make it happen the stress would destroy me.

More amusing though is that I wouldn’t survive as an employee.

Sure, I would “know” I had a paycheck coming on a certain schedule. I wouldn’t need to seek a new project every few months.

But I’d be trapped; I’d only be able to travel on weekends, maybe. I would have to wake up with an alarm clock every day. I’d see the same technology day in and day out. I’d have to get permission to do things (such as build/release open source) because my work would belong to my employer.

And my horizon would shrink; I would become a useful maintenance developer, knowing the code and fixing problems fast from my intimate daily knowledge of that same code-base. But I would no longer be able to see the big picture and recognize opportunity for sweeping changes using different approaches. I wouldn’t be as valuable as I am right now and that would be me dying inside every day.

Fundamentally, I’m a nomad. I love travelling to new places and meeting really great people who are awesome in their fields. I learn tricks and tips from every developer of every project I’ve worked on. As a nomad I don’t just “practice” continuous learning but I embrace it out of need and passion.

That is why I’m a pure contractor — I help by filling specific needs and then I leave.

Our industry needs both employees and contractors; it needs contractors who are absolute experts in fields that are important but brief and it needs employees who have a long-term investment in their employer’s products and traditions.

To my fellow contractors: if you’re an employee in disguise drink the kool-aid and become a W2 employee. At least be honest with your employer and yourself.

Keep the Light!