Software Engineer: Permanent or Contractor?
Pros and Cons of working as a Permanent or Contractor.
For a software engineer (including SDET), there are mainly two choices in terms of work:
A Permanent employee
Employee (I will use this term in this article), or informal: “Permi”. Paid by annual salary.A Contractor
paid by the hour/day.
Both have pros and cons. I have worked both for a number of years. This article shares my views.
· Contractor Earns More
∘ Zhimin’s Simple Hour Rate to Annual Salary Conversion Formula
· Employee Has More Benefits
· Contractors are considered more Technically Competent
· Contractors can do side projects
· Less overtime for Contractors
· A Permanent Employee is not “Permanent”
· Higher Pressure work for Contractors
· Contractors can work with more projects and more people
· My Advice: Start with an Employee for a few years at least, then become a Contractor
Contractor Earns More
IT Contractors are paid at a daily or hourly rate. This rate is usually 30% — 50% higher than the employee who performs similar tasks. Let’s be direct, for most people, money is №1 considering factor in choosing a job. So when there are two job offers, one Employee and one Contractor. How do you compare the money offered, one is an annual salary, and the other is an hourly rate.
Zhimin’s Simple Hour Rate to Annual Salary Conversion Formula
Hourly Rate ✕ 2 ✕ 1000 = Annual Salary
Then multiple a discount factor, e.g. 70%
For example, an $80/hour contractor job, is equivalent to a $160,000 salary employee job at best. 80 x 2 x 1000 = 160,000
.
Assume you work 40 hours per week and 50 weeks (extremely hard working) a year. The total (maximum) money received: 40 x 80 x 50 = 160000
. Then assess the permanent job offer, then multiply a discount factor (more employee benefits, lower discount factor). 70%
is a good discount factor to start with. For example, for a 69%
discount factor, an $80/hour contractor job is equivalent to a $110K permanent job, from a pure income perspective.
Of course, this is just a rough and quick calculation. Once I created an Excel spreadsheet with this formula, a few contractors liked it.
Employee Has More Benefits
There are many employee benefits, depending on the company, of course. That’s why companies are willing to pay contractors higher rates. The common benefits are:
Job Security
Paid holidays and Annual leaves
Career (Promotion)
Health Insurance and other medical covers
Training
(it seems to get less nowadays)Stock options
Transport and other allowances
Having a long-term relationship with some of your colleagues
(better emotional support. Contractors, on the contrary, hard to build long-term work friends)Redundancy package when gets fired
A story about Career of two BAs
I once joined one large IT firm and happlily see one BA, whom we worked together several years back. One day, I saw the BA talking to the Vice President (VP) quite closely. Later, I learned the BA and the VP worked in the same team ~5 years ago. The BA was a better one and moved on to another contractor role shortly after. When a postion was open, the VP got promoted to be a project manager and then program manager.
The CEO took the management team to join this large company, so he became the VP. The last time I checked, the VP is a CIO of a medium-sized company.
If up to me to judge the capablity (leadership, writing, speaking, and personality), the BA is better than the VP.
Contractors are considered more Technically Competent
In the software industry, people generally consider an IT contractor to possess high-level technical skills. One simple reason: he/she has the confidence to find another job every six months.
I am talking about the contractors in a general sense. There are some be-one-place-forever contractors, who are really an employee, but somehow negotiated a deal to earn more money. Maybe due to his connection or a unique skill set.
A story of be-one-place-forever contractor
I clearly remember one. Simon has worked in this government department for over 20 years. The first 10 years as an employee, later became a contractor. Our system is an old main-frame, the core work is to around the proprietary databse created in decades ago. Simon knew the database very well. He may be a little arrogant, but he really knew the stuff and was helpful. I quite liked him.
In 2013, our state health payroll system embrassingly failed (led by IBM). The expected cost: A$6.9 million, ended up with A$1.2 billion. As a result, staff cut in all state departments. Simon’s contract was terminated .
A few months later, Simon was hired back under differnet terms because of his knowledge of the database. He told us, he could not find any other jobs, he only knew this database.
Contractors can do side projects
In the “Silicon Valley” show, Richard, a software tester at Hooli, developed revolution compression software. The company Hooli used an army of lawyers to sue Richard for his Intelgicla Property (IP). While an employee can still work on his own kick-ass software, be careful (don’t work at the office and use any office equipment to develop the software), as things can get a bit scathy.
In the “Silicon Valley” show, Richard was a genius, coding at least 100X of developers at the top IT firm: Hooli (hinted Google). Richard was working there as a not-appreciated QA Engineer.
“In my experience, great developers do not always make great testers, but great testers (who also have strong design skills) can make great developers. It’s a mindset and a passion. … They are gold”.
- Google VP Patrick Copeland, in an interview (2010)The show is about Richard quitting Hooli and building a start-up.
If you dream of building your own software company or a Micro-ISV (Independent Software Vendor), being a contractor is the way to go. In fact, it is common that the initial funding of the business is from consulting (a fancy term for contracting).
Less overtime for Contractors
Overtime is common in the software industry, for permanent employees. In some countries, a 60-hour work week is normal for IT workers. Some IT companies went too far, such as the 996 working hour system: “work from 9:00 am to 9:00 pm, 6 days per week; i.e. 72 hours per week.”
I have been contracting since 2000, and from my memory, no more than a handful of overtime work. Why? The company has to pay me by hours. If the overtime is on weekends, 150% or more. I remember I got it once or twice.
The most recent overtime rates set by the Australian Government: “150% of their minimum hourly rate for the first 2 hours, after that, 200%.” But this rule does not apply when you agree to work overtime in the employment agreement.
“No overtime” is definitely one thing I like about contracting.
A Permanent Employee is not “Permanent”
My friend Chris once said: “The difference between Permi and Contractor in terms of job security: 4 weeks vs 2 weeks”. He is more or less correct.
In the software industry, only a small percentage of staff have worked one place over five years. Some moved on, some got fired, or the company closed.
To benefit each other, there are notice periods for both the employee/contractor and the company. The difference is: Commonly, two weeks for contractors, and four weeks for employees.
So, the meaning of “Permanent” does not really exist. The most “permanent” you can get are government jobs, still, I have seen laid-off in governments.
Higher Pressure work for Contractors
As a contractor, people expect you are ready to work quickly and perform well. That’s OK for me. One thing that I felt quite uncomfortable with contracting is that I need to re-prove myself again in a new team, maybe every six months.
Occasionally, there will be an anti-contractors movement among the employees. Some movements started within a team, some started from higher-ups. When that happens, contractors feel a sense of lacking belongings. Aways a few short-sighted employees saying something silly, as they only care about the difference between their salary and a contractor’s rates, ignoring all the benefits and so on.
Contractors can work with more projects and more people
I personally prefer contracting, as I get to work on more projects, use/witness more technologies, and especially have more chances to meet really great people. I could program well with Java, C#, C++, Perl, JavaScript and Ruby, on Linux, Windows or macOS. I related that to my contracting experience. This is not just about the skills, but more importantly, an open mindset.
In 2005, I, for the first time, witnessed real test automation and Continous Integration by pair-programming a world-renown developer on a contract job. Also from him, I heard of Ruby (then self-learned it). This totally changed my career (for good).
When I provided test automation coaching to various companies, the shortcoming of employees, especially senior engineers, became obvious. The knowledge of architects/principal software engineers is often very limited. For example, I presented two implementations of the same test automation suite, one in Java, and one in Ruby. Then I highlighted the obvious benefits of using Ruby. Most of the time, they would choose Java anyway, because they only know Java, even though it is not a scripting language (for automated test scripts).
My Advice: Start with an Employee for a few years at least, then become a Contractor
Keep reading with a 7-day free trial
Subscribe to The Agile Way to keep reading this post and get 7 days of free access to the full post archives.