Nick, Warren, there's great value in both of your emails.

There was a bit of discussion about this back at the first Adelaide Rails Camp 
- leading from suggestions I had around choosing rates - this blog post doesn't 
do the Rails Camp discussion justice, but the comments certainly add a lot of 
value:
http://freelancing-gods.com/posts/freelancing_tips_via_rails_camp_4

That said, Nick's provided some much deeper (and better) distinctions on how 
contractors work situations differ from full-time, and the pros and cons of 
each. Thanks for sharing.

-- 
Pat

On 09/11/2011, at 1:00 PM, Warren Seen wrote:

> Good post Nicholas. 
> 
> I contracted for 7 odd years, (not just as a Ruby dev) and everything here is 
> pretty much spot on. I used to aim for about 60% of my time being billable, 
> that was the break-even point for me - once I had covered my mortgage, living 
> expenses, feeding the kids, etc. anything else was "profit".
> 
> When setting your rate, know your market value, and be prepared to justify it 
> and walk away from a bad deal if you feel like you're about to get screwed.
> 
> Above all else, make sure you plan from the start to pay yourself at LEAST 9% 
> superannuation - although paying more can have tax benefits, so get a good 
> accountant if you don't already have one. 
> 
> Actually, scratch that: Above all else, get a good accountant.
> 
> Happy to answer questions off-list if anyone wants to ask me anything.
> 
> Cheers,
> 
> Warren
> 
> On 09/11/2011, at 4:45 PM, Nicholas Faiz wrote:
> 
>> Hi,
>> 
>> I've been watching job boards for Ruby related contracts lately and have 
>> noticed some low rates being offered with high expectations. It's happening 
>> frequently enough that I wanted to post my understanding of how to calculate 
>> an hourly rate. Setting *reasonable* standards of pay for the appropriate 
>> level of expertise is vital. There's a lot to say on the matter, so I've 
>> tried to be brief.
>> 
>> For some reason it's very easy for software developers to match their 
>> experience and knowledge to a full-time rate, but for contracting there is 
>> less awareness. 
>> 
>> The difference between full-time employment and self employment.
>> 
>> Employers gain certain benefits from contractors. On a financial level, they 
>> have less commitment, which means they do not have to pay for sick, parental 
>> and annual leave, training, redundancy payouts (for redundancy see 
>> http://www.netlawman.com.au/info/retrenchment-and-redundancy-australia.php) 
>> or superannuation (at least 9% of base income). To hire someone on a 
>> full-time basis is a serious commitment for an employer, and if the 
>> relationship isn't successful they cannot simply end the agreement (see 
>> unfair dismissal laws - 
>> http://www.fairwork.gov.au/resources/fact-sheets/conditions-of-employment/Pages/termination-of-employment-fact-sheet.aspx
>> ). 
>> 
>> So, employers can take project risks, using contractors, to build a 
>> profitable application, without the consequences of supporting long-term 
>> staff. If they (read large corporations especially here) had to commit to 
>> long-term employment responsibilities before their endeavours became 
>> profitable it would be prohibitive to start them. Good contractors are 
>> essential for ventures hoping to build a profitable application and it's a 
>> typical scenario that applications are initially built with contractors and 
>> then, when mature, transition to full-time internal staff.
>> 
>> Expertise.
>> 
>> In addition, there's expertise to consider. Contractors are often experts 
>> (or aspiring ones) in their domains. Full-time staff might specialise on a 
>> particular use of a technology *and* the business. Contractors are expected 
>> to specialise in the technology, and to bring new perspectives and expertise 
>> to inhouse practices. So, these sorts of contractors also enrich the 
>> development habits of their employer by showing them new ways to solve 
>> problems which their own employees haven't had time to research.
>> 
>> Remember, if these things don't happen, the agreement between the contractor 
>> and the employer can quickly end.
>> 
>> The basic rate.
>> 
>> The rough calculation is your expected annual income, at a full-time rate 
>> (including super, paid leave, etc.), divided by 1000. For e.g., for $75,000 
>> pa (including a super payment, holiday pay, potential sick leave cover, 
>> etc.), the matching hourly rate is $75 (GST not included). This sort of 
>> package would like be advertised at somewhere like 62k with benefits 
>> attached, if converted to a full-time role. 
>> 
>> If you pull out a calculator and multiply the number of working weeks in the 
>> year by the number of working hours (46 x 40) then times that by the hourly 
>> rate, you'll find that this adds up to 138k. This seems to be excessive of 
>> the targeted 75k income. But that's okay, for two reasons.
>> 
>> 1) The employer hasn't hired you for 46 weeks in the year.
>> 2) If you are able to bounce between short-term contracts continually, then 
>> that's a good thing, but the employer's agreement with you doesn't guarantee 
>> this and it can't be used as a justification to lower the rate. The reality 
>> is, in the contracting scene, there are sometimes gaps in employment for 
>> upskilling (open source coding, etc.), rest, or securing the next role.
>> 
>> This rate leaves to one side the notion of expertise. If you're an 
>> exceptional candidate, for whatever reason, or if the technology you 
>> specialise in has a rarer skillet, or is in high demand, then these rates 
>> can adjust to such things. The reality is that Ruby and the frameworks 
>> around it are an in demand skillset, so if anything the rates should go 
>> higher.
>> 
>> So, beware of contractual roles which are, in reality, heavily benefitting a 
>> company or (more than likely, a middle man agent), and offering 
>> incommensurate rates for skillsets. Support the employers that do offer fair 
>> rates by doing good work. 
>> 
>> 
>> Cheers,
>> Nicholas
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Ruby or Rails Oceania" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/rails-oceania/-/QDcQGFsvlCEJ.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to 
>> [email protected].
>> For more options, visit this group at 
>> http://groups.google.com/group/rails-oceania?hl=en.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby or Rails Oceania" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/rails-oceania?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rails-oceania?hl=en.

Reply via email to