3 ms·

We pay the same (and offer a Singapore visa if they change their mind). The method is pretty simple: we pay X amount of money and get Y (or more) amount of code

by crdb 12y ago

We pay the same (and offer a Singapore visa if they change their mind). The method is pretty simple: we pay X amount of money and get Y (or more) amount of code "value" back, and try and keep Y/X relatively stable. Works out well for those living in cheaper cities, but it does suck a bit if you're in a high tax country/state, since Singapore's tax rate is in the single digit percent.

nomadpdx 12y ago
This is exactly the comment I was looking for. So many folks on here that are resistant to the idea of paying everyone equally for the amount of value they bring to the team.
- davewasthere 12y ago
  It's quantifying that value that is the difficult part. Delivery of x amount of lines of code would be a terrible metric for example...
  - crdb 12y ago
    I'm not saying it was the only predictor, but we did have a candidate who solved the application task with a quarter (1/4!) of the code submitted by the next best, whose submission was already beautifully succinct. So, number of lines of code CAN be a meaningful predictor ;) More seriously, I agree with you. I don't think performance is quantifiable with parametric methods, you just have to allocate a fair amount of mental effort to the problem. For example, a "maintenance guy" who enjoys breaking other people's code, fixing holes and doing tests is extremely valuable, but not someone that is easily sold to non-technical management, nor that is very visible; at the same time, without some builders to work with, his salary is wasted. We get away with it because we have a carefully selected (around 3 man-month of just recruiting) small team (10) of experienced developers from a small but strong and mature community (Haskell) on a well defined problem (fix and improve a large e-commerce platform). I shudder to think of the magnitude of the problem for a much larger company with much larger teams, like Google or Microsoft.

by crdb 12y ago

nomadpdx 12y ago

This is exactly the comment I was looking for. So many folks on here that are resistant to the idea of paying everyone equally for the amount of value they bring to the team.

davewasthere 12y ago
It's quantifying that value that is the difficult part. Delivery of x amount of lines of code would be a terrible metric for example...
- crdb 12y ago
  I'm not saying it was the only predictor, but we did have a candidate who solved the application task with a quarter (1/4!) of the code submitted by the next best, whose submission was already beautifully succinct. So, number of lines of code CAN be a meaningful predictor ;) More seriously, I agree with you. I don't think performance is quantifiable with parametric methods, you just have to allocate a fair amount of mental effort to the problem. For example, a "maintenance guy" who enjoys breaking other people's code, fixing holes and doing tests is extremely valuable, but not someone that is easily sold to non-technical management, nor that is very visible; at the same time, without some builders to work with, his salary is wasted. We get away with it because we have a carefully selected (around 3 man-month of just recruiting) small team (10) of experienced developers from a small but strong and mature community (Haskell) on a well defined problem (fix and improve a large e-commerce platform). I shudder to think of the magnitude of the problem for a much larger company with much larger teams, like Google or Microsoft.