Hacker News Reader

Comment by scarface_74 | Hacker News Reader

Yes because I know Java (hypothetically I haven’t touched Java since two years after it was introduced) I can become an efficient Android developer “in a few days”.

Better yet, since I did Windows CE development for ruggedized devices using C# Compact framework back between 2007-2010, I should have no problem picking up iOS development “in a few days” and start being a productive member of a team right? Or better yet, leading a team?

Third thing, I know the fundamentals of web development including JavaScript, HTML and CSS. But I haven’t done anything on the front end since 2012. Are you going to hire me to help create your website when you’re looking for a modern web developer?

Learning a language is easy. Modern development requires knowing the toolchain framework, idiosyncrasies, foot guns, best practices, etc.

These days, I am only looking for jobs where I have some type of team lead/architect position. Are you going to hire me to lead a team working on a 10 year old complicated Java app when all of my “enterprise” experience is in the .Net ecosystem?

On another note: I haven’t randomly submitted my job to an ATS worrying about an “HR” screen since 2008 across 5 jobs. I’ve always either reached out to my network or had someone reach out to me.

View on HN

Thanks very much for posting this, totally agree. I get frustrated when I hear all these missives about how easy it is for any good developer to learn a new language "in a couple days". I think this paragraph was key:

> Learning a language is easy. Modern development requires knowing the toolchain framework, idiosyncrasies, foot guns, best practices, etc.

That said, I still nearly always hire for general skills and not specific technologies, as long as there is at least one expert in the specific tech under consideration on the team (which there nearly always is). And I budget anywhere from 3-6 months for a person to become truly proficient at a new platform technology.

And you are probably not going to pay me the same as someone who already have the experience you are looking for (and you probably shouldn’t).

Because of the stupidity of hiring and raise practices (not your fault as a hiring manager), you can get HR to open a job req at market rates. But it’s a lot harder to get HR to allow you to give your current employees raises to get them at market rate.

That investment is then lost because your employee is going to jump ship.

its fundamentally wrong to treat your employees learning process as a long term investment that you maintain ownership of. paying someone for two months to come up to speed is an investment. if they become productive in your environment, that investment is very quickly paid off. if they don't, then your at-risk investment didn't pay off. the return is the work that you got from them afterwards. you don't get to claim ownership of what's in their head.

if someone gives you two years of good work and moves on because you aren't giving them what _they_ need, or because their father got ill, you still came out way ahead. you should be a human and accept that.

They didn’t though if I hired someone with no experience. They gave me six months of negative work as they took time away from the more experienced developers, did a year and a half of resume driven development (if they are smart) and then moved on.

If I hired someone with the experience I was looking for, then they gave me 2 years of productive work.

Why would I train someone new instead of just poaching your developer at market rates?

having a mix of experience levels is really healthy for an organization.

streamlining onboarding and extracting the secret recipes from the seniors is really valuable

there is no better understanding than that gained by teaching

its clearly a higher risk investment, but often times that one super workhorse and brilliant jewel is the one that you helped grow

but yeah, I've had employees that just sat around learning the latest fad and left. it happens. but if it happens a lot then maybe you should look at your hiring and management

if I convince someone to come work for me, its not poaching. its life.

> but if it happens a lot then maybe you should look at your hiring and management

You as a hiring manager only have power of hiring and management. Your HR department at the behest of their management controls how much of a raise you can give your employees.

You can give them the meaningless platitudes of “we are family” for only so long.

>Why would I train someone new instead of just poaching your developer at market rates?

Because you pay more, and still have the risk of less/negative productivity anyway? Who says experienced dev won't do 2 years of resume driven development instead? Who says they won't simply zone out and spend their last 6 months being poached the same way you poached them from the last company?

your argument works under the assumption that your experienced hire has no downsides, and there's no risk of upside for the less experienced hire.

I always read "learn" in this context as "be familiar enough with the basic language properties that I can pick the rest up on the job, get things done, and not be too dangerous, or annoying in code review"

