How to calculate an hourly, contractual rate

[Nicholas Faiz]

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

[Warren Seen]

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

--
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 rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

[Pat Allan]

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

[Daniel N]

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...

--

[Chris Berkhout]

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

[Steve Gilles]

That is a great post Nicholas, you've nailed it.

One point worth adding is that your rate should also reflect the length of contract.

Have a potential client with a 3 week rescue project? Charge a premium. Then add a bit.

On the flip side, there are many contracts of 6-12 month duration. Your utilisation for the year is dramatically higher. You're not really a freelancer, more like a professional contractor.

The rule of thumb here is that a professional contractor should earn roughly 20% more than a permanent employee (for reasons Nicholas explained earlier). 

When a company converts a contractor to a permanent employee you see this rule in action. What should the salary be? Let's use Nicholas' rate of $75 per hour as an example:

$75 per hour

* 8 hours

* 5 days

* 46 weeks

= $138,000

Minus 20% and you're left with $110,400 (all figures include super). 

That's not the final salary but it is the first calculation I make to find my bearings. Now you need to consider factors unique to your situation. This is what makes negotiation rand(fun,terrifying).

I can talk about this stuff all day. You are all welcome to hit me up for friendly career related advice, even if you are not looking for work. Catch me online, at the Ruby Sydney meetup or at Railscamp X (where I'm am definitely not the werewolf). 

Cheers,

Steve Gilles

@stevelikesyou

p.s. I am *always* hiring Ruby developers, though rarely post ads to the list. Get in touch if you are looking to hire or be hired. You can also check my jobs feed: @stevelikesjobs. 

[matthe...@gmail.com]

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 <chrisberkh...@gmail.com> 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 <has....@gmail.com> 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 <nicholas.f...@gmail.com> 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...).

[Phil Oye]

All great advice so far, but I just want to add that while it is critical to understand your costs when setting your rate (super, expected utilisation, equipment, sick leave, holiday, etc.) that is only half the story.

Don't forget to gauge what the market can bear. Just because you live in a tent, wear hand-me-down clothing, and work 90 hours a week, that doesn't mean you should set a cheap rate. If you're awesome, charge accordingly.

p.

[Warren Seen]

On 09/11/2011, at 10:58 PM, Phil Oye <phi...@gmail.com> wrote:

> Don't forget to gauge what the market can bear. Just because you live in a tent, wear hand-me-down clothing, and work 90 hours a week, that doesn't mean you should set a cheap rate. If you're awesome, charge accordingly.

Yep, this is what I meant before when I said to know your market value. I mentioned it in passing, but I could bang on about it for hours if given the chance. :D

In short, it doesn't matter if you're a contractor or a salaried employee, you owe it to yourself to get the most out of any contract rate, salary or pay rise negotiation, and you just can't do that if you don't know what the going rate is.

Cheers,

Warren.

[Gregory McIntyre]

Speaking of good accountants, how do you find one? How do I tell if one is good? And lastly, would anybody here like to promote one they know in Sydney?

[Steven Ringo]

Speak to Adrian Raftery aka @mistertaxman on twitter. He's awesome.

Steve

On 10/11/2011, at 9:28 AM, Gregory McIntyre wrote:

Speaking of good accountants, how do you find one? How do I tell if one is good? And lastly, would anybody here like to promote one they know in Sydney?

[Taryn East]

* Warren Seen <warre...@gmail.com> spake thus:

> 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.

Any recommendations? :)

Cheers,
Taryn
[currently a long way away... but moving back RSN]

[Michael Pearson]

There was a recent thread on this subject - take a look at the archives on groups.google.com

I'm in the same boat and really need to stop procrastinating on this.

--
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 rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

--
Michael Pearson

[Warren Seen]

Ha, my accountant is from a small town on the NW coast of Tassie, you might find it a bit awkward getting to his office. :) I actually started using him because he's been the accountant for my parent's small biz for 15 years.

