
Show HN: Convert your annual salary into an hourly rate - dpmehta02
http://dpmehta.com/portfolio/calculator.html
======
warrenm
I can save you the time: divide by 2000 to get very close.

There's 2080 work hours in a year (52 weeks, 40 hours per week).

So _technically_ you should divide by 2080, but dividing by 2000 is a lot
faster in your head (drop three zeroes, and halve).

~~~
dpmehta02
Thanks for the feedback warrenm. Heuristics can be useful, but I built this
calculator to help freelancers account for opportunity costs and unexpected
expenses in their rates. For example, someone who makes a $100,000 salary
would charge 100,000/2080 = $48/hour by the measure you described. However, I
don't believe that rate accounts for PTO, National Holidays, Health Insurance,
Business Development time, self-employment taxes and many other things. A more
realistic equivalency in my experience (and according to the calculator) would
be $100-$125/hour.

Hope that's helpful.

~~~
bradknowles
In my experience, people tend to greatly underestimate how much it will cost
them to pay both the employer and the employee part of insurance, as well as
other expenses typically paid by an employer.

The rule of thumb I arrived at years ago was to start by dividing the annual
rate by a factor of two, to account for the additional tax burden. Then to
divide by an additional factor of two to account for the additional insurance
burden.

Then you start factoring in your other costs.

Years ago, I was contracting with Apple Retail Software Engineering in
Cupertino, and making $95/hr. I calculated that they would have to give me a
$250,000 annual salary to be able to take home the same amount of money on a
monthly basis, and virtually no one at Apple makes that kind of money unless
they're an SVP.

So, I was actually quite happy when the contract ended and I got to go home to
Austin.

------
adtac
Why is this a slide bar instead of an input field where I can enter the
number?

~~~
dpmehta02
Thanks for the feedback. I thought it would be easier for users to simply
slide a scale rather than manually input numbers (which I feel is error prone
and more work), especially on a mobile device.

In the next iteration I'm considering allowing users to use either option,
sliding scale or direct input.