and when I read it that way I agree. Some of the best devs I have hired had no prior experience in the stack.

I'm not hiring for Python or C#, I am hiring a software engineer and the skills I value are all transferable.

What about your tech leads who are looking for top of market salary? By top of market, I mean within your hiring pool not senior staff principal engineer level at a hedge fund

What about them? I'm looking for someone who has lead a team, solved that level of problems, has good soft skills and leadership.

The language or stack is irrelevant.

A good lead knows the right questions to ask, understands they don't have all the answers and plays to their own and the teams strength.

Honestly the last thing I care about, especially here, is if they know the stack.

And the other part of “leading the team” is being able to mentor juniors and help them technically.

What good is a lead if they can’t answer technical questions and can’t help other developers with technical guidance?

What will it do for team morale on your iOS team when they know you bought in a “lead” who couldn’t actually help them with the tough technical problems?

The team has a culture that knows full well someone is brought in for who they are ... what they know might need some catch up.

I'm not saying this is right in all circumstances. I wouldn't do this with, for example, realtime embedded.

For what I operate in, fairly bland web applications and stacks.

It works fine, exceptions excepted.

The team has a culture where the leads know less than they do and they are okay that?

There is a persistent attitude that developers are interchangeable, that the tech matters less than the knowledge of how to apply tech to solve problems.

I think that for architecting systems that's probably true, but as technology becomes more specialized and ecosystems become more complex it's harder for individuals to pick up and run with.

Consider if someone has written lots of PHP and jQuery

Now tell them to write a NodeJS server, React Frontend using NextJS.

It's not just "Oh I need to pick up ExpressJS" anymore. It's a whole beast.

Yeah the fundamentals stay the same. REST is still REST, SQL is still SQL, but actually writing lines of code is still a key activity of the job which people familiar with the technology will be better at.

Personally I run into this any time I try and write C#. There's a massive undercurrent of stuff that I feel I don't understand about C# and I bounce off that ecosystem every time I try

> SQL is still SQL

And you’re going to hit a brick wall at 100 mph thinking SQL is still SQL once you try to treat a columnar database like Redshift or Snowflake like you would a traditional database.

That would be an expensive lesson to learn on the job. That’s just one example of trying to pattern match based on what you know when you hit a new to you technology.

It’s like the old school operations people who study one course of ACloudGuru, get a certificate, call themselves “consultants” and duplicate an on prem infrastructure and internal process and their poor clients wonder why they are spending twice as much and not moving faster.

I've never actually used Redshift or Snowflake so I can't comment.

I will say that even moving from Postgres to MySql has a speed bump or two, so I completely agree.

Tech knowledge just isn't as interchangeable as hiring managers sometimes seem to think.

You're generalising to win an argument.

The lead may know less than them about some things. That's OK for us. But what's important is they know more than the team about other things.

For example, we would rather have a lead that knows when to say "How do you know this is performant? Show me." and understands statistics and how to read perf dumps ... than how to profile whatever PHP script or whatever hands-on.

Sorry that contradicts the black-and-white world view you're holding.

I also strongly believe good technical leadership is about accepting you know _less_ than a team, and being able to ask the right technical questions to the right people who know more than you to ensure the best outcome.

You can do that with a ground knowledge of the stack, picked up on the job, along with learning the application's code and architecture. What a good technical lead brings is a deep understanding of how to manage complex people and systems by having done so across different languages/stacks/architectures many times.

Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve.

> Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve.

The reason you would is because while I don’t know Android. I do have years of experience designing systems for field service workers where they go out on the field with mobile devices in places where they may or may not have connectivity. But they still need their applications to work and they work in a “semi connected state” [1] and be able to sync and handle conflicts.

Then you need to know whether the feature you’re going to spend man hours on will break App Store rules. Someone needs to know how long the process usually takes, etc. knowing how to write a complex mobile app is not “easy”.

[1] My four experiences with dealing with mobile implementations

