Hacker News Reader

Comment by onion2k | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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

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

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.

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.

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

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.

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

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.

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

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

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

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

"Buyers are willing to pay for labour at the clearing price based on their assessment of cost-vs-benefit."

If you're competing against firms like Google or startups that just raised unicorn funding, and these days everyone is, then the people bidding in the market or labor are not doing cost benefit analysis. They just need to hire. They have the money, they need to hire and they're going to do it no matter what the price ends up being because that's just what they do. Whether the hires actually generate more value than they're costing is only rarely assessed because the money won't dry up anytime soon.

Additionally, market rates are an abstraction. Consider a simplified example where you have 3 people who need to buy a chicken. They're all starving so they need the chicken or else they die. First person bids $1. Second person says, I'll pay $2. Third person says no wait, wait, I'll pay $3. First person says, I'll bid $4.

This loop ends when only one of the people can still pay and everyone else starves. It does not end when the price has reached some a-priori knowable "market rate" that you could go out and measure ahead of time. To the people actually in the market, they have limited information and don't know what the bidding limit is for the other players, and thus to them it can appear that regardless of what price they bid, they are always beaten by 20%.

In a properly functioning liquid market in which nobody has access to printed money, this cycle is supposed to reach an equilibrium fairly quickly with supply catching up to counterbalance demand. In the actual software market there's been a fairly direct flow from quantitative easing and crypto directly into employers, as well as the yearly 20% revenue bump Google always seems to achieve, so some participants have effectively "unlimited" money. It doesn't make sense to talk about a clearing price in that situation. From the perspective of any normal business that gets money from customers, they will always lose.

> If you're competing against firms like Google or startups that just raised unicorn funding, and these days everyone is, then the people bidding in the market or labor are not doing cost benefit analysis. They just need to hire.

That is a cost-benefit analysis.

They've received funding, they have a business model, now they need labour.

It seems to me your real gripe is that there's a large amount of investment flowing into Silicon Valley and you don't believe that should be happening.

> This loop ends when only one of the people can still pay and everyone else starves.

That's right. And that means, in the valley in particular, some companies will never get off the ground because they can't afford the price for labour.

The solution is simple: hire in a different labour market.

> To the people actually in the market, they have limited information and don't know what the bidding limit is for the other players, and thus to them it can appear that regardless of what price they bid, they are always beaten by 20%.

Sure, that's called incomplete information, and it's a feature of virtually all markets, minus open and instantly traded markets like stock exchanges.

I'm not sure what point you're trying to make, here, other than to complain about a general feature of capitalism that (in a refreshing change of pace) happens to be working in favour of labour.

> In a properly functioning liquid market in which nobody has access to printed money

And now we get to the political axe you're grinding.

Look, the SV labour market has been explosively expensive for 20-30 years. This isn't a new phenomenon by any stretch, and it certainly pre-dates the 2008 financial crisis and the low interest rate environment that followed. There's a reason outsourcing became so popular throughout the early 2000s.

The problem is that tech companies failed to expand their labour pool beyond a few tight markets, either by opening offices in other locations or supporting remote workers. That's their choice, but don't complain when labour prices go up as a consequence.

My point is that you're over-simplifying. You've given two "simple" solutions neither of which are actually responses to the post you were replying to by vbezhenar:

1. "Hire/retain at market rate". Easy unless you don't know what the market rate is, which you don't, because - as you say - incomplete information is an inherent feature of any resource allocation system including markets. Which is probably why vbezhenar phrased their claim in relative terms instead of absolute terms, whilst caveating that this is true for an "ordinary company" but maybe not for Google or governments. Theirs is an inside-the-market view. You're arguing that all you have to do to solve this problem is somehow step outside the market, and just know what the final price actually is for any given person.

2. "Hire in a different market". But that isn't an answer to the OP's point, it's an agreement with it. He's explaining why ordinary companies will refuse to train people. You're claiming the "solution" is to get out of Dodge i.e. not train people. It's not a refutation.

There's no political axe grinding here. What's happening is not unique to SV tech firms. It's an inevitable consequence of CB monetary policy distorting classical market economics. The causes of the policy may ultimately be political, but the outcomes are inevitable.

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

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?

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

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.

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

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

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.

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.

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.

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.

In most cases that I’ve seen, it’s not React that’s difficult to ramp up on, it’s the overly complicated codebase.

Now you could make an argument that React/Rails/whatever shares some of the blame for encouraging/allowing the state of the code.

>"In most cases that I’ve seen, it’s not React that’s difficult to ramp up on, it’s the overly complicated codebase."

Well the developers you want to hire would know zilch about that codebase so you have to train them anyways. And after you do they will not leave because for greener pasture with that new knowledge since nobody else is using that codebase internally.

Reply on news.ycombinator.com