Good advice here, all I would add is you have to consider the length of the contract on offer. $100/hour for a 12 month contract is a better deal than $100/hour for a 2 month contract. The longer the contract, the more work you have guaranteed, the less often you have to look for jobs (which is a cost in the contracting equation) and also gives you more time to find another contract before your current contract runs out. The more time you are in work the closer you get to the theoretical 46 weeks * 40 hours * rate.
On Nov 9, 6:48 pm, Chris Berkhout <[email protected]> wrote: > Good stuff guys. > > Nicholas' formula of `hourly rate = equivalent full time salary / > 1000` seems about right, but I think it's worth breaking that down > into specific costs as Pat has in his blog post. > > Some extra costs to consider are equipment, accounting, legal advice, > office/coworking space, educational materials and unplanned time > between contracts. > > Cheers, > Chris > > > > > > > > On Wed, Nov 9, 2011 at 2:12 PM, Daniel N <[email protected]> wrote: > > Really great points in here mate. It's up to us to set the expectations for > > our work and we shouldn't cheapen it. Once we race to the bottom we all > > suffer... > > On 9 November 2011 16:45, Nicholas Faiz <[email protected]> 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-australi...) > >> 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-employ...). > > >> 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.