I think that's probably a good indicator, talk to small business owners you know, family, friends, etc, find someone with a good reputation who's used to dealing with the "small end of town", I don't think you can go far wrong. :)

> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

[Ben Schwarz]

Unless anyone feels strongly against me doing so—I'm going to pin this as a topic on the group because I feel it represents the community and local industry rather well right now. 

Thoughts?

[Pat Allan]

Do it.

On 11/11/2011, at 1:19 PM, Ben Schwarz wrote:

> Unless anyone feels strongly against me doing so—I'm going to pin this as a topic on the group because I feel it represents the community and local industry rather well right now.
>
> Thoughts?
>

> --
> 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/-/wsaSGrTorVwJ.

[Nicholas Faiz]

I'm okay with it.

Cheers,

Nicholas

[kirk.bushell]

 Just had a chat with the guys on #roro about a post I just put up regarding this - and I must say that I disagree on quite a number of points, having contracted for about 2-3 years of my career, and not having anywhere near these expectations.

In short, I used to work for most companies at approximately $55/hour. You cannot expect people to pay for your downtime - it is of your own interest and initiative to find out if/when contracts end and if you're continuing, well ahead of contract end date (I used to know about 4-6 weeks out). If it doesn't look like you're going to continue, start looking. I used to look regardless of the outcome. I was never out of work. During the GFC I  actually upped my rate and still had no problems.

Furthermore - $75/hour for $75k/annual is NOT equal. If that were the case, we'd all be contracting, as it means you only have to work approximately 25 weeks/year to meet your annual (closer to $150k/year) expectations. For me this was never a problem (as I always had work), but perhaps it's a bit different these days. In any case, this is WELL ahead of people on permanent salaries. What you should be doing, is taking 6 weeks from the annual and making up that gap. This is pretty much the expected norm.

All said and done, as has been said here - specify whatever rate you're after and if you can get it - well done.

[Chris Berkhout]

Hey Kirk,

Link to your blog post?

Cheers,
Chris

> --
> 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/-/S_ojqOo0SRIJ.

[kirk.bushell]

Chris, sorry for the misuse of terminology - I meant in the chat room :)

[Anthony Richardson]

Hi Rhondalynn,

The way I read it is your hourly rate needs to cover the amount of time you spend on non-billable stuff. Just like the hourly rate your Lawyer charges has to pay for the receptionist even thou they aren't directly billing you the receptionists hours.

So you don't work 400 hours on a project and bill the client 600 hours, you only bill 400 hours. But your hourly rate better cover the the time you will be spending on financial management, marketing, etc... in the other 200 hours.

Cheers,

Anthony Richardson

On Thu, Sep 6, 2012 at 3:00 PM, Rhondalynn Korolak <rkor...@gmail.com> wrote:

On what basis does it make sense for someone to bill out their non-billable hours?  In most professions like law, accounting, architecture etc. this is actually illegal.  If it's non-billable, this practice could open up the developer to potential legal issues.  To bill someone at an hourly rate, you have to have the paperwork to prove that you did the work.

 

On Thursday, 12 July 2012 17:35:39 UTC+10, Ashley P wrote:

Hey Guys,

I really agree with below and it depends on your % of billable hours. But guys! You should be billing for nearly all your non-billable hours! You worked for it so send the bill! Quotes excepted. 

In regards to the non-freelance space this is my calculations for full-time contracts. 

Hourly rate X 1840 = Annual package including superannuation

How do I get 1840? 8 hours a day by 230 days a year (230 days is worked out as 52 weeks a year times 5 work days minus 30 days off for sick and annual leave) 

A contractor typically earns 20-25% more than a permanent employee. This is to compensate for the risk, time spent bidding for work and effort involved in chatting to pesky recruiters like myself :).

