5 ms·

This article highlights one of the things that really bugs me about tech hiring. The availability of developers who know a language or tech isn't a limiting fac

This article highlights one of the things that really bugs me about tech hiring. The availability of developers who know a language or tech isn't a limiting factor if you're willing to hire people and give them the time to learn. Yes, it's expensive, but if there really are productivity benefits from using a particular tool then you should end up better off in the long term anyway. The expectation that another company will train your workforce, or that they'll train themselves in their spare time before joining, massively inhibits the proliferation of different, new, and interesting technologies and keeps 90% of the devs in the web and mobile world on the same 3 platforms (JS/TS, Swift, and Kotlin). Unless companies start hiring to mentor people this will not change, and probably TS will just eat all the others in the long run.

vbezhenar 5y ago
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.
- 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.
jamonholmgren 5y ago
I don't disagree, but you kind of answered your own question here: > Unless companies start hiring to mentor people this will not change, and probably TS will just eat all the others in the long run. You and I both know this will not change. Thus, TS will eat all the others. That's an underlying assumption in my article, to be honest.
JimDabell 5y ago
> The availability of developers who know a language or tech isn't a limiting factor if you're willing to hire people and give them the time to learn. It is a job satisfaction risk though. Just because a person is capable of learning a language or technology, it doesn’t mean that once they have learnt it they will find satisfaction in using it every day. Surely most people with a decent amount of experience has at least one language or technology they dislike? Only hiring people who have experience with the language or technology doesn’t just mean that they can be productive much sooner, it also means that you are selecting only the people who know they want to work with it every day whilst filtering out people who would end up disliking it.
- onion2k 5y ago
  it also means that you are selecting only the people who know they want to work with it every day whilst filtering out people who would end up disliking it Doesn't that imply that we all like the languages we use every day? I'm fairly sure that's not the case for a lot of developers. In fact, I'm certain loads would like the opportunity to use what they think is a 'better' language, but they can't because too few companies hire for it.
  - JimDabell 5y ago
    If somebody is working with a language and applies for another job working with that language, then you have high confidence that they aren’t going to suddenly realise they dislike the language and therefore the job. If somebody hasn't worked with the language before, that confidence is not there at all. > I'm certain loads would like the opportunity to use what they think is a 'better' language Sure, but expectations and reality are not always in agreement. The grass is always greener on the other side, right? Those people might have a different opinion after working with the “better” language for a while.
  - kodah 5y ago
    > Doesn't that imply that we all like the languages we use every day? Yes and no. I tolerate writing in Java, but for most applications I'm not a fan. I think what GP is alluding to is that developer ergonomics matter more than we give them mindshare for.
jayd16 5y ago
That's fine but if the job description is explicit about a technology, they probably need the mentor not the mentee.
ozim 5y ago
I would like to take different point of view. Developers also switch jobs to get more salary and market themselves as specialists in a specific stack. I yet have to see developer taking pay cut to retrain in a different tech. Companies already have to factor in training of people on their company specific stuff. That is why no one expects new hire to be fully productive in first 3-6 months. Even if you know JavaScript it still is quite a lot of work to understand code base ... now take someone who does not know JavaScript and as addition has to learn company specific stuff. That is why hiring is like that because "tech" is transferrable skill between companies and developers like to invest into transferrable skills.
- mjmahone17 5y ago
  Learning JavaScript is such a small cost for an experienced developer who has done any kind of similar work in any language, relative to the 3-6 months of company level ramp up you propose, as to be essentially meaningless. If you need a JS expert because you currently don’t have anyone who can figure out performance problems with junior engineer’s changes, that’s one thing, but you then probably can train that JS expert in any JS framework very quickly. Likewise if you need a UX expert, that UX expert should be able to pick up Swift or whatever language you need them to work in faster than it takes them to grok the business problems you’re actually solving.
- nouveaux 5y ago
  "I yet have to see developer taking pay cut to retrain in a different tech." I'd argue that most tech just does not take that long to train in. If I am proficient developer that knows Postgres, how long is it really going to take me to be productive with Mongo? This is very different compared to say a web developer moving to robotics. I would take a pay cut for that because the knowledge gap is so wide.
cameronh90 5y ago
> massively inhibits the proliferation of different, new, and interesting technologies Do people really look at the JS webapp framework landscape and feel that LACK of proliferation is a problem?
- pc86 5y ago
  To be fair, if you exclude the ones that are garbage, you basically have React, Vue, and Angular. Of those three, React is the clear winner in terms of market penetration, but there are certain things in both Vue and Angular that blow React out of the water.
  - gkbrk 5y ago
    Many people would consider some of the ones you ruled out as "garbage" as great, while considering React/Vue/Angular as garbage. React is the clear winner in terms of market penetration as that is what happens to projects with the largest marketing budgets / corporate hype.
