[another-dave]

On the otherhand, when Cloud Computing started to come in, I knew a bunch of sysadmins. Some were in the "it'll never take off" camp and no doubt they know it now, kicking and screaming.

But the curious early adopters were the ones best positioned to be leading the charge on "cloud migration" when the business finally pulled the trigger.

Similarly with mobile dev. As a Java dev at the time that Android came along, I didn't keep abreast of it - I can always get into it later. Suddenly the job ads were "Android Dev. Must have 3 years experience".

Sometimes, even just from self-interest, it's easier to get in on the ground floor when the surface area of things to learn is smaller than it is to wait too long before checking something out.

[bigstrat2003]

> But the curious early adopters were the ones best positioned to be leading the charge on "cloud migration" when the business finally pulled the trigger.

lol no. There's nothing actually different about managing VMs in EC2 versus managing physical servers in a datacenter. It's all the same skills, and anyone who is competent in one can pick up the other with zero adjustment.

[swagmaster8008]

Maybe in a greenfield environment, but this I disagree with your assessment in an enterprise setting. Have you worked with orgs that have on-prem + cloud and are migrating? It is a massive pain and regardless of whether it's easy, people and orgs don't want to do it.

[rewgs]

But here's the thing: learning Android dev is nothing like "learning" to use an LLM.

Obviously there are tons of tools and systems building up around LLMs, and I don't intend to minimize that, but at the end of the day, an LLM is more analogous to a tool such as an IDE than a programming language. And I've never seen a job posting that dictated one must have X number of years in Y IDE; if they exist, they're rare, and it's hardly a massive hill to climb.

Sure, there's a continuum with regards to the difficulty of picking up a tool, e.g. learning a new editor is probably easier than learning, say, git. But learning git still has nothing on learning a whole tech stack.

I was very against LLM-assisted programming, but over time my position has softened, and Claude Code has become a regular part of my workflow. I've begun expanding out into the ancilary tools that interact with LLMs, and it's...not at all difficult to pick up. It's nothing like, say, learning iOS development. It's more like learning how to configure Neovim.

In fact, isn't this precisely one of the primary value propositions of LLMs -- that non-technical people can pick up these tools with ease and start doing technical work that they don't understand? If non-technical folks can pick up Claude Code, why would it be even _kind_ of difficult for a developer to?

So, I'm with the post author here: what is there to get left behind _from_?

[aworks]

"must have X number of years in Y IDE"

Not quite on topic but as an engineering manager responsible for IDE development, explaining to recruiters and candidates I wanted engineers who developed IDEs, not just used them. Unfortunately, that message couldn't get through so I saw many resumes claiming, say 5 years of Eclpse experience, but I would later determine they knew nothing of the internals of an IDE.

Presumably, people now claim 3 years of machine learning experience but via ChatGPT prompting.

[aleph_minus_one]

> On the other[ ]hand, when Cloud Computing started to come in, I knew a bunch of sysadmins. Some were in the "it'll never take off" camp and no doubt they know it now, kicking and screaming.

> But the curious early adopters were the ones best positioned to be leading the charge on "cloud migration" when the business finally pulled the trigger.

From a technological perspective, these sysadmins were right: in nearly all cases (exception: you have a low average load, but it is essential that the servers can handle huge spikes in the load), buying cloud services is much more expensive overall than using your own servers.

The reason cloud computing took of is that many managers believed much more in the marketing claims of the cloud providers than in the technological expertise of their sysadmins.

[bigstrat2003]

Yeah, most companies still should not be using cloud for stuff. I think a lot of people here who work for startups don't get that, because cloud makes a ton of sense if you're a new business that has a hundred other higher priorities than spending capital on infrastructure and sysadmins. But for most companies? They are better off with on prem.

[SoftTalker]

> Suddenly the job ads were "Android Dev. Must have 3 years experience".

So just read up on it and say you do. They don't really need 3 years experience, so you don't really need to have it.

[bitwize]

Employers check your work history. You'd better be able to back up having the amount of experience they require with paid, value-delivering work at past employers, or they'll pass.

[aworks]

I was an engineering manager an for decades and I did first technical phone screening of a very large number of candidates. I couldn't really assess someone's design and programming skills. So I would pick a particular area they were promoting and go as deep as I could on it, both on the technology and their project experience using it. I weeded out lots of candidates, saving my engineers' interview time for more suitable candidates. And my teams were good at giving me feedback when I let someone unqualified e slip through...

[SoftTalker]

Many actually do not check anything.

[bitwize]

I've never actually encountered one who didn't. Just like I've never been able to actually quit on Tuesday and walk into my next role on Thursday the way Hackernews told me "any halfway decent developer" should be able to do. They tend to ask about this sort of thing in interviews too and if you prove not to have the required background, you are considered weak and filtered out.

Anyways, checking happens often enough that the risk of being considered a liar and a fraud for claiming experience you don't have is high.

[mablopoule]

I'm not sure why you're downvoted, but this is the right take IMO. I hate cheating and lying in general, but in any job posting you have to separate what are the actual requirement in term of knowledge versus what can be realistically learned on the job / doing a prototype in a weekend.

Of course don't fraud by like pretending you're a statistician when you have absolutely no mathematical background, but also don't take at face value the "Must have {x} years of experience in {y} tech" requirement when you know you have the necessary work experience to have a good grasp on it in a few weekend prototypes, and you also know that the job doesn't actually require deep expertise of that particular tech.

I did the same for my first React.js job, and I didn't feel bad because 1) I was honest about it and did not sold myself as a React expert, and 2) I had 10 years of front-end development, and I understood web dev enough to not be baffled by hooks and the difference between shallow copy vs. deep copy of a data structure, so passing technical test was good enough for it.