But don't be too overly weary for recruiters :) We aren't all bad! We spend a lot of time matching people up with the best opportunities rather than in a non-open market where businesses can just screw their employees. Like yourselves we spend a lot of time on non-billable activities that fall through :(. 

I'm on linkedIn if you'd like to keep in touch. Ashley Pettit

--

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/-/BdGr3AHv_FcJ.

[Tom Allen]

I've only recently joined the group (and only recently started working professionally with ruby), so I had to dig through the archives to read the other responses.

I've had a lot of discussions with game developers on this topic, as they're also in the class of people who routinely undersell themselves. Nicholas' post contains some great advice for cost-based pricing, but, personally I think this is a terrible approach and you should aim for value-based pricing instead. Two very smart and wealthier-than-most-of-us people agree:

• Patrick McKenzie (patio11 on hackernews) - http://www.kalzumeus.com/2012/01/23/salary-negotiation/
  
• and Ramit Sethi (the iwillteachyoutoberich.com guy) - http://www.kalzumeus.com/2012/09/21/ramit-sethi-and-patrick-mckenzie-on-why-your-customers-would-be-happier-if-you-charged-more/
  

Both of these guys have some great blog/video content on value-pricing. Put simply, work out how much your effort generates for your clients, and charge a percentage of that.

There's a few good reasons this works. First up, if your client already knows the value you're likely to deliver and you can also work this out and agree with them, it's much harder to underpay you. At the very least they'll feel very guilty about paying you $75/hr for a 2% increase in conversions on a $15M revenue application. If you can deliver that result, you're making them near 2% of $15M year on year, and deserve a butt-load more than $75/hr. Second, if you conclude that the value you're adding results in a billable rate close enough to or below what you'd charge in a cost-based pricing model, you've just learnt that your client's business isn't scalable. This tells you, for example, not to discount your rate based on a possibility of future work, because they'll probably go out of business soon enough. Thirdly, you'll be better off if you only work for people who understand the monetary value of your work. People who don't understand this hire people who don't understand this. People who do understand it hire people who don't, at very cheap rates, and people who do, at what they deserve.

Two caveats with this. Firstly, I'm in full-time employment, so maybe my advice is complete bullshit in the consulting world. I doubt this. Secondly, to pull this off, you need to be very clear about your skills and ability to deliver the value you calculate. At any rate, even if you don't buy my argument, read those blog posts above for a more thorough look at this stuff.

Cheers,

Tom

[Anthony Richardson]

It not about the value any programmer can add to a business. Its about the value you as a specific person can add.

Using your analogy

Put a bit primitively, it's like saying that the maker of a funnel should sell a funnel for $1 to a water supplier but $1000 to an oil company. I don't agree with that, really, even in the case of bespoke funnels.

The case for the oil company would we that they need a funnel that can be used in extreme circumstances or volatile materials and you are a company that is specially situated to engineer and create that very specific funnel.

If you can provide specific skills that *ADD* value (not just implement value specified by the client) then there is a case to charge for that value.

Cheers,

Anthony Richardson

On Wed, Mar 13, 2013 at 3:32 PM, Nicholas Faiz <nichol...@gmail.com> wrote:

Hi Tom,

I've only glanced at these articles but I think I understand the argument. I've even thought through it, a little bit, in the past.

There are at least a couple of problems with this approach (if I've understood what you're suggesting correctly).

The trouble with the idea of setting a rate based on the value you add to your customer's business income stream is that the case for it is only ever made for the case of making more money. The examples always seem to be about short term work meaning large value returns for clients. What about work that has longer payoff periods or can't easily be evaluated? 

The real issue I have with this method of charging clients, though, is that it loses its notion of market rates and a sense of objectivity. It's ostensibly about taking a fair cut from the value you add to a customer's business but, in reality, it confuses the work you do (writing code) with the work the business has done to create a financial structure that can profit from a computer program. I don't think the programmer deserves the latter profit cut unless they have built the business themselves.

Put a bit primitively, it's like saying that the maker of a funnel should sell a funnel for $1 to a water supplier but $1000 to an oil company. I don't agree with that, really, even in the case of bespoke funnels.

Again, you can always go for higher rates by showing that you bring something exceptional to the role. 

Cheers,

Nicholas

--

You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceani...@googlegroups.com.

To post to this group, send email to rails-...@googlegroups.com.

Visit this group at http://groups.google.com/group/rails-oceania?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Chris Berkhout]

If the funnel lets the oil company make $1000 more, then they should
be happy to pay $1000, minus some amount that makes it worth their
while to bother at all... unless some other funnel maker will do it
for less.

Cost price to value price is the range of viable prices (at which it's
worth doing), the market should determine the final price (that a
buyer and seller are prepared to agree on).

Cheers,
Chris

[Nicholas Faiz]

Just to remember the context, this was a post about hourly rates for contracts that people advertise about. Not for being a business owner or domain expert, etc.. It's really about XYZ company advertising that you join their team for n months and setting an hourly rate. 

Yeh, if you had to build a super funnel to oil you could charge more for it. If you're just building a funnel that's good enough for a water company or an oil company (it's the same act of work, same complexity, etc) you can't really use the market argument to say the oil company should pay an extra amount that is vastly disproportionate. 

The main idea is, I think, if you want access to the huge profits, take on business thinking as well. 

[Nicholas Faiz]

Ashley, 

Those rates are too low. The idea of the post was to let people know how to fairly identify a rate of pay.

Using the original calculation for an hourly rate (see the original post), that's saying a mid level developer would be charging $50 an hour, which maps to earning about 50 k (super included) per annum in a full-time role. I don't think you'd see any full-time mid level Rails roles offered for that.

Nicholas

On Friday, March 15, 2013 2:36:03 PM UTC+11, Ashley Pettit wrote:

Hey guys,

People are often just plainly asking me what they should charge.

Here's my two cents for contracts > 3 months and 40 hrs /week. 

Mid-level developer ~$400 day.

Senior-level ~$600 day.

As Nick said if you want more you need to have to really think about the business. How to improve it. Invest in the business and give suggestions on how they can be more profitable.

Also you need to value your service and have connections with people who really value what you do. 

Chaio,

Ash

[Dan Cheail]

Nicholas:

How do you figure? $50 / hour for a 40 hour week comes out to a gross of $104,000. Less  11% super contribution, that's still a gross of ~$95k, (~$70k after tax)

-- 

Dan Cheail, Geek

0402 114 697

--

[Ben Taylor]

You also need to take into account lack of holiday pay, sick leave and job security.

$70k after tax is what you would expect from a graduate IT position. And with contracting you don't get the perks of a normal job.

- Ben

[Nicholas Faiz]

Dan - as stated, read the original post. Anyway, this is looping and enough has been said.

Cheers,

Nicholas

[Michael Pearson]

On Fri, Mar 15, 2013 at 4:11 PM, Ben Taylor <m...@taybenlor.com> wrote:

You also need to take into account lack of holiday pay, sick leave and job security.

$70k after tax is what you would expect from a graduate IT position.

-- 

Michael Pearson

[Simon Russell]

Indeed, graduates are getting ~$93k?

[Ben Taylor]

Sorry, I meant before tax. But yeah $70k before tax is what I've seen recent CS graduates go into.

- Ben

[Michael Pearson]

On Fri, Mar 15, 2013 at 4:17 PM, Ben Taylor <m...@taybenlor.com> wrote:

Sorry, I meant before tax. But yeah $70k before tax is what I've seen recent CS graduates go into.

 

That's how I first read it, and my response is still the same.

Did they have Ph.Ds? Had they developed a popular JavaScript framework from scratch? Was the hiring company desperate for hires because they'd sullied their name in the local community? Did the graduate have a specialist skill? Were they a short-lived, burn-brightly-then-flip overfunded startup? Can I have my salary for the first five or six years of my career in IT retro-actively adjusted to this new entry rate, pretty please?

--
Michael Pearson

[Ben Taylor]

These aren't abnormal positions (AFAIK). A Ph. D would get higher. From discreet conversations with friends who took graduate roles between 4 years ago until now the going rate is around 60-80k. All have Degrees from the Group of 8 in either Computer Science, Engineering or IT and are working in either consulting or development roles. Example companies:

 * IBM

 * Google

 * Deloitte Digital

 * Macquarie Bank

 * Atlassian

 * Commonwealth Bank

 * NAB

FYI the ones I know who were super capable (PhDs and such) often got taken by American companies for >$100K graduate positions.

- Ben

[Michael Pearson]

On Mon, Mar 18, 2013 at 3:29 PM, Ashley Pettit <Is_ash_...@hotmail.com> wrote:

$400 day for someone mid level (~2-3 years by my loose definition) is pretty rocking stuff in my opinion. Most of my friends are around 24 years old and I can't quite say any of them earn anything near this! (Again disclaimer *you may definitely be worth it* I don't know) 

IMO 2-3 years isn't mid level.

Mid level is (years that you've been working in the industry) / 2.

Junior is (years ..) / 3

Senior is max( (years ...) - 1, 3)

--
Michael Pearson

[Ben Schwarz]

I wouldn't call anyone with less than 10 years experience a senior. 

In my mind: 

Junior:   1 – 4 years

Mid-weight: 5 – 9

Senior: 10+ 

We're talking not only skill, but mastery of craft and processes. 

--
You received this message because you are subscribed to a topic in the Google Groups "Ruby or Rails Oceania" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rails-oceania/aJUEhoE89mo/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to rails-oceani...@googlegroups.com.

[Ben Taylor]

Or we could measure on "how good they are" rather than "how many years they sat at a desk".

- Ben

You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceani...@googlegroups.com.

[Ben Schwarz]

Ben, they're two totally different subjects. 

I'm so not getting into one of those "define what you mean" discussion threads. 

[pythonic]

Or we could measure on "how good they are" rather than "how many years they sat at a desk".

But recruiters don't know how to do that!

Thanks,

Nicholas

[Michael Pearson]

Holy missing the point, batmen.

It's not about how many years you've been in the industry - it's being the same age or older than than the person hiring you. That's what "Senior" means.

I found it faintly amusing that Ashley thinks that 2-3 years is "mid level", because that's what I thought when I was 24, and now that I'm a fair bit older I think it's closer to what Ben says, which I also think is amusing, because I think we're about the same age.

--
Michael Pearson

[Nicholas Faiz]

Yes. I think this is a good guideline. 

[Clifford Heath]

I was a co-founder at ManageSoft from 1990 until 2007, and we hired a lot of
fresh graduates and saw them grow. Not web developers, but still… we had an
expectation that people would move up at a certain rate from junior to mid- to
senior level. The definition was roughly: A junior needs to work under some
level of supervision, whereas a mid-level dev can take rough requirements and
figure out how to negotiate, implement, test and deliver significant product
enhancements of increasing scope. We didn't expect mid-level developers to be
able to effectively mentor juniors; they only did that under combined supervision
of a senior dev. Senior devs were always involved when work had cross-cutting
scope or long-term ramifications.

I'm trying to make several points here:
* Mastery of the coding craft is only part of the picture; the team/community angle
is more important,
* Juniors that didn't progress to the bottom of the mid-level range within 18 months
were almost always fired, whereas very quick learners could advance in only six months.
* Seniors need to have many project cycles under their belt; they're expected to
not only know how things *should* go, but also the many ways they can go wrong
and how to avoid it. That almost always takes 8 or 10 years to develop.

There are many more technologies in a modern web stack, so these durations
will vary… but the point is that maturity is about being able to add value in the
team. Juniors might have great coding chops but still suck as much value (or
even more!) as they add, in the form of requiring supervision.

Clifford Heath.

> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceani...@googlegroups.com.

[Dave Bolton]

The following post has articulated well all the things that go into making a reliable senior engineer. As someone earlier noted, there is so much more to it than excellent technical skills, and a lot of the experience required to bring judgement to the factors mentioned in the article would be difficult or impossible to compress into a young career.

"On Being a Senior Engineer" - http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer

A good reference to show to engineers who are on the journey from having potential to really stepping up to senior level, and a good refresher for those already there. We all have so many things to work on!

Cheers,

Dave

On Tue, Mar 19, 2013 at 12:24 PM, jamesl <ladd....@gmail.com> wrote:

If only things were simple. Here are is my 2c given I'm 45 years old, have 25+ years of professional development
experience and currently act as a Development Manager where Junior, Mid and Senior is important to know from
a career and hiring perspective.

Junior, Mid-level and Senior have little to do with time. However, time is often used as a rough and quick
correlation technique. ie: 10+ years will typically = Senior Developer. etc

What makes someone Junior, Mid or Senior depends on their current role and their ability to do that role with little supervision (Senior) or
a lot of supervision (Junior). The ability to mentor and help others maximize their potential also makes people Senior, coding is not the
only skill required. Age has nothing to do with it but can be a factor on team fit.

How much you can charge depends on how much value you can bring to the business, and what budget the business has for people.

The more experience you have the more you can predict potential problems and steer away from them before they hit. The more experience
you have the more quickly you can see a problem and solve it. These are the two things people pay more money for as they save
money for the Business.

Rails Developers in my opinion are cheap right now at any given level as quite simply the demand is higher than the supply.
Stop selling yourself short/cheap.

- James.

[Simon Russell]

That's a really great post, I hadn't seen that. It's a much better
expression of what I think than I could ever muster.

I reckon everybody who wants to call themselves an engineer should read it.

[John Barton]

Back when I was working at envato team my rough rule of thumb was:

  - juniors can produce work but need help

  - mids produce work

  - seniors help others produce work

Sometimes the seniority would come deep technical knowledge and the ability to share that knowledge, sometimes it came from just general maturity in the "software development process".

Years working isn't the best proxy for this, but a certain number of them is necessary. Usually you're looking for the number of battle-scars the dev has. If a dev has the motivation to work and learn combined with being in the right places you can collect a good set quickly, but if they've just been coasting for 10 years in a series of unchallenging roles they won't have enough.

Just my 2c

-jb

[Tom Allen]

Michael O. Church has a good take on this too: http://michaelochurch.wordpress.com/2012/01/26/the-trajectory-of-a-software-engineer-and-where-it-all-goes-wrong/

Teams, in general, have four categories into which a person’s contribution can fall: dividers, subtracters, adders, and multipliers. Dividers are the cancerous people who have a broad-based negative effect on productivity. [snip] Subtracters are people who produce less than they cost, including the time of others who must coach and supervise them. As a temporary state, there’s nothing wrong with being a subtracter – almost every software engineer starts out his career as one, and it’s common to be a subtracter in the first weeks of a new job. Adders are the workhorses: competent individual contributors who deliver most of the actual work. Finally, multipliers are those who, often in tandem with “adder” contributions, make other people more productive. In many industries, being a multiplier is thought to be the province of management alone, but in technology that couldn’t be farther from the truth, because architectural and infrastructural contributions (such as reusable code libraries) have a broad-based impact on the effectiveness of the entire company.

What this scale intends to measure is the transition from a subtracter to an adder (0.0 to 1.0), from an adder to a multiplier (1.0 to 2.0), and from a “local” to a “global” multiplier (2.0 to 3.0). [snip]

Approximately speaking, the ranges are:

0.0 to 0.4: Complete novice

0.5 to 0.7: Sound grasp of fundamentals

0.8 to 0.9: Becoming an adder

1.0 to 1.3: Full-fledged adder

1.4 to 1.6: Solid adder

1.7 to 1.9: Becoming a multiplier

2.0 to 2.3: Full-fledged multiplier

2.4 to 2.6: Becoming a global multiplier (“Fellow”)

2.7 to 3.0: Senior fellow

Obviously, you should read the whole post if you want more details.

Cheers,

Tom

Tom Allen

t...@jugglethis.net

+61 412 335 425

http://www.drtomallen.com