jarjoura 5y ago
Counterpoint, I made a recent shift to Android from many many years of iOS development. It's not the language that I struggled with, it was the completely different engineering culture surrounding the platform. Yes there are many similarities, things like concerns for battery life and thoughtful network usage. However, that's where the similarities end. The APIs and appropriate architecture decisions are completely different, so I needed to build all new instincts. Then, you have the tooling that are completely different. Where it would normally take me 5 min to jump into Xcode to profile an application, inspect for leaks or other performance issues, I spent a few hours going through Android documentation learning how to do the same thing. Last, and this one is a bit nuanced and sort of hard to explain. As a senior engineer, you're typically expected to help mentor others and maintain the foundations of your product so that as new people join they have a template to work from. If you're switching to something so different, you could end up hurting the team (or company) by using the wrong patterns and promoting incompatible ideas. People need to trust you and if you break that trust at the beginning of your employment, it'll be really hard to earn it back. No regrets though, and I'm grateful to my employer for giving me the space to make the shift. However, I do not believe in the idea you can hire someone at a generalist level and then expect them to be productive anytime soon. There is a saying, "Jack of All Trades, Master of None," and although very cynical, it's just an honest statement when it comes to these things. Hire the right person for the role you need filled first, then if you want to make room for engineers who are looking for big career changes, make sure your product and team won't suffer for that and you have the right culture in place to encourage that kind of growth.
- Benjammer 5y ago
  I think the key point from the OP you're missing here is mentorship/training to avoid all of the issues you described. I don't think the OP was advocating for hiring the best generalist you can find and then just throwing them to the wolves and expecting senior-level productivity.
- pjmlp 5y ago
  Being active as a generalist with some deep knowlege across specific stacks I can pretty much vouch this, even on stacks one is conftorable with takes some time getting back to after a couple of months let alone stacks that one never used.
sangnoir 5y ago
> Unless companies start hiring to mentor people this will not change This wont change until SWE stop job-hopping so much. In turn, the job-hopping won't stop until employers stop prioritizing new hire compensation over existing employees...and I don't see how this stops because it's measurably profitable and is self-reinforcing. On the flip side, as an employee, I like that I can reuse the skills I have, it commoditizes employers and lowers the friction in changing jobs. Knowing what I know about capitalism in practice, employers would love the savings from employee tech lock-in.

vbezhenar 5y ago

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

jamonholmgren 5y ago

I don't disagree, but you kind of answered your own question here: > Unless companies start hiring to mentor people this will not change, and probably TS will just eat all the others in the long run. You and I both know this will not change. Thus, TS will eat all the others. That's an underlying assumption in my article, to be honest.

JimDabell 5y ago

> The availability of developers who know a language or tech isn't a limiting factor if you're willing to hire people and give them the time to learn. It is a job satisfaction risk though. Just because a person is capable of learning a language or technology, it doesn’t mean that once they have learnt it they will find satisfaction in using it every day. Surely most people with a decent amount of experience has at least one language or technology they dislike? Only hiring people who have experience with the language or technology doesn’t just mean that they can be productive much sooner, it also means that you are selecting only the people who know they want to work with it every day whilst filtering out people who would end up disliking it.

onion2k 5y ago
it also means that you are selecting only the people who know they want to work with it every day whilst filtering out people who would end up disliking it Doesn't that imply that we all like the languages we use every day? I'm fairly sure that's not the case for a lot of developers. In fact, I'm certain loads would like the opportunity to use what they think is a 'better' language, but they can't because too few companies hire for it.
- JimDabell 5y ago
  If somebody is working with a language and applies for another job working with that language, then you have high confidence that they aren’t going to suddenly realise they dislike the language and therefore the job. If somebody hasn't worked with the language before, that confidence is not there at all. > I'm certain loads would like the opportunity to use what they think is a 'better' language Sure, but expectations and reality are not always in agreement. The grass is always greener on the other side, right? Those people might have a different opinion after working with the “better” language for a while.
- kodah 5y ago
  > Doesn't that imply that we all like the languages we use every day? Yes and no. I tolerate writing in Java, but for most applications I'm not a fan. I think what GP is alluding to is that developer ergonomics matter more than we give them mindshare for.

