5 ms·

You will spend year teaching someone then he leaves for another company who gave him 20% rase. You're net negative, they're net positive. You'll lose the race i

You will spend year teaching someone then he leaves for another company who gave him 20% rase. You're net negative, they're net positive. You'll lose the race in the end. This could be a good approach for someone huge like Google or government. Asking that from an ordinary company will not work.

rootusrootus 5y ago
If it takes a year for someone to pick up a new framework and be productive, I didn't want them anyway.
carlio 5y ago
Isn't the corollary that there are other companies who train up people who you can hire for a 20% raise from them? Or even just give your existing staff a pay rise once they reach a more senior level? If you can't afford to do that, then that's saying you can't afford to hire people who know a lot about the technology you're using, and then that's a whole different issue.
BaseballPhysics 5y ago
> You will spend year teaching someone then he leaves for another company who gave him 20% rase. This only makes sense if you hired the person at 20% below their market rate under the belief that they were less valuable as a hire simply because they didn't have a specific skillset you needed, and then once they acquired that skillset you failed to adjust their salary accordingly. But the entire thesis of the OPs comment is that we shouldn't be valuing staff based on any one specific technical skillset, but rather based on their broader software development skills and experience, because learning the ins and outs of any specific software stack is not itself that difficult given enough experience. Solution: hire and retain at a competitive market rate. Problem solved.
- orra 5y ago
  > But the entire thesis of the OPs comment is that we shouldn't be valuing staff based on any one specific technical skillset, but rather based on their broader software development skills and experience, because learning the ins and outs of any specific software stack is not itself that difficult given enough experience. Exactly. Tech stacks are extremely transferrable, at least to an experienced developer. Imagine hiring a painter. You want a green wall. You don't rule them out, or pay them 20% less, because the last wall they painted was pink.
- native_samples 5y ago
  I think the assumption behind the post you're replying to is that this will happen regardless of what you are paying them, that is, there is no actual stable "market rate" that can be precisely targeted. It may seem this cannot happen, but in a system experiencing rapid inflation it's what you'd expect to see. This doesn't have to be on a macro level. The endless tide of VC + crypto funds have created a form of (hyper?) inflation inside the tech industry in which wages are spiralling upwards without any fundamental link to increased value. It's simply a bidding war in which those who fight for closer access to the flow of inbound money can always outbid other firms, regardless of how much they pay, because there is no "market rate", just "whatever this guy currently makes + 20%".
  - BaseballPhysics 5y ago
    > I think the assumption behind the post you're replying to is that this will happen regardless of what you are paying them, that is, there is no actual stable "market rate" that can be precisely targeted. > The endless tide of VC + crypto funds have created a form of (hyper?) inflation inside the tech industry in which wages are spiralling upwards without any fundamental link to increased value. It's simply a bidding war in which those who fight for closer access to the flow of inbound money can always outbid other firms, regardless of how much they pay, because there is no "market rate", just "whatever this guy currently makes + 20%". . Of course there's a market rate, it's just increasing. That's called supply and demand. And it would happen regardless of any one specific technical skillset. If anything this just further emphasizes the OPs point as specifically because demand so significantly outstrips supply, companies should be willing to train someone up rather than forego a promising hire, as that increases their potential labour pool (this is basically the labour market version of a substitute good). For the same reason companies are looking at partial- or full-remote hires, launching offices in other markets, etc, as that gets them access to a broader labour market outside the SV bubble. Frankly, I don't know what you even mean by the claim that there's no "fundamental link to increased value". There is a demand for labour. There is a clearing price in the market for that labour. That clearing price is going up due to a high demand for that labour relative to the supply. Buyers are willing to pay for labour at the clearing price based on their assessment of cost-vs-benefit. You may not think that labour is being put to productive use. But that doesn't imply the labour market is in any way flawed or that the laws of supply and demand have somehow broken down.
- dzikimarian 5y ago
  > and then once they acquired that skillset you failed to adjust their salary accordingly. Or your budget took a hit due to half year gap in delivery, caused by boot camp you conducted and then bigger company snatches your team, while you have no way to react.
  - BaseballPhysics 5y ago
    If you need a half year to train up a developer to a reasonable level of productivity, you have a problem. If you need to slip or stop development for a half year because you need to train up a whole new team, you have a whole other problem. If, prior to hiring, you failed to budget for an appropriate market rate reflecting a skilled up staff, you have yet another problem. Honestly, at what point can we agree the real problem is bad management?
    - dzikimarian 5y ago
      >If you need to slip or stop development for a half year because you need to train up a whole new team, you have a whole other problem. Yes, which is why nobody reasonable does that. Which leads us to the original point, that many companies will not be interested in taking risk to introduce flutter.