1. Windows CE ruggedized devices back when trucks had satellite dishes on them to get a signal and some customers didn’t want the extra expense of early cellular data plans. These were trucks that delivered propane and other field service work to rural areas or they were in basements

2. Railroad car repairmen in a rail yard

3. Doctors in hospitals that often didn’t have great reception. I wrote the backend syncing protocol for the iOS and Android apps. But I knew the design constraints.

4. Home nurses for special needs kids and often the signal wasn’t strong at home or at the school when nurses would go to the school with the students. This was built on top of a third party forms engine. But you could customize it anyway you wanted using web technologies and it had an API where you could save local data and sync it.

I agree with all of this - and the skill that leaders need isn’t demonstrating (intermediates can do this), but coaching - this will help develop the team to be able to solve the issues themselves.

You can’t coach what you don’t know. And the reality of leading an engineering team is that when your team members actually seek your opinion on a problem, you have to know the specific solution to specific details, not general patterns.

But as a leader, if you don't know - then it's an opportunity for you and the team members to learn it together, the real point of which is teaching the team members how to adapt. Half the crap people ask me, I don't know, but I'm happy to find out with them. And maybe next time they'll be able to figure it out on their own.

And while you are fumbling around trying to learn the technology, the market is leaving you behind, you’re burning through resources and you’re not creating business value by either making the company money or saving the company money.

Great, you learned swift and can do a bunch of leetcode with it. It has nothing to do with actually managing a complicated iOS software project with the zany decisions that have gone into the framework design and tooling. Also good luck with the lazy documentation from Apple and the extremely contrived examples from educators. Can you learn all this in somewhat reasonable time and not code something horrific as a result? Absolutely, lots of people do. In a couple days? Good luck.

Not to out myself and my level of skill, but it took me several days off and on just to wrap my head around the minutiae to get Apple signing for macOS and iOS to work just right. Learning the rest of the ecosystem came along eventually, but I think the real point is with a couple of days worth of intense study, I, and any other developer worth their salt, can bullshit your interview that requires a specific language, but no one requires a specific language for interviews anymore because everyone knows that!

Do your interviewers not ask you to talk through your real world experience?

Having sat on both sides of the table, the job of the one giving the interview is to suss out how much the candidate is full of hot air. The one being interviewed wants to put in the precise amount of hot air required to pass the interview and get to the offer stage. Talking through real world experiences, a candidate can prep and be able to pass despite not actually having had those experiences.

At my last job I was officially a senior software engineer. But I was the de facto “cloud architect”. I was looking for someone to off load some of the cloud work too. I could tell someone who was faking it from a mile away. I am objectively very good at behavioral interviews (my next job at AWS ProServe was based passing a 5 round behavioral interview loop). The guy I eventually chose moved on to be an IT manager at the next company my CTO went to.

I can tell a paper tiger from someone who just went through ACloudGuru and memory enough to pass an exam.

How though? what are some of the tells?

> I get frustrated when I hear all these missives about how easy it is for any good developer to learn a new language "in a couple days". I

It is, maybe you aren't a good developer (yet). The more you do it, the easier it gets. It took me a good time to change from PHP to Python, but from there to Java, JavaScript, C#, Clojure and some 10 more, it only got easier. Toolchain frameworks, idiosyncrasies, foot guns, best practices also follow patterns and gets easier to learn.

Personally, yeah, I would have no trouble hiring you for any of those things, based on your experiences. I wouldn't have expectations that you'd be the most productive member of those teams "in a few days", but a few months, sure. And I would expect your wisdom from working on a bunch of different things to be a lot more impactful than whatever fine grained details you don't yet know of the exact technology we're using.

You're saying that in isolation. If you have 50 other resumes on your desk for a React job, there's no way you're going to choose the guy who hasn't touched front-end since 2012.

I’ve done this exact thing. Stop telling people how they’d act.

Stop telling me how I should stop telling people how they’d act!

I kid.

I agree completely. Even if I did learn React. I still wouldn’t know the tricks to make a modern, usable, website. I would be no good as lead responsible for giving input on best practices and strategy.