jayd16 5y ago

That's fine but if the job description is explicit about a technology, they probably need the mentor not the mentee.

ozim 5y ago

I would like to take different point of view. Developers also switch jobs to get more salary and market themselves as specialists in a specific stack. I yet have to see developer taking pay cut to retrain in a different tech. Companies already have to factor in training of people on their company specific stuff. That is why no one expects new hire to be fully productive in first 3-6 months. Even if you know JavaScript it still is quite a lot of work to understand code base ... now take someone who does not know JavaScript and as addition has to learn company specific stuff. That is why hiring is like that because "tech" is transferrable skill between companies and developers like to invest into transferrable skills.

mjmahone17 5y ago
Learning JavaScript is such a small cost for an experienced developer who has done any kind of similar work in any language, relative to the 3-6 months of company level ramp up you propose, as to be essentially meaningless. If you need a JS expert because you currently don’t have anyone who can figure out performance problems with junior engineer’s changes, that’s one thing, but you then probably can train that JS expert in any JS framework very quickly. Likewise if you need a UX expert, that UX expert should be able to pick up Swift or whatever language you need them to work in faster than it takes them to grok the business problems you’re actually solving.
nouveaux 5y ago
"I yet have to see developer taking pay cut to retrain in a different tech." I'd argue that most tech just does not take that long to train in. If I am proficient developer that knows Postgres, how long is it really going to take me to be productive with Mongo? This is very different compared to say a web developer moving to robotics. I would take a pay cut for that because the knowledge gap is so wide.

cameronh90 5y ago

> massively inhibits the proliferation of different, new, and interesting technologies Do people really look at the JS webapp framework landscape and feel that LACK of proliferation is a problem?

pc86 5y ago
To be fair, if you exclude the ones that are garbage, you basically have React, Vue, and Angular. Of those three, React is the clear winner in terms of market penetration, but there are certain things in both Vue and Angular that blow React out of the water.
- gkbrk 5y ago
  Many people would consider some of the ones you ruled out as "garbage" as great, while considering React/Vue/Angular as garbage. React is the clear winner in terms of market penetration as that is what happens to projects with the largest marketing budgets / corporate hype.

jarjoura 5y ago

Counterpoint, I made a recent shift to Android from many many years of iOS development. It's not the language that I struggled with, it was the completely different engineering culture surrounding the platform. Yes there are many similarities, things like concerns for battery life and thoughtful network usage. However, that's where the similarities end. The APIs and appropriate architecture decisions are completely different, so I needed to build all new instincts. Then, you have the tooling that are completely different. Where it would normally take me 5 min to jump into Xcode to profile an application, inspect for leaks or other performance issues, I spent a few hours going through Android documentation learning how to do the same thing. Last, and this one is a bit nuanced and sort of hard to explain. As a senior engineer, you're typically expected to help mentor others and maintain the foundations of your product so that as new people join they have a template to work from. If you're switching to something so different, you could end up hurting the team (or company) by using the wrong patterns and promoting incompatible ideas. People need to trust you and if you break that trust at the beginning of your employment, it'll be really hard to earn it back. No regrets though, and I'm grateful to my employer for giving me the space to make the shift. However, I do not believe in the idea you can hire someone at a generalist level and then expect them to be productive anytime soon. There is a saying, "Jack of All Trades, Master of None," and although very cynical, it's just an honest statement when it comes to these things. Hire the right person for the role you need filled first, then if you want to make room for engineers who are looking for big career changes, make sure your product and team won't suffer for that and you have the right culture in place to encourage that kind of growth.

Benjammer 5y ago
I think the key point from the OP you're missing here is mentorship/training to avoid all of the issues you described. I don't think the OP was advocating for hiring the best generalist you can find and then just throwing them to the wolves and expecting senior-level productivity.
pjmlp 5y ago
Being active as a generalist with some deep knowlege across specific stacks I can pretty much vouch this, even on stacks one is conftorable with takes some time getting back to after a couple of months let alone stacks that one never used.

sangnoir 5y ago

> Unless companies start hiring to mentor people this will not change This wont change until SWE stop job-hopping so much. In turn, the job-hopping won't stop until employers stop prioritizing new hire compensation over existing employees...and I don't see how this stops because it's measurably profitable and is self-reinforcing. On the flip side, as an employee, I like that I can reuse the skills I have, it commoditizes employers and lowers the friction in changing jobs. Knowing what I know about capitalism in practice, employers would love the savings from employee tech lock-in.