UnpossibleJim 5y ago
I think a lot of companies are figuring out, right now, that it isn't all about money (and crappy snacks) that equal employee retainment. Mentoring and proper training in decent platforms, not to mention a decent work/life balance go a long way when you start comparing them to different company cultures. I might grind away at Amazon for a couple of years (personally - no offense to the people that love it, it isn't for me), but that sort of job first, life second - everyone move up metric isn't for everyone. Some people are "professionals" and some people are "craftsmen"... I guess? Neither one is good or bad, they're just different mindsets and goals. There are companies (though few, I suppose) that want "craftsmen". There are companies that want "professionals". A good company, wants both.
NicoJuicy 5y ago
What if your don't teach them and they stay?
FpUser 5y ago
>"You will spend year teaching someone then he leaves for another company who gave him 20% rase." If you hire decent developer and it takes a year to teach them for example react to be productive the problem is not with the developer. Normal developer should be reasonable productive in a matter of days. Ok give it a month. And it does not require tutor hanging over the shoulder. The problem is with you as you've just hired someone who's at the moment unqualified as a developer in general.
- bseidensticker 5y ago
  IDK what your experience is, but in my experience at Google it would take about 6 months before I could consider someone "reasonably productive". Or maybe it takes about 6 months before I'm confident that they are actually underperforming. A week is just enough time to get a cursory understanding of the product and tooling and fix a newbie bug.
  - native_samples 5y ago
    Google is not at all a reasonable proxy for the rest of the industry. It has an almost entirely parallel infrastructure that bears little resemblence to what everyone else learns and uses. Google has notoriously high training times for this reason and always did.
    - bseidensticker 5y ago
      I realize that, but 1 month vs 6 months? It's not just that the infrastructure is all different, ramping up on a codebase is extremely time consuming itself. You're going to have that at any other large tech company. If it's a tiny startup on mostly greenfield stuff then sure, but that's also not a reasonable proxy for the rest of the industry.
      - native_samples 5y ago
        Trust me, Google is just weird. I used to work there. When I joined SRE it took 3 months for me to be able to do anything useful at all, and another three months after that before I was really able to function on my own without needing to constantly look things up or ask for help. After Google I joined a startup where I built two new products from scratch, including hiring most of the team myself. On boarding time was about a week and that included learning a new programming language from scratch (Kotlin, which is in fairness, easy to learn). This remained true true even after several years where the codebase had become quite large. On-boarding time never really changed for programmers of equivalent skill. Ramp-up time in most normal businesses and most normal codebases is measured in weeks, not six months.

rootusrootus 5y ago

If it takes a year for someone to pick up a new framework and be productive, I didn't want them anyway.

carlio 5y ago

Isn't the corollary that there are other companies who train up people who you can hire for a 20% raise from them? Or even just give your existing staff a pay rise once they reach a more senior level? If you can't afford to do that, then that's saying you can't afford to hire people who know a lot about the technology you're using, and then that's a whole different issue.

BaseballPhysics 5y ago

> You will spend year teaching someone then he leaves for another company who gave him 20% rase. This only makes sense if you hired the person at 20% below their market rate under the belief that they were less valuable as a hire simply because they didn't have a specific skillset you needed, and then once they acquired that skillset you failed to adjust their salary accordingly. But the entire thesis of the OPs comment is that we shouldn't be valuing staff based on any one specific technical skillset, but rather based on their broader software development skills and experience, because learning the ins and outs of any specific software stack is not itself that difficult given enough experience. Solution: hire and retain at a competitive market rate. Problem solved.

