> and directing them as to how they should do they job
This is, to me, a very puzzling take. If you hire a contractor, you don't direct how they do the job, only what the job output is like. Hourly contractors are certainly a thing.
I'm still confused how you can avoid tell someone how to do their job. A SW contractor can't be told which language to use or be connected to company source control or use existing company software libraries? A carpenter can't be directed in some fashion beyond: 'YOU, GO BUILD HOUSE FRAME'.
I did software contracting for a while. It’s certainly appropriate to define parameters like “use language x, code these features, by this deadline and keep a synchronized copy of the code in this repo.”
You can’t set hours and direct particular tasks day to day.
Having personally been through the employee vs contractor maelstrom when, for some unknown reason, the state government got a bug up it's ass, I'd have to say that the state requirements become quite arbitrary.
What you might think is appropriate is sort of besides the point.
I too have been through the maelstrom. What I think is appropriate for me as it all boils down to interpreting the IRS regs and hiring a good lawyer who successfully avoids and navigates lawsuits for me. Just because I navigated it successfully doesn’t mean I’m right or my interpretation is appropriate for all.
But I think it’s pretty useful and certainly disproves that it’s not possible to hire software contractors.
This gets into a big grey area and I’m not sure there’s an absolute rule. If I were writing the contract I would say “must pair program with employees” and let the contractor figure iut how to meet the req.
You can tell someone to "do this work". You can only tell an employee to "do this work, at this desk, using this computer, for 8 hours between 8 AM and 6 PM every weekday".
You can tell someone to "get it done by the first of the month or suffer a penalty". You can only tell an employee to "get 5% of it done every workday and send me your status metrics by 10AM every morning or you're fired".
You can tell the carpenter what the work is that must be done, and provide detailed specifications, but if there are multiple ways to get that work done, you can only mandate those details for an employee. To some extent, building codes establish a minimum standard that everyone should be satisfied with, and you could tell an employee to do the minimum amount of work required by the building codes to get the job done, but you can't stop a contractor from carving Mayan-inspired engravings into every stud if they feel like that's what the job requires, or from using glue and joinery where most people would just put framing nails. As long as the work meets the specs, the contractor can get there by any route they please, no matter how much or how little actual effort is required.
Uber can tell its driver to "to collect this fare, get this passenger to this location". When they start saying what kind of vehicle they have to use to do that, they are starting to move into employee territory. Clearly, a passenger can be moved from A to B by a restored and retrofitted tie-dye-painted 1970 VW minibus as effectively as a nearly-new factory-stock black 2018 Toyota Corolla, so when Uber is making requirements that speak more to their company's brand identity than to the reasonable requirements of the job, those are employee-like requirements.
It isn't always clear whether a requirement is directed more towards the means or the ends, because specifying an end result precisely enough may dictate that the only practical means to that end be used. So California has decided to resolve this exploitable ambiguity in favor of assuming certain types of worker are employees unless a minimum degree of autonomy can be demonstrated.
This is, to me, a very puzzling take. If you hire a contractor, you don't direct how they do the job, only what the job output is like. Hourly contractors are certainly a thing.