Show HN: Convert your annual salary into an hourly rate | Hacker News Reader

Show HN: Convert your annual salary into an hourly rate

dpmehta.com

12 pointsdpmehta026 comments

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

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.

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.

Yeah - I saw all the other components added: but they're pretty subjective between people

Work hours in a year vs salary gets you to a very close approximation in seconds.

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

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.

Reply on news.ycombinator.com