orra 5y ago
> But the entire thesis of the OPs comment is that we shouldn't be valuing staff based on any one specific technical skillset, but rather based on their broader software development skills and experience, because learning the ins and outs of any specific software stack is not itself that difficult given enough experience. Exactly. Tech stacks are extremely transferrable, at least to an experienced developer. Imagine hiring a painter. You want a green wall. You don't rule them out, or pay them 20% less, because the last wall they painted was pink.
native_samples 5y ago
I think the assumption behind the post you're replying to is that this will happen regardless of what you are paying them, that is, there is no actual stable "market rate" that can be precisely targeted. It may seem this cannot happen, but in a system experiencing rapid inflation it's what you'd expect to see. This doesn't have to be on a macro level. The endless tide of VC + crypto funds have created a form of (hyper?) inflation inside the tech industry in which wages are spiralling upwards without any fundamental link to increased value. It's simply a bidding war in which those who fight for closer access to the flow of inbound money can always outbid other firms, regardless of how much they pay, because there is no "market rate", just "whatever this guy currently makes + 20%".
- BaseballPhysics 5y ago
  > I think the assumption behind the post you're replying to is that this will happen regardless of what you are paying them, that is, there is no actual stable "market rate" that can be precisely targeted. > The endless tide of VC + crypto funds have created a form of (hyper?) inflation inside the tech industry in which wages are spiralling upwards without any fundamental link to increased value. It's simply a bidding war in which those who fight for closer access to the flow of inbound money can always outbid other firms, regardless of how much they pay, because there is no "market rate", just "whatever this guy currently makes + 20%". . Of course there's a market rate, it's just increasing. That's called supply and demand. And it would happen regardless of any one specific technical skillset. If anything this just further emphasizes the OPs point as specifically because demand so significantly outstrips supply, companies should be willing to train someone up rather than forego a promising hire, as that increases their potential labour pool (this is basically the labour market version of a substitute good). For the same reason companies are looking at partial- or full-remote hires, launching offices in other markets, etc, as that gets them access to a broader labour market outside the SV bubble. Frankly, I don't know what you even mean by the claim that there's no "fundamental link to increased value". There is a demand for labour. There is a clearing price in the market for that labour. That clearing price is going up due to a high demand for that labour relative to the supply. Buyers are willing to pay for labour at the clearing price based on their assessment of cost-vs-benefit. You may not think that labour is being put to productive use. But that doesn't imply the labour market is in any way flawed or that the laws of supply and demand have somehow broken down.
dzikimarian 5y ago
> and then once they acquired that skillset you failed to adjust their salary accordingly. Or your budget took a hit due to half year gap in delivery, caused by boot camp you conducted and then bigger company snatches your team, while you have no way to react.
- BaseballPhysics 5y ago
  If you need a half year to train up a developer to a reasonable level of productivity, you have a problem. If you need to slip or stop development for a half year because you need to train up a whole new team, you have a whole other problem. If, prior to hiring, you failed to budget for an appropriate market rate reflecting a skilled up staff, you have yet another problem. Honestly, at what point can we agree the real problem is bad management?
  - dzikimarian 5y ago
    >If you need to slip or stop development for a half year because you need to train up a whole new team, you have a whole other problem. Yes, which is why nobody reasonable does that. Which leads us to the original point, that many companies will not be interested in taking risk to introduce flutter.

UnpossibleJim 5y ago

I think a lot of companies are figuring out, right now, that it isn't all about money (and crappy snacks) that equal employee retainment. Mentoring and proper training in decent platforms, not to mention a decent work/life balance go a long way when you start comparing them to different company cultures. I might grind away at Amazon for a couple of years (personally - no offense to the people that love it, it isn't for me), but that sort of job first, life second - everyone move up metric isn't for everyone. Some people are "professionals" and some people are "craftsmen"... I guess? Neither one is good or bad, they're just different mindsets and goals. There are companies (though few, I suppose) that want "craftsmen". There are companies that want "professionals". A good company, wants both.

NicoJuicy 5y ago

What if your don't teach them and they stay?

FpUser 5y ago

>"You will spend year teaching someone then he leaves for another company who gave him 20% rase." If you hire decent developer and it takes a year to teach them for example react to be productive the problem is not with the developer. Normal developer should be reasonable productive in a matter of days. Ok give it a month. And it does not require tutor hanging over the shoulder. The problem is with you as you've just hired someone who's at the moment unqualified as a developer in general.

bseidensticker 5y ago
IDK what your experience is, but in my experience at Google it would take about 6 months before I could consider someone "reasonably productive". Or maybe it takes about 6 months before I'm confident that they are actually underperforming. A week is just enough time to get a cursory understanding of the product and tooling and fix a newbie bug.
- native_samples 5y ago
  Google is not at all a reasonable proxy for the rest of the industry. It has an almost entirely parallel infrastructure that bears little resemblence to what everyone else learns and uses. Google has notoriously high training times for this reason and always did.
  - bseidensticker 5y ago
    I realize that, but 1 month vs 6 months? It's not just that the infrastructure is all different, ramping up on a codebase is extremely time consuming itself. You're going to have that at any other large tech company. If it's a tiny startup on mostly greenfield stuff then sure, but that's also not a reasonable proxy for the rest of the industry.
    - native_samples 5y ago
      Trust me, Google is just weird. I used to work there. When I joined SRE it took 3 months for me to be able to do anything useful at all, and another three months after that before I was really able to function on my own without needing to constantly look things up or ask for help. After Google I joined a startup where I built two new products from scratch, including hiring most of the team myself. On boarding time was about a week and that included learning a new programming language from scratch (Kotlin, which is in fairness, easy to learn). This remained true true even after several years where the codebase had become quite large. On-boarding time never really changed for programmers of equivalent skill. Ramp-up time in most normal businesses and most normal codebases is measured in weeks, not six months.