Sure you would. It's all the same thing, just different details. You'd do the same thing you do with whatever stack you're currently using: you'd read a lot, do a lot of proofs of concept and prototypes, make a bunch of mistakes, but figure it out and do just fine.

Sure, you wouldn't be as fast as someone who has worked with these tools a million times, and sure, that would matter if you're being hired on a three-month contract to build something and part ways. But if you're being hired to be a valuable contributor and leader at a company, this learning period is going to come out in the wash.

Let me give you an example: At my current company, by my estimation our MVP employee on the engineering side spent most of his career making video games, largely within the Microsoft stack. We do python, go, and React. If we hadn't hired this person because he had never used any of those technologies, that would have been, by a very long shot, the stupidest decision we ever made. This stuff just. doesn't. matter.

And why would you waste money on waiting for me to come up to speed when there are literally thousands of people who know react and can hit the ground running?

And at this point in my career I’m looking for lead positions. Would you hire me to lead your front end efforts?

(my area of expertise is enterprise app architecture/dev + AWS. As a developer I spent most of the modern era of my career working with Node, C# and Python).

I would not be wasting my money, I would be hiring you for all the other skills and experiences you have, which I would find far more compelling than whether or not you already know something you can learn in a few months. If I thought it was a waste to hire anybody who would take non-zero time to learn the stuff they need to know to be an effective employee at a specific company, it would be impossible to hire anybody (except people who already worked there and only left quite recently). Hiring full-time employees is an investment in their ability to contribute net positively to the company over their whole tenure, not in the first few months.

You are right though that I wouldn't hire you to lead a dedicated front-end team. But I'd prefer not to have such a team to begin with. But I'd be happy to hire you[0] to lead a product team working on a product that requires a front-end to succeed. Either other members of your team will know how to make that part work well, and I would expect you to learn quickly from them, or I would expect you to figure it out and then teach the rest of the team.

[0]: I'm using "you" as a stand-in for someone with your experience, who is otherwise a good fit for the organization. I may well not hire you in particular and suspect you would not take a job from me in particular, since we clearly have very different philosophies on specialization vs. generalization and investment in employee training, such that we may not enjoy working together :)

I've interviewed a lot of candidates over my years and technology specific information isn't something I ever look for, unless money is tight.

> unless money is tight

The software dev job market is cooling down. Making good choices on what to build experience in is more important than it has been in recent years.

I think many companies, including mine, are thinking they have only a few spots to fill and a lot of candidates to consider. I know we consistently say things like “who will be productive quickly?”

I honestly think that if you have a short enough runway that "who will be productive quickly" is a prime concern, it may be time to consider hiring nobody and figuring out other ways to save money and extend runway. And if you aren't that desperate, then you should stop asking this question and instead ask "who will be a good investment longer term?".

Alas, that's not how the market works, unless you can pay top of market. So for FAANG, that works, but for startup #293928293 that won't work. They need to ship more features asap (an orthogonal discussion about building the right features is a different matter), and for that they don't have time to bring someone up to speed, only for them to jump to a better paying role once they've upskilled.

I've worked at all different kinds of companies, and I don't think this is the way it works at well managed startups.

The model I've seen at startups is an approximately two-year cycle of 1. raise money against a couple year plan of milestones, 2. hire quickly on the back of that raise, 3. use that personnel growth to hit those milestones, 4. go back to 1.

Importantly, the large bulk of the hiring happens around those post-raise points, when there is a couple years of runway. And the idea of startups is to be ambitious and forward-looking, not myopically churning on short term features.

I would submit that it's even more important for startups to be focused on investing in the right team during those scale-up periods, because many of those people are going to be the leaders during the next round. You want people who are going to be strong stewards of your business as it grows, not just people who see themselves as "react devs" or whatever.

That's not been my experience with hiring. My experience has been that 9 out of 10 resumes that cross my desk have almost no relevant job experience at all.

I'd love to have someone apply to a .NET desktop app position with 5 years of solid experience building Java web services. I'd love to fill a Node.js web service position with at least someone who spent 10 years writing embedded C for home automation devices. Hell, I'll take a brand new CS grad who built a janky Unity3D app in their spare time, not because it was a school project, but because they just wanted to.

What I get is IT network technicians who took a programming certification, substitute teachers who 15 years ago did software QA testing, public policy majors who dabbled with Matlab or Python in grad school, boot camp grads who haven't touched programming again since they finished their 8 week course 10 months ago. People who have never had any experience with the care and feeding of any kind of software project that other people had to work with them on for any significant time.

I'll get 1 resume out of the batch (and they always come in groups of 10) that is just a software developer: for whatever N years of experience, at least the most recent .8N has been software. Then it comes down to figuring out if they were actually a contributing member or spent most of their time hiding in a large team.

> My experience has been that 9 out of 10 resumes that cross my desk have almost no relevant job experience at all.

We're all out here shedding a tear for you. Not too sure what you expect, as they say, the real talent doesn't need to apply to job postings and submit resumes blindly. With that said, is there anything in your .NET desktop job posting that would encourage a Java web service developer to apply? The first day of every month a bunch of people with widely varying backgrounds and experience post on this very site that they are seeking work... ever reach out to any of them?

This is what I find amazing about a lot of the replies I see here. I saw the writing on the wall four months ago that I was probably going to be “Amazoned” soon after my manager left.

I’ve been warming up my network like crazy over the past four months, preparing my resume and career document, etc. I keep my network semi-warm regardless.

When the day came and I had the offer to quit and get big check or stay, I chose the quit option, before my last day, I had one manager trying to create a position for me, a second round scheduled with another former company and a third and final round scheduled at a third company.

All based on networking.

It’s foolish in this market to hope something is going to happen quickly by randomly uploading your resume to an ATS and keyword stuffing your resume like an SEO technique from the 90s trying to juice your position on Altavista.

On the hiring side, a hiring manager also needs a network that they can call on when trying to find candidates.

>the real talent doesn't need to apply to job postings and submit resumes blindly.

I think there's a huge valley of difference between "no relevant job experience" and "real talent". I do a mix of job postings to stuff that looks interesting while also talking to my network.

Sure I would. My company builds stuff with React, but that isn't what's important to what we do. It's just an implementation detail.

I mean obviously it depends on a bunch of other stuff in the resumes and during the interview process. But no, it's not a huge advantage to know React or have done front end development recently, just because we do some front end development in React. It's like the tenth most important consideration for whether someone would be a valuable contributor.

> Modern development requires knowing the toolchain framework, idiosyncrasies, foot guns, best practices, etc.

All this stuff is the same as learning the details of the language. Once you know the pattern it’s not hard to use it in a context with incidental differences in details. It’s usually more than days, but can easily be weeks or months — it depends on how well you really know the patterns. If you really know them it is just days.

But being hired is a completely different thing. Hiring managers (1) don’t understand any of this, generally; and (2) in any case, have no way to directly determine whether a candidate really knows all the relevant patterns. They use past direct experience with the technology as an approximation (a pretty poor one, but it’s easy).

Personally, I’ve done many jobs successfully on stacks I didn’t have previous experience with, almost always as lead or sole. But of course, I got these jobs through people who know me, not a random hiring manager.

(BTW, the skills most important for a lead/architect type have nothing to do with specific technologies. You’re making sure the project/team/product/business doesn’t run into dead ends and progresses efficiently, daily, in the short term, the medium term, and the long term, and balancing their conflicting needs. Probably less than half of this is tech at all.)

I’m a senior dev, having coded commercially for 20 years now, and I think you are correct.

In my time, I have been an embedded C developer, a kernel developer, MFC C++, then J2EE, then Mobile C# .NET, then Python we dev, Python DS, Python Scientific, DevOps, WebDev

These aren’t trivial projects, but entire systems, E.g. I solo built https://atomictessellator.com just to scratch my own itch learning quantum chemistry simulators.

I think you are 100% right, at about the 10-15 year mark learning new languages and tooling really is a matter of days, maybe a week if the tooling is very different. That’s 1 week from no experience in a language to “employable, productive member of a team”

At some point it all just clicks, I suspect the people above who are disagreeing and likely devs with maybe only 5-6 years experience who this hasn’t happened for yet.

Were you able to mentor juniors in best practices and see the foot guns that could happen based on your experience?

BTW, I’m using the definition of senior developer as defined by large tech companies - the whole “scope”, “impact”, “dealing with ambiguity”, “leading initiatives” metrics not “I code really well”.

My experience on the enterprise dev side (1996-2020 and going back on that side now), is that titles mean very little outside of tech companies with leveling guidelines.

BTW, the last time I had only six years of professional experience was 2002.

The last time I only had six years of programming experience was 1992. By then I had done assembly language programming as hobby on four architectures (65C02, 68K, PPC and x86)

My job as a lead was three fold and from my recent interviewing based on the jobs I’m currently looking at it’s the same (cloud+app dev)

1. Working with external/internal stakeholders to define business outcomes and deal with ambiguity and doing project management - from my experience at AWS (ProServe) you can be really good at this with hardly any technical proficiency

2. Determining what is the right service or combination of services to use and the overall architectural design. I could do this without any specific platform knowledge - I know what type of database I need. I know I need a messaging bus. I know the trade offs of different types of technologies.

I was able to go from never opening the AWS console to working at AWS in the cloud consulting department within 2 years. But I sucked during those two years while I was learning the ropes.

3. Using the “right” one of the literally 100+ services and being able to mentor junior consultants and help them troubleshoot complex issues.

The 3rd bullet point is where you need someone who has the specific skillset.

My experience at the second bullet point is the downside of hiring someone based on “potential”. The CTO who hired me threw me at the cloud initiatives without experience and let me figure it out. But paid me $30K less than he would have had to pay someone with experience. He would have never been able to push through the 20%+ raise I would have been looking for when I left 2 years later if I had stayed on that side of enterprise dev/BigTech compensation side.

He definitely couldn’t push through the 50% raise I ended up getting at BigTech.

Now that I did my bid and the pay/bullshit ratio is going too much in the wrong direction, I can go back to my former company (since been acquired) and ask for about the same I would have been asking for three years ago (a lot less than I was making at BigTech)

> Are you going to hire me to lead a team working on a 10 year old complicated Java app when all of my “enterprise” experience is in the .Net ecosystem?

Yes. The skills are fungible.

While that might be the 'right' answer, it's also in the minority for many job openings/postings.

You're not wrong, but thankfully job openings are more fungible than ever too, with remote positions open at plenty of companies that won't make that particular (not-)hiring mistake.

Remote positions make it easier not harder to find someone with the skills fit that a company needs and makes any position more competitive.

When companies were looking for “a C# developer who knew the latest front end framework who was willing to commute to the office in midtown Atlanta” the pool was a lot smaller than “someone legally allowed to work in the US”

Actually it is more like legally to work anywhere, for some kind of positions.

Yep, this is true. But that just means that it's something of a super power for organizations that don't make this myopic mistake.

And I would be a horrible hire to lead a team where I’m expected to mentor junior developers on best practices, which packages to use, how best to work with technical debt, etc.

In the real world, I’m interviewing for positions where they are looking for leads at cloud consulting companies who can mentor juniors and that they can put in front of customers for recommendations, estimating statements of work for implementations on AWS and it’s specializing in application development where you are integrating with AWS services. I have lots of experience with most things AWS.

No one should hire me to do the same for either Azure or GCP. Sure I could do the initial discovery, pre-sales, needs analysis, business outcomes, etc. But I wouldn’t have a clue about what services to use and i definitely couldn’t mentor and help troubleshoot implementations on Azure or GCP.

How hard is it to find a few mainstream opensource projects and emulate what they're doing in a given language when it comes to packaging and best practices?

Other than awful, unsuitable for production languages like ruby.

Most open source solutions are meant to be building blocks for larger projects. It’s up to you to know what’s best for your organization based on prior experience. If you’re not in the C# ecosystem would you know how badly you are shooting yourself in the foot using Entity Framework when you should be using Dapper (a micro ORM invented and used by Stack Exchange)?

On the other hand, would you know the limitations of Dapper until your system grew and you found out that you really needed EF but because you didn’t know the tradeoffs you didn’t know what to look out for?

I don't write crud apps, but if I did, I'm sure I could sort out which ORM is the right one for my usecase.

“I don’t have any experience that is relevant to most of the 2.7 million developers. But I’m sure about my opinions”

Right. You have experience doing what everyone else does, aka, replaceable.

Everyone is replaceable. If you get hit by a bus tomorrow your company will have an open req for your position before your body gets cold.

They will send your next of kin “thoughts and prayers” and you will soon only be remembered when someone sees your name while doing a “git blame”

A less morbid example, what I call the “are you replaceable test”. Can you can hit on your boss’s spouse repeatedly at the Christmas party and have a job the next year?

> Other than awful, unsuitable for production languages like ruby.

GitHub, Discourse, and Basecamp would like to have a few words with you.

Your hyperbolic comment is not far from reality when applied correctly.

I've long said, and would stand by: Programming/Development is logic; learn logic. Languages are just syntax; if you understand logic, you _can_ learn the syntax.

Taking concepts from one language to another shouldn't be an onerous task.

Of course, none of that means you'll get that _senior_ language -focused position, or any particular position at all.

But let's not act like picking up a new language, for a developer, is the equivalent of switching from development to medical practices, or even networking/system administration/etc.

The first language I used professionally was C and I programmed console apps on DEC VAX and Stratus VOS mainframes. All I really needed to know was standard C.

Guess how long the learning curve was at my next job where I had the learn the intricacies of Win32/MFC, COM and DCOM, when to use which of the 8 different methods that Microsoft had of defining a string and how to safely convert between them, why my C++/ATL COM object kept crashing the other developers VB apps because I wasn’t doing reference counters correctly…

I think GPs approach works for junior roles where learning on the job is acceptable. You're right that it would create pain for everyone if the lead/senior guy is having daily struggle sessions as opposed to taking the work to the next level.

>Yes because I know Java (hypothetically I haven’t touched Java since two years after it was introduced) I can become an efficient Android developer “in a few days”.

No, but you probably can in 6 months. Whereas if you hadn't even touched any language and UI framework before, it would have taken you a few years.

Does it have to happen "in a few days" to matter? Or the hyperbole is to argue that past experience with different languages and their concepts, and SDKs and their architecture doesn't help going forward, because each of them is some kind of unique snowflake?

How much similarity do you think there is between modern Android and C# Compact framework in 2008? The last time I did any “mobile development”?

Note how the parent said: "As software developers we learn technologies for breakfast. We learn them, and then we forget them. We recollect the wisdom gained and apply it in our next gig using a different technology".

If you havent' done that with any technology for a full 15 years in some domain, and so can't adapt to the current framework used quickly, it's not like this refutes the parent's comment.

The parent described a situation where you serially learn new technologies and move on, which means there's a lot of concepts that transfer fine, and things that gradually change that you can more easily pick up in much smaller time. If you had done Android development in 2018, it wouldn't be that different to 2023.

> I can become an efficient Android developer “in a few days”.

I'll wager that you can't. Android development is Kotlin nowadays with Jetpack Compose.

Efficient, hardly. Not "in a few days"

>>Yes because I know Java (hypothetically I haven’t touched Java since two years after it was introduced) I can become an efficient Android developer “in a few days”.

You can become whatever you want to become. Hiring is a totally different thing altogether.

Did A for B years is how you get hired. Not what you can do.

Reply on news.ycombinator.com