I don’t buy it. 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. It works for mobile development, for frontend, for backend, for infra, for almost anything.
I have worked for years with PHP, Apache, Ansible and MySQL. Nowadays not anymore. And in 7 years I’ll be using something else. Learn the fundamentals (which is not a one-time job, btw) and you’ll be fine. If someone asks for technology X in their job offers when you know Y, but you know you won’t have difficulty in learning X, just take a few days in learning X and then put it in your CV. You’ll get pass HR screening and then you’ll have a chance to explain in tech interview that your are more of a technology-agnostic dev. You’ll do fine.
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.
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.
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
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 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.
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
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 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!
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.
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?
>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.
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.
> 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.
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.
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 :)
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.
> 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.)
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)
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)
> 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?
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”
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?
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?
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?
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.
>>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.
It's one thing knowing the language, it's another being productive with the ecosystem.
One takes between a few days and a few months. The other is a few years, unless you get pro training.
I guarantee most people starting with Python from another language will be productive quickly. But they will curse the packaging ecosystem because they will follow a lot of tutorials that don't follow this:
Yeah I learned Ruby on Rails very quickly a long time ago, it's probably one of the most accessible frameworks to learn, but it took me years to master all the weird quirks, dev environment stuff, debugging, production deployment etc. Plus from all the years doing it I'm familiar with all the old libraries so when you join a company with a large legacy code base, which at this point is very common for rails, I don't have to spend forever learning the details of some 7yr old implentation no one uses anymore.
Working with senior devs who have only been doing it for 1-2yrs is where you see the small productivity differences that aren't simply being a newbie programmer.
You're seriously arguing that someone with general knowledge of programming is going to get hard-stuck not knowing specifics of a language you and thousands of others have blogposted about for years, while linking your own posts?
Let's be real here. What percentage of companies are in dire need of 'experienced [language] programmers' who know these specifics that haven't already been set by previous devs or have another developer present to make the decisions? That's a tiny, tiny percentage of the entire job market, with much of the demand coming from companies with incredibly shaky foundations.
Almost the entirety of this is a luxury problem put on the individual. The moment the job market says they can't demand it anymore, they won't.
Last week I talked with a guy who was pitching to rewrite their entire product in another language because he never heard of python GIS ecoshst and was doing spatial calculations by hand. Would cost hundred of thousand euros.
I don’t agree at all. I was productive within a month in a completely new language and stack at my current job for example. Once you know a few inside out, it’s just pattern matching with some Googling of “what’s X in Y language”.
Extremely deep knowledge of a language is very rarely needed, even when it is as long as you can somewhat vocalize the problem it’s just debugging
I agree, but unfortunately hiring managers, recruiter etc. don't think like this. If you happen to find a person that is tech-savy, they can asses your true skillsets and capabilitiy of solving problems. Hiring managers and recruiter match buzzwords in your CV.
I recently got rejected for a project from an agency (am a contractor) because I did not have provable skills or knowledge in "CI/CD". Stupid me, made the mistake of putting extensive details about creating build and deployment pipelines with Travis, GitLab, GitHub Actions, Azure Pipelines for each past project going back to 2012, but did not specify the right buzzword "CI/CD" for the recruiter...
> Hiring managers and recruiter match buzzwords in your CV
So? You put those buzzwords in your CV. What’s difficult about that? You feel like being dishonest? If so, again, just explain in the next stage of the interview (with real engineers) that you do have real world experience in similar but not exactly the same technologies listed in your CV. You just did so to pass through HR. Not a big deal (as long as you’re confident and believe you can learn technologies easily)
Blatantly lying on the CV is an instant rejection at the places I've worked. It's one thing to stretch your contributions on past projects, but to outright lie about the technologies used is a huge red flag. It's easy to teach a person the company tech stack, but I'm not sure it's possible (or worthwhile) to try and teach some one to be honest.
I have made some "SEO" optimizations as some agencies use text-based CV matching. Some are upfront with it, with others I observe it because I get a lot of Java project requests (I never coded Java, but as a FE dev, have lots of JavaScript in my CV text).
I'm gladly looking forward 3-5 years, when AI will handle this CV analysis and match a project description from a company to a proper candidate. Basic GPT can tell right now if CI/CD matches "Azure Pipelines". Then we can fire the lower 50-80% of unskilled recruiters that do not provide any value to the market right now.
Absolutely, I feel I could be employed tomorrow in a language or stack that I haven’t even heard of and start being productive by the end of the week!
I seriously think you owe it to yourself to practice learning something new every week. It often takes one afternoon to get a “taste” and small side project to get beyond that.
Every programming language. Is literally just a template for instructions, and every technology just an abstraction over some crud somewhere.
My experience is that learning a new language -at a basic level- can be done quickly (like a couple of weeks, not days).
But learning it at an advanced level, is a whole different matter.
I've been writing Swift since, literally, a few hours after it was announced, in 2014. I write Swift every day (like, seven days a week), and have been, since that first day.
I feel as if I have only had "mastery" of the language for the last couple of years. There's still plenty for me to learn, and they keep adding more stuff.
But the language isn't the big deal. The deal for me, is the fundamental SDK/API/Framework. That has been an ongoing project since 1986. As soon as I learn one API, they change it up (and sometimes, the entire OS).
During that time, I've written in 68K ASM, Pascal, Object Pascal, C, C+- (the weird THINK C variant), C++. ObjC, and Swift. I've worked with MacApp, OpenDoc(!), Think Libraries (Pascal and C), PowerPlant, and Cocoa (and its expression in iOS, WatchOS, AppKit, and TVOS).
I've always considered hiring folks to be an investment. As a manager, I always looked for folks that had the fundamentals down, and assumed that I could train them into what we need. Most of the work we did, was way beyond anything you'd find in textbooks. I was under no illusion that I could hire folks that would be able to start on it right away.
That was why my team was always one that I wanted to keep whole and cohesive, over many years. I can't even imagine today's 18-month engineer lifetime. I kept my engineers for many years, and that wasn't easy.
But as far as employees being an “investment” let’s look at things from the employee side.
For context: these numbers I’m about to cite are correct to within a first approximation on the “enterprise dev” side where most of the 2.7 million developers work and in most major cities in the US that are not on the west coast or in NYC
Let’s say you hire a
Junior/mid level developer and offer them $100K which is fair knowing they are going to do “negative work” for the first few months as an investment. Two years later, they have experience and now can apply for companies that are looking for experienced iOS developers. Their market rate shot up to $135k.
Because of salary compression and inversion, you’re not going to be able to pay them 35% more in two years because of HR policies. Yet you can bring in new experienced iOS developers at market rate. If he’s smart your employee is going to jump ship, wasting a lot of your “investment”.
As a hiring manager, knowing that statistically I’m only going to get two years out of an employee, why wouldn’t I just poach the person you just trained and pay them the $135K you couldn’t?
Another scenario is that now that developer has been reading r/cscareerquestions and decided to “grind leetcode and work for a FAANG”. Now he’s looking at $200K+ as a mid level developer adding yet more bloat to the Facebook app.
> You couldn’t compete with that if you wanted to.
Unfortunately, I was forced to.
My company was one that paid “competitive” salaries.
That’s code for “below average.”
This filtered out 90% of applicants, right there.
So the ones that applied, did so, out of genuine interest in the company and the technology (we were a “marquee” company).
I was forced to look for “diamonds in the rough,” and became fairly good at evaluating whether or not someone could handle the tech and the learning.
I kept them, by being a really good manager. I treated them with respect, didn’t burn them out, and shielded them from a lot of the corporate BS. They appreciated that, and stayed.
When our team was finally rolled up, after just short of 27 years, the employee with the least tenure had ten years. These were seasoned C++ image processing professionals.
Most of those 2.7 million developers I spoke about will never make low end FAANG money and that’s perfectly fine.
I had my first house built in the burbs of Atlanta in 2002 making $60k (2500 square feet) and my second house built in the northern burbs (3200 square feet) making $135K in 2016 [1].
I only fell into a remote role at BigTech in 2020 at 46 years old after declining a chance to interview for a software development position and being offered a chance to interview for a position in the Professional Services division doing cloud consulting [2].
I was perfectly happy living the upper middle class lifestyle in 2020 making only $150k with my wife making $20K working part time.
In fact, I’m excited to get back to working at small companies on the high end of enterprise dev comp because my department became too “Amazonian” this year and my shit tolerance level is extremely low.
[1] 2002-2012 was a decade of bad life and career decisions that I didn’t recover from completely until 2018.
[2] I did my bid, saved money and paid off debt and our bills are actually $1000+ lower per month now than they were when I started.
> you’re not going to be able to pay them 35% more in two years because of HR policies
Seems like you just identified the issue. You're right, of course, that the "invest in employees" approach doesn't work at companies that have a corporate policy to not invest in employees.
Investing in employees is a top-down strategy, not a bottom-up one. If there isn't support for it at the top, then you're right, it won't work.
I think all the "a few days" and "a week" stuff that generates these kinds of debate is a total red herring. Yes, it's hyperbole. But it's also true that people with experience successfully applying a bunch of different technologies are great hires onto a team using a technology they don't yet know. It's just a process measured in months rather than days. But if you need to hire someone because you have something that needs to get done this week, then you've already screwed up.
And then it gets back to my other argument. Are you going to pay someone the same that doesn’t fit your technical needs as you would someone who does? If you pay them less, are your raise policies going to allow you to get them to market value once they do have the skillset or are they going to end up job hopping?
Personally, I would not take this into consideration when deciding how much to pay people.
I recognize that there are a lot of different niches in our industry, and presumably in some of those niches this narrow focus on what technology is being used makes sense, but that hasn't been my experience.
In my experience, you want people who are both pragmatic and flexible about learning, evaluating, choosing, and teaching others new tools.
I do recognize this may be a somewhat privileged view. I think I've been fortunate to spend my career in organizations where software is the profit center rather than a cost center supporting the rest of the business. My experience is that these companies have focused their hiring, compensation, and performance expectations on fundamentals and figure-it-out-itude rather than any specific technology stack.
Not iOS, but I'm fairly confident I could be productive in an Android codebase in a week.
The only reason I don't think I could do iOS is because I'd need to use a OSX, and I think it would take me longer to become productive in OSX.
It also depends on what you mean by "productive", would I want to lead a team to create a new app from scratch? Probably not. Go into an existing app and start fixing bugs and creating new features? Sure.
I did a trial week before joining my current gig full-time. I had pretty much no typescript experience, came into a large TS react/nodejs app and had a pull request on the 2nd day for a new feature.
I wouldn't try to work on a Haskell or OCaml codebase, they are different enough that I'm not confident I could pick them up quickly. But most mainstream languages are similar enough that it really shouldn't be that hard to pick them up and be productive.
As someone that has done on and off Android programming as hobby since NDK was introduced in Android 2.2, and regularly follows ADB Podcast, I doubt it.
Every Android version is basically a reboot in many parts of the framework, the device fragmentation is hardly any better than J2ME days, several features are only documented via samples or Google IO talks, Gradle plugins require rewrites between upgrades, and each Android Studio release is a box of surprises what quirks it has.
I think it really depends on what your definition of "productive" is.
Let me try and quantify it. I looked through my apps that I installed from F-Droid, then looked at their GitHub issues and picked one [0]. I bet I could implement that in less than a week with 0 Android development experience.
> Every Android version is basically a reboot in many parts of the framework, the device fragmentation is hardly any better than J2ME days, several features are only documented via samples or Google IO talks, Gradle plugins require rewrites between upgrades, and each Android Studio release is a box of surprises what quirks it has.
Does any of that really matter if you're hiring someone into an existing org? Doesn't Android have amazing backwards compatibility? I'm sure I have some dice app from 2012 that still runs. The company is probably targeting some version of Android and isn't changing to the latest one every time a new version is released.
Are you trying to find a job as a journeyman developer (nothing wrong with that) or are you trying to lead a team or be a senior where you are expected to be productive from day one and maybe mentor developers and be more strategic?
Would you hire me someone who not only doesn’t know anything about Android development but doesn’t even follow the ecosystem and the current trends?
If I was looking for a job, I'd say that I have no professional Android experience but I'm confident that I could hit the ground running at a senior level and mentor juniors for Android.
I mean, in this hypothetical scenario, I've decided that I want a job as an Android developer. So I would take my own time to learn Android whilst interviewing. By the time I got a job, I'm confident I'd hit the ground running.
I wouldn't try to apply for a job to lead an Android team without at least working in one first. I'm sure some people do, but I'm not that confident ;).
> Would you hire me someone who not only doesn’t know anything about Android development but doesn’t even follow the ecosystem and the current trends?
I wouldn't hire you because you don't sound like you think you could do it.
If I was interviewing someone and they said something like: "I have no experience with Android, but I know Kotlin and I'm confident I could pick it up. I did a similar thing with x,y,z" then sure.
> If I was looking for a job, I'd say that I have no professional Android experience but I'm confident that I could hit the ground running at a senior level and mentor juniors for Android
I can say I’m a little teapot. But without demonstrated experience, why would you hire me over one of the million developers with experience and have at least shipped an app?
> If I was interviewing someone and they said something like: "I have no experience with Android, but I know Kotlin and I'm confident I could pick it up. I did a similar thing with x,y,z" then sure.
Yes because “positive thoughts” without experience means you can be effective
Already with that response you have proved not to understand the Android ecosystem.
No it doesn't have an amazing backwards compatibility, specially depending on what is cool in one Google IO, and already legacy in the new one, without replacement, like e.g. Tango, Sceneform, Fragments.
There are policy rules how old an Android app is allowed to be in Play Store.
I don't care what platform you are targeting: unless the entire purpose of your product is to take advantage of the feature (which is sometimes fair), you never ever ever EVER integrate whatever is "cool" from the latest keynote.
Regardless, while Android requires you to compile new apps with the latest toolchains to release, and you might have to update some stuff in your manifest, they do not force you to use new APIs, they do not require you to stop supporting old versions of Android, and I've seldom run into a backwards compatibility issue that wasn't some corner case involving the weird intents we have to use (as our app relies on being a VPN).
Time to acquaint yourself with Play Store policies and what should be the minimum API version for uploading new app versions, which do force to use new APIs, that is the whole point behind it.
Besides the whole Android example, was just that, I can give several examples of technology stacks where having a passable knowledgeable of a programming language, without the associated frameworks that are being used in the company, makes the candidates a no hire, unless they really excel themselves at the interview, assuming HR even cares to call them in.
sigh, look again: you have mixed up "target" with "min" :/. This is a critical distinction that you can't just gloss over: you simply are NOT forced to use new APIs just because you bumped the target... at build time it might activate the ability to choose to use some new APIs if you want to, but the biggest effect it has is at runtime to affect the various subtle--and extremely limited--backwards compatibility behaviors I mentioned (similar to how iOS uses the version of UIKit you linked your app against) which tend to mostly limit specific scenarios where security issues or bugs were found in older designs.
FWIW, I am seriously the build engineer for an Android app distributed in the Play Store (and have maintained apps for Android since the platform launched and it was still called the Android Market), and I'm telling you: you are not just wrong, you are being loudly wrong... not just about this (where the wrongness frankly feels egregious at this point), but your entire point: I have taught classes at the university level on how to rapidly pick up programming environments, and the lead UI developer I hired for our company had almost no experience in the toolkit we are using before we hired him and he's doing fine with it.
As of the rest, in most companies I worked on, unless the higher ups are bypassing the hiring process, due to networking and acquaintances, such CVs never get through HR first round of filters.
>There are policy rules how old an Android app is allowed to be in Play Store.
yup, but we're not talking about new feature to removed in 2 years level of radical changes. It's still something coporate uses and coporate doesn't latch on every cool feature.
You can probably expect your newest API app to work in 5 years if you don't touch it. You probably can NOT expect it to work in 10 years. That just means you need to make sure you're never 3+ years behind on using deprecated features.
> It also depends on what you mean by "productive", would I want to lead a team to create a new app from scratch? Probably not. Go into an existing app and start fixing bugs and creating new features? Sure.
As someone with experience, are you actually applying for jobs where you would just be pulling stories off the board doing “feature work”?
And let’s take your example. What’s the chance of me being productively able to create a feature in a Typescript/React app seeing that I haven’t done front end work since 2015 and even then it was server side rendering with ASP.Net MVC and bootstrap.
> As someone with experience, are you actually applying for jobs where you would just be pulling stories off the board doing “feature work”?
I dislike the whole Agile stories/points/sprints thing, so probably not those jobs. But if you're asking if I'm applying to jobs where I write code, then yep! I love writing code and building things.
> And let’s take your example. What’s the chance of me being productively able to create a feature in a Typescript/React app seeing that I haven’t done front end work since 2015 and even then it was server side rendering with ASP.Net MVC and bootstrap.
I don't know what other experience you have, but probably. At my previous job, I got a bunch of silicon production test engineers, that spend most of their day writing VBA, "productive" in React within a week.
I setup the base of the application and sorted out the routing, state management and abstractions for dealing with our data. But they were writing views and features after a week pretty well. I had to point out some performance issues in code reviews but that was mainly it.
> I don't know what other experience you have, but probably. At my previous job, I got a bunch of silicon production test engineers, that spend most of their day writing VBA, "productive" in React within a week.
It depends on your definition of “production”. I got a couple of developers who had spent a decade+ supporting a PowerBuilder app and writing stored procedures.
Their C# code was a horrible mess.
My former CTO (55 years old and his idea of research was coding POCs - smart guy), said he wouldn’t hire “old people” any more to do front end work because their front end designs weren’t as good as people who started out doing front end work and have been doing it for years.
All of his back end developers/architects were older.
If your resume shows you job hop regularly, then I’m going to want you to be productive very quickly.
If your resume gives me the impression that you are likely to still be working here for enough years, then I’ll give you time to get up to speed. If you were a really great front end developer in 2015, I suspect you can figure out Typescript/React.
I sucked back then too at front end development :).
I knew enough to copy/paste/pattern match an existing page and make the necessary change. But you start me with a blank slate and give me a mock-up, I would end up using tables and frames like it’s 1999.
During Covid I had a colleague, mainly web/js/angular dev, join the Android team. It was a new project to him, so he had 0 idea of the business problems, flows, etc.
In a timeframe of 1-2 weeks he was making PRs. It needed quite some reviews from me, usually because he didn't know about "how it should behave" on Android, or what the best practices were in terms of using Kotlin or following our architecture. After 2-3 months he was as proficient coding as I basically (but we all know, coding is 50%).
i did this with php and python in two different jobs. i had very little php experience and never worked with any php framework before, but the team i was in consisted mostly of junior developers, so i ended up writing better code than any of them except the team lead. laravel was also very easy to understand.
at another job i started with only some rudimentary python experience. they had an inhouse framework, so being deeply familiar with python frameworks and libraries would not have even helped me. they knew i had experience in other languages and it worked out pretty well.
most recently i had an interview where it was very clear that i haven't done any work on go before. at least during the interview that was not an issue. after the interview they wanted me to send them code examples of previous work. i didn't get the job, but i don't think lack of go experience was the problem.
>don’t buy it. As software developers we learn technologies for breakfast.
This is such a funny mantra. Okay learn how nuclear fission works. Or EUV lithography. Or power transmission across superconductors. All of these are extant, commercial, technologies (yes even the last one). Too much? How about something more pedestrian like overhead cams and electric fuel injection? Too far afield? Okay learn how DMA works on a GPU - not how to call `copy(host, device)` but what actually happens and more importantly why.
The truth is software developers learn APIs, not technologies (and not over breakfast either). Point being, it's not good to be haughty because if tomorrow you were out of a job and the only place hiring was the Ford motor plant I think you'd be just as fucked as the author of the post.
You're just arguing semantics. And the example given can go the other way: if your Ford motor plant closes and the only places hiring are software shops, you'd also be "fucked".
I never have any clue what this retort means: when exactly are semantics (the meanings of things) not important?
> Ford motor plant closes and the only places hiring are software shops, you'd also be "fucked".
That's one hundred percent true but the difference is I don't see assembly plant workers going around claiming they learn technologies for breakfast (or lunch or dinner).
>when exactly are semantics (the meanings of things) not important?
arguing over meanings when we should understand the meanings tends to mean you're nitpicking instead of clarifying. There's clarification and then there's bike shedding.
> As software developers we learn technologies for breakfast.
...
> I have worked for years with PHP, Apache, Ansible and MySQL.
As much as I agree with your general sentiment that adaptation is one of our primary skills in this industry, these two statements combine to sound like parody. You “eat new technologies for breakfast” but PHP and Apache are in your short list of technologies you’ve used for years?
> And in 7 years I’ll be using something else.
And 7 years for your prediction of when you’ll be using a different technology is both oddly specific and oddly long.
Apologies if this comment actually is parody and it’s just flown over my head.
Everyone goes through this once. A lot of your knowledge suddenly aren't needed anymore because of external factors. For me it was Flash. I've seen colleges being afraid of learning new technology after being burned once. Now my skills are learning new skills.
I also did Flash for a long time. 10 years later it’s not like that experience is mostly lost. When I write typescript I get a dejavú to AS3. Plus knowledge of VMs, garbage collection and all the other programming concepts translates to most languages
The biggest money I've made technology on is C, which I don't really know, just basics.
I've wrote some js, ts, c++, lua, used some postgres+mssql+mongo, yada yada and stuff
but when writing CV I'm not saying that I know those, just that I have experience with those. It is probably bad strategy cuz people inflate their skills, but who knows.
There's giant difference between person who "can use tech" and person who "understands to the point that he/she feels particular tech".
"Feeling" technology takes years because you need to understand its ecosystem, why some approaches to some problems are more common within this tech, historical context, internals, etc, etc.
Sure, but say you focused as a iOS developer you definitely cannot tell the recruiter doing Android are the same. They wont hire you if you say you have no Android experience, same thing
The probability of success is largely is based on the available supply of developers vs the demand for them. Canada’s market is ok, but not great which is probably why so many Canadian programmers immigrated south.
Oh come on. Language specific knowledge is a game changer in programming speed & efficiency. Likewise the level of effort to understand modern React concepts has gone way up.
Deep React specialization is a great way to get most tech jobs. Some interviewers literally just want to see if you can use hooks in a solution. Applying a learners mindset in the middle of an interview comes off as amateur.
Learn the tech stack you’ll use on the job. It’ll get you tons of mid grade offers.
Dart is my biggest issue with Flutter. It's still missing ergonomic features like data classes and lower level things like unsigned 64-bit integers. There is no runtime reflection, which I think is a good thing for end user apps, but it's also missing static metaprogramming. And code generation is not integrated into a complier. Since, there is no runtime reflection, metaprogramming & integrated code-gen are sorely needed.
Flutter itself is slowly reaching maturity on mobile and is already quite good, if you can live with a few compromises.
The biggest issue with Dart IMHO is not so much the language itself, but the ecosystem.
For the record, Swift suffers from this problem as well. Kotlin only avoids it because of Java interop, although even this becomes complicated because of Google’s half-assed implementation of Java on Android.
I think this is one of the biggest reasons to reach for JavaScript instead. It has a lot of flaws, but it has a huge ecosystem that works nearly everywhere.
It may lack things - true. But it's a pleasure to work in. I code quite a bit of Dart these days and the language never really holds you back. It flows quite easily. I use some code generation by having a build runner in the background.
I definitely like it more than Python () and probably more than Typescript (the best non-niche scripting language available today). But there are some quite glaring holes and weirdnesses. In particular:
* The support for tagged unions (Rust style enums) is pretty nonexistent.
* `int` is 64-bit but not on the web. I totally get why they did that and hopefully they can fix it with wasm at some point but it's very annoying for interop with languages that have the full range of int types.
* As many many people have said, it's quite verbose to make dataclass style types.
But it still deserves to be way more popular than it is. It's basically what JavaScript would be if it was designed by someone with taste.
I'm wondering about this as well, actually this weekend been doing Flutter 'Test Drive' of their tutorial and experience was not that great. I'm still forcing my brain to parse this complex structure with very simple widget structure from their samples.
Its Flutter:
```
class MyHomePage extends StatelessWidget {
@override
Widget build(BuildContext context) {
var appState = context.watch<MyAppState>();
var pair = appState.current;
With the help of the IDE (Android Studio is what I use for Flutter development) it is actually pretty OK. It's easy to use keyboard shortcuts to see / explore function parameters and so on. I also indent regularly so I can easily undo if something is clearly out of whack.
That said, SwiftUI is clearly the supreme leader in this declarative approach.
I'm curious at the point you are trying to make - I don't know any of the three but Flutter looks by far the most obvious and easier to read and understand
I recommend putting those code snippet I shared to VSCode and using default formatting - this will be more visible in IDE. But other annoying things for me:
1) SwiftUI feel more like jquery so that you can chain styles like padding, color, font etc. Because of that :
- code completion just works and is fast you just press a '.' and see all choices
- it's easy refactor the code if you wan't to change styling or layout
2) Flutter abusing too much composition and adapter pattern to the point they using refactoring in VSCode to add simple padding etc. Just have look at this official GIF from 'Test Drive' - how many times 'down arrow' got pressed:
Now imagine designer come to you and telling you we change layout and styling slightly - in flutter I feel it's easier to throw away such layout code and start from scratch than trying to refactor it. In swift UI you just change VStack to HStack, change maybe some parameters and move around chain of .padding().color() around and are done with it.
What would improve flutter readability is extending Dart to have something like Swift:
- first parameter can be marked as optional specifing parameters name such as '_ child:'
- escaping parameters in Swift so you instead of doing ... children: []) you can just close previous Widget and make also 'children' parameter name optional so that you can write :
I don't understand why this language exists. It just feels like a promotion vehicle by someone at Google who had enough clout to then get it shoehorned in to Flutter. If they had gone with JavaScript they could've made the switch to TypeScript later on. I realise this is being said with the benefit of hindsight but Flutter would be in a far better place today I suspect.
It compiles AOT to native code and supports tree shaking. It also has JIT mode with hot reloading/restarting. It has sound null safety and is statically typed.
It's not a bad language. It just lacks some needed features. They'll probably get implemented over a span of a few years.
Ecosystem is small, but at least there's FFI interop.
It also has some baggage from it's early days when it was meant as JavaScript replacement. Since we now have WASM (and soon WASM-GC) I think it would be best, if compilation to JS would be dropped, so more low level features can be implemented.
I agree. The team behind the language is the real problem.
> It just lacks some needed features. They'll probably get implemented over a span of a few years.
For years they have dismissed calls to add multi-threading in the language, despite it being sorely needed for anything computationally non-trivial (isolates have ridiculous overhead).
> Ecosystem is small, but at least there's FFI interop.
FFI continues to be a disaster (to be fair, this is not unique to Dart/Flutter).
The biggest problem with any cross-platform system on mobile is always getting performance out of the native interop. It's often easier to ship a computation to a server on the web and ship teh result back rather than execute it natively on another thread on the bloody phone. It's infuriating. We have a zillion cores, and every single phone OS tries it's damnedest to prevent you from using them because, heaven forbid, you might actually use up some of the battery. The Horror! The Horror!
The cross-platform systems for phones are really good at doing puzzle games or CRUD. Step outside of that and you enter "Here Be Dragons" territory very quickly.
The language exists because of AdWords, they had recently migrated from GWT to AngularDart when everything fell down, regarding Chrome team jumping off the DartiumVM integration, eventually with all this process most key designers like Gilad Bracha, and Kasper Lund leaving the project.
When Flutter came around, for whatever reason they decided to pick Dart, the original prototype was in JavaScript (the official reason being it wasn't good enough given the language semantics), and Dart 2.0 effort started, with the language gaining strong typing (it was dynamic with optional typing in Dart 1.0), and AOT compilation support.
Dart is actually hands down one of the most productive languages out there right now in terms of ergonomics. It’s still a tiny language ecosystem at the moment but there are already a lot of happy paths that will get you to an incredibly high level of quality with very little work.
I really wish somehow Flutter or react native would be written in Rust or some other language on the same level. I hate having to deal with JavaScript or some half baked compiler.
It has been interesting seeing how many interviewees coming in for a mobile app developer positions in the last 4-5 years have made bold claims about native development (Obj-C/Swift/Kotlin/Java) being dead due to Flutter, then fumbling completely when asked to solve problems that would require them to drop 'down' into the native environment.
Having Flutter in the toolbox is quite a good thing, unless there is nothing else in there. Then you are in trouble.
You need to know JS to be a React guy though and that's easily transferable to another JS framework or other frontend work, where is Dart used other than Flutter?
For anyone reading this and if you want to develop mobile apps, just first learn native iOS/Android platforms, they are not going anywhere before you get tempted by other flashy technologies like Flutter or React Native. Most companies including the ones that created these cross platform frameworks, build thier core apps using native stack for a reason.
I used to say just this. And I did native Android dev for many years, but I gave it up around 2019.
When I finally checked out, native Android was a teetering mess of compatibility libraries, half-baked never-finished “new ways of doing things”, lacking docs, forever-bugs, and overall neglect. Simple ui would take you 5x as long as equivalent css and have you dropping down to low level drawing in frustration.
Back then, I felt native Android didn’t deserve my time or patience.
Jetpack Compose, and Kotlin coroutines, mixed with kotlin multiplatform code, came and made many things nicer, especially UI. With so many libraries and so many ways of doing things with so many opinions it’s still hard to digest of course.
It’s better than non native for performance and experience but many companies will of course care more about the money saved from a sub native experience with fewer developers.
> It’s better than non native for performance and experience but many companies will of course care more about the money saved from a sub native experience with fewer developers.
I currently work at an agency doing Android apps (not a typical pump and dump agency mind you, I've been the lead on this single project for 5 years and we've had them as a client for 8+), and I'm so happy to see our client buck that.
They've had us on a native app that we've been supporting for the entire 8 years, and had deep technical issues from before us ("lets reinvent the web browser for UI"). They had a secondary internal team (known to us, no hidden surprise, you're gone stuff) working to replace us with a greenfield cross platform app (I think react native). That project went on for a year before they cut their losses and said "cross platform can't be good enough."
We're now in the planning phase of a complete greenfield rewrite of the existing app to take advantage of Compose + Kotlin, and ditch 12 years of tech debt and I'm practically ecstatic.
I'd argue the opposite. For a lot of people, getting quick results is absolutely needed for motivation. Focusing on learning "the fundamentals" before getting to the enjoyable parts is bad advice for most, as it often leads to people dropping out before they get hooked.
I agree that you probably can't be a decent mobile dev in the long term without learning basic iOS/Swift or Android/Java(/probably Kotlin nowadays) but that is not a good place to start for people who are just getting started.
>Most companies including the ones that created these cross platform frameworks, build thier core apps using native stack for a reason.
yes, because they are a company and have 2 separate teams maintaining each stack.
TBH I mostly blame Apple for my reluctance. Given the barrier of entry, I'd rather just work with a cross platform tool, launch android, and then figure out any potential IOS issues when I decide I need an IOS port and the need to pay for a license (and find/buy the Apple hardware).
The mistake OP is referring to is spending too much time learning the wrong thing which is easy to do in the Cargo Cult that is modern Software Development.
There isn't really anything to Flutter that stands out as so unique it wouldn't translate. Dart is not opinionated, sort of as if you threw every Algol family language into a blender, and the component/reactive style is just like any other modern framework.
it's arguably one of the strengths of Flutter, regardless of where you come from there's nothing esoteric to it, so it's not like you learn the wrong thing. Learning Programming isn't about memorizing APIs or libraries, it's about concepts.
If you've done Flutter for several years your experience translates just fine to say React native, you just gotta learn Javascript
Maybe I’m special (and it was 6-10 years ago), but after becoming proficient and pretty deep in osx/ios development I took an android project and it wasn’t obvious AT ALL. If it were a new job and not a project pushed to me at the same position I had, pretty sure it would be difficult to keep it.
Of course that depends on average expectations. Some people may learn and do and relax and still outperform if these are low.
Pre-Kotlin and Jetpack Android were very tedious. Even simple things like handing button click events and changing the text of a label at runtime were not obvious or simple, and you had to worry about backwards compatibility libraries to a larger extent than any other platform.
From what I understand modern Android has become much more pleasant to develop for.
It's the same in every other stack/programing language/technology when you go through the default channels of HR/recruiters.
It's not that competent engineers can't become quickly productive in a new/stack language, it's that business don't understand that and/or don't want to risk it with switchers, and so prioritize hiring only those already experienced in that stack, creating employment bottlenecks where there's simultaneously a shortage and enough people willing to switch.
Same when talking to recruiters: "oh you only have experience in X (which is similar to Y), sorry but the hiring manager said (s)he wants someone with at least 3 years experience in Y".
Your only escape is having a solid network so you can push your resume directly to hiring managers who understand technology and your adaptability, and this way bypass the hiring shit-show.
C’mon. HR doesn’t have a clue of what they’re asking for. Anyone with a little of experience in the IT industry knows that:
1. You’ll need to put whatever is needed in your CV to pass through HR
2. You can explain yourself to the actual tech people who interview you in the next stage. For example, if you know Ruby and RoR, but there’s an excellent opportunity to work in a cool product for a company that does Python and Django, well, apply! Obviously you’ll spend a couple of days with Python and Django and notice the similarities and differences with Ruby and RoR. You will add to your CV the keywords Python and Django and you’ll get pass HR (if HR asks you about your experience with such tech stack you can always say that, indeed, I have plenty of experience with MVC web frameworks and blah blah blah). When you pass to the next stage of the interview and get to talk to real engineers, then you can explain that you have many years of experience working with RoR and that learning Django will be a pleasure.
It's not difficult to switch between mobile stacks. It's just companies make you believe that it is, to promote a "one codebase efficiency" mantra. For me, to be efficient with cross-platform solutions, you need a deeper knowledge with the underlying native frameworks.
I started with Blackberry SDK plugin with Eclipse, then to Android, Windows Mobile (UWP) and iOS in that order. Majority of those projects I have worked are written in native. It's not that hard to switch since you can find familiar concepts in each frameworks and stacks.
Of course, I have been also part with cross-platforms solutions but it just cannot cope up with the yearly updates and deprecation especially if your apps are critical.
Why are people so obsessed with hyper specializing in software development? Labeling yourself a react dev or rails dev or flutter dev or whatever is only going to limit your growth and options. Your career will outlive many tech stacks. Tech changes quickly. Never stop learning.
Because once the market goes belly up, being a generalist seems to be a death sentence.
One thing I noticed having been on the job search for about a year now, is the amount of jobs looking for a specialist, whether that be in a particular domain, or technology. Often very obscure or “obsolete” stuff.
I remember applying to a government job, and in their little checklist application, one of the questions was basically “do you have experience writing software for [hyper specific domain]”. Of course, it was the only question on there I couldn’t answer “yes” to. Low and behold I was rejected for that reason. Not sure how they’re going to fare finding someone so unique at the price they’re paying.
I’m frankly ready to leave the industry, but unfortunately, there’s not really any other good options for me at this point.
We must be looking at different levels or roles or something. Most job postings I see say something like Must have experience in “x, y, z or other modern language”. Maybe extreme specialization is more common in front end ?
I’ve seen roles like that as well, but much less than I used to. I see them more on entry level roles. I’ve never worked frontend and I’ve barely been full stack for several years now. Most of my experience is in .NET stuff, and usually C# is not the “ “x, y, or z”. Usually it’s something along the lines of “Java, Go, Python”. Not that I haven’t ever worked in those languages, but certainly not recently.
IDK about specific software, but I'd love to be a domain expert one day. Key is to grow in something that is always growing. Being "the Network guy" is a lot more promising than being "The Ruby guy".
> You are not defined by your chosen software stack: I recently asked via Twitter what young engineers wanted to know about careers. Many asked how to know what programming language or stack to study. It doesn’t matter. There you go.
> Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career.
And I'm saying this as somebody who worked across a lot of tech stack levels
from writing c# backends + even c# webassembly running in browser (high level), to some dekstop, to background workers / cli tools, to having my own OSS lib, to compilers (using llvm), to uefi / firmware C development.
Sure, it is interesting to work across all those levels, you get a lot of understanding how things are connected or you're just aware of how this work, but very often this is just shallow knowledge. Strong knowledge and experience requires time. If you switch, then you ain't gonna learn.
When trying to find a job there's almost never such a overlap which requires those.
I did mostly work on python and Java. Whenever I apply for positions using golang they stop my application process after learning I don't have work experience in the language.
May be this doesn't happen in FAANGS but I see it is the usual thing around.
Many recruiters are good at their job, however there are those that want to maximize their sales and don't really understand any tech, so if the customer is looking for XYZ Developer that is what they filter on.
It isn’t clear why the discussion is around flutter.
The problem is when you define yourself by the technology you know. You’re an app developer or an engineer, not a flutter developer. Focus on showing your ability to make apps or whatever the target company does.
Obviously I feel the pain of the OP but I think he blames the wrong thing.
Flutter is a ( viable ) technology that’s being growing for the last few years. A very significant percentage of new mobile apps are programmed with it these days.
It seems his problems have everything to do with the local job market and not the technology. With the added bonus that you can be a single man operation and release your own apps for both iOS, Android and the desktops.
I’m not a fanboy and even less of Google but Flutter really offers the ability to make lemonade if the job market gives you lemons.
Flutter is pretty old if you think about it and still has too many rough edges and not a lot of big name adoption. The project is too ambitious, and the features seem more like PoCs than something you can rely on in production, IMO.
This is what has prevented me from diving into Flutter for a personal project. Although it supports desktop and web, it is first and foremost a tool for building mobile applications. For desktop, too much of the API is built around the assumption that you are on a mobile device with a single window and a finger as the pointing device. Feature requests for desktop, such as proper support for mouse-based drag and drop and multiple windows, are either ignored or take forever to develop.
Any platform that tries to support web, mobile, and desktop all at once, of which there are many, are destined to this fate of being spread too broadly and thinly.
The API assumes you are on a relatively small screen and using a finger to drag and drop. Thus, it doesn't provide functionality that you would expect if you were on a desktop or laptop monitor with more space and using a mouse and keyboard where there is a wider variety of things that you would like to happen with a drag and drop interface. The API is primarily assuming you're taking a widget and dragging it with a finger to somewhere just an inch or two away on a phone or tablet screen. Yes, drag and drop "works" on desktop as it is, but the API is not well-designed for desktop-based usage. A lot of ad-hoc type of behavior using global state has to be used.
Is that actually true though? Most major Google apps predate Flutter. I was under the impression that a lot of their apps are either custom web view wrappers or native with shared C++ code for business logic.
Stadia and Google Pay are the only consumer facing Google apps I’m aware of that are made with Flutter.
Most of their apps are native. They learned the same thing that Facebook learned years ago. Cross platform GUI apps have always sucked - or at least since Java tried to popularize them in the late 90s.
Fuchsia is an OS that is also using Flutter for their entire UI layer.
I think there’s more a case of there isn’t an argument for doing but rewrites just because Flutter is now a thing but in a greenfield scenario it would be a serious contender
I used to feel the same way but Flutter is hardly a new technology anymore yet still seems to be used very little. I've dabbled with it on hobby projects here and there and it seems "fine" but not sure I'd bet the farm on it.
You made an argument saying that even Google won’t use it for cross platform.
I have some context as to why it’s both a wrong and misleading statement.
When it came to the biggest money maker of the entire business this is what they picked. When it came to a new greenfield project for an entire OS… this is what they picked for the UI.
The statements you made about “the lessons they learned” is just some stuff you made up and isn’t actually supported by facts.
Ads is their biggest money maker. But it doesn’t have to be usable compared to their consumer facing software. Even though it’s used by ad buyers, it’s more akin to internal tools that at most large companies don’t get near the care of consumer facing tools (looking at you Amazon where the internal review process website broke last April).
I worked for a midsized health care company a few years ago (around 300 people including customer service). They had three mobile developers who supported the iOS app and the Android app.
It mistake misses the point of the investment. The pay-off is experience in new patterns, new tooling, new approaches. The dividend is in the job where you use the tool but the capital gain is in experience.
When I hire for my team, I never mention the stack. I don't care. I am hiring software engineers, and what I value is mindset and ability.
I'll throw you in at the deep end. Learn the language, libs, tooling, infra on the job and the team will support you. Because you're awesome. That's why I hired you.
That sounds crazy to me. If you throw me at a new language, sure learning the language might only take a couple of weeks (if it doesn't radically depart from what I already know), but learning the libraries/ecosystem is at least 6 months. Probably more for something yuge like Java or .NET.
I'll be referencing the doc and tinkering every little thing for many many months, which is sure to affect my productivity. Append to a file? Make an HTTP connection? Serialize a data structure? Have to look it up.
Then come all the 3rd party libraries a seasoned developer will already know. How do I talk to Postgres? Which of these five 3rd party libraries should I use? Which library do I need to help generate my SQL statements?
It's like you're looking for a journalist for an American newspaper, and you decide "oh, you don't have to speak english, you can learn that later". Sure, you can do this for an exceptional talent, but on average you're better off finding people who already speak english.
At our company, out of the 8 engineers I hired, only 2 had specific experience with our backend (Elixir) or frontend (Flutter) stack. I hired for apparence of talent, experience in some other equivalent stack and the right attitude towards learning.
All of them got productive rather quickly and had PRs shipping to prod in the same week, if not within a couple days.
I’m not saying it _will_ go as smoothly for anyone else, but if you have the right environment and pick the right people, as an employer you’re better off being flexible with experience.
Developers have a finite useful lifespan and they need to pick their portfolio of techologies wisely if their journey is not going to be an anxious random walk chasing the latest fad.
You cant only pick "winners" but you almost need to develop a sixth sense for what will be a valuable and long term addition to your finite toolbox.
Looking at tech attributes is just the start. business and community context, complementarity with other pieces etc are all the subtle factors that may help avoid wasting energy in short lived pursuits.
I don't think it's subtle at all. Pick existing popular technologies / frameworks. If you like to gamble a bit, pick those that you see growing quickly. Invest time in learning new stuff (ideally, on an employer's dime) throughout your career.
If you don't care about being on the 'bleeding edge', you really don't have to think about it too hard and you'll have plenty of job opportunities.
Hmm, lets put that approach to the test? Is flutter 'popular'? There are other popular alternatives for mobile apps. Is one or two years being "the most loved" on surveys sufficient to decide its "growing quickly"?
As the comments on the post say - it's most likely due to the generally slow job market. 3.5 years later I'm still glad that I chose to use Flutter in my business.
I recently started building my first Flutter app and overall I've found it to be surprisingly pleasant. I've had no trouble finding good packages for features I need and even though I'm learning the language and APIs as I go I've made rapid progress.
I've done many apps in Electron, React Native & native iOS and at least on a technological level I prefer the devx of Flutter.
C, Java, PHP, SQL, Python, Ruby have kept a lot of people going for more than 20 years, and will likely continue to be relevant in some capacity for at least another decade (if only maintenance, not even including new projects started with those tech stacks). I've been working with PHP and some variation of SQL for the past 28 years, and it will go on for a while longer. I've also worked in the Java world, and have done a smattering of other tech along the way as well.
Not everything lasts 40 years, but many things last more than 3-5.
But Java 2023 is quite different from Java1.
The tools you use now are different (unless vi)
You have had to learn a lot of new technologies,
frameworks, syntax to keep up.
PHP has also gone through so many changes that it is
near a different beast these days than when it first
appeared.
So if you had relied on your skills you learn as
PHP 1.0 and Java 1.0 today you would not be very productive.
Much/most of Java 1 will still compile, at least (FWIR). The evolutionary progress of java 1... to whatever it is now (current one I'm using is 17, but I know there's more past that) has largely been adding of new libraries/methods, etc, and the majority of your java skills from 10-15 years ago are still valid (although might not be the most efficient any more).
I've watched people go through Flash/Silverlight/Actionscript, multiple MS tech stacks, and many many other promising tech. Many have had to large scale reinventions of themselves and cram 'new to them' tech as the old stuff has gone away.
It's definitely easier to evolve with a tech stack over the years. You get a better sense of idioms, best practices, etc. that is hard to replicate overnight.
And yeah, some tooling is different over the years too, but yeah, vi still works :)
Shiny new 'hey look at this' ideas can pop up in newish langs, but diving deep in to them isn't often the best path for most people. The truly good and impactful ideas tend to get recognized and adopted in the more mainstream ecosystems over time, giving you most of the benefits without needing to throw out much of your experience.
> Much/most of Java 1 will still compile, at least (FWIR). ...
Actually it won't, past Java 9, as after the modules introduction it was also decided to take action on deprecation, now things get really removed after a couple of releases.
Interesting... I have a project that was originally done in J8, and... it's still working/compiling as of a couple weeks ago, but it's not necessarily as advanced as it could have been. I think we moved to J11 a few years ago, and IIRC J17 in 2022, and didn't hit any issues other than some dependency versions.
I started doing Java (and sql/Oracle) development in late 1990s and even today I am deploying REST APIs written in Java, MySQL to AWS. So, yeah, it has been about 23+ years so far!
I spent quite some cycles into flutter|dart, ended up with React Native for mobile and wxWidgets for cross platform desktop GUI(electron.js is too fat for me and wxWidgets 3.2 looks decent).
RN(javascript) and wxWidgets(c++) are both job friendly, unlike Dart, which is a language I actually enjoy, but there are not a lot jobs for it anywhere.
I don't want to get into the complexity of Qt licenses ever, and wxWidgets does everything I need so far, plus it's 100% open source and free to use. the new release 3.2 is pretty good and it's also smaller than Qt ecosystem, which means much easier for me to learn and start to make releases.
I only invest in company-sponsored tech after the market share grows to a ver significant number. A lot of what is sold as "the future of X" is just marketing. Flutter and Dart in particular failed to thrive, as many of these technologies do, and are evolutionary dead ends (despite the remaining die-hard users).
Of course they did. Dash/dart was obviously dead about three months into it’s existence. Google cancelled their plans to replace JavaScript after nobody expressed interest and Dash/dart will never be more than a curiosity.
Yeah, I don’t understand why anyone jumps on Flutter.
There’s barely any Flutters devs out there, definitely few with Dart experience. You’re dooming your project to die based on churn, so definitely a bad business decision.
There’s thousands of Reacts devs out there that picking RN will guarantee that you have your “one codebase” and will be able to support it long term.
What’s the benefits of Flutter? A nicer dev experience? No customer cares about that.
And you obviously don’t care about the best possible user experience or you would’ve gone native.
And that’s even before the whole “one day Google will wake up and kill it off on a whim”.
It's a a good enough language (Dart is kind of odd, but when comparing to Javascript it's tolerable), and the API itself IME (as someone who's done hobbyist web development) had the least amount of "CSS jank". I put a button in the middle and by god, it seemed to know what "center" meant for once.
But the real magic comes from the tooling. I've also done some Android development, but Flutter's iteration times were incredibly fast. This combined with the lack of aforementioned CSS Jank made it feel like I could actually be productive without getting bogged down in all sorts of weird layout edge cases.
Also, Google support in theory means that there's (relatively) little risk of abandonment.
>What’s the benefits of Flutter? A nicer dev experience? No customer cares about that.
You're asking a dev why they like flutter, not a businessman. Why should I take into account customer care when determining my tooling? As we both agree, they don't care anyway. If I made a usable website in Microsoft Word, then mission accomplished as far as the customer knows.
Dev marketability is important as a professional, but TBH you couldn't pay me to be a web dev to begin with. So that's not a factor in my answer. The only reason I'm using React right now for some current hobby projects is due to the lack of maturity for Flutter Web (at least, 2 years ago. But nothing in the current docs make me think it's better today".
>you obviously don’t care about the best possible user experience or you would’ve gone native.
native doesn't guarantee the best UX. Even RN's maintainers break their own established rules on their websites. don't take my context menus and navigation away from me without a very sensible, intuitive reason (e.g. Google Sheets)
> Also, Google support in theory means that there's (relatively) little risk of abandonment.
I don't know, Google's known for abandoning things left and right. They bought Fastlane and proceeded to abandon it.
> You're asking a dev why they like flutter, not a businessman.
It's more of a comment on the original post where OP is looking for a job as a Flutter dev - why would anyone choose Flutter to base their product on, if they can't find devs and all the other reasons I mentioned.
As a dev - I really like Flutter - no doubt there, but it just doesn't make a lot of business sense due to a chicken and egg problem and likely won't for a while.
> native doesn't guarantee the best UX. Even RN's maintainers break their own established rules on their websites.
I meant native as in Swift and Kotlin - even splitting it in those two avenues makes you think more about the respective platforms and their expected quirks. I've yet to see a RN and Flutter app with a live activity, for example.
All the sports apps out there that are crossplatform don't have a widget, etc
The market is so weird right now, that I find it hard accepting this. A lot of jobs that would have been otherwise open are paused.
Having said that, I have just recently got into Flutter/Dart and I found the experience quite enjoyable and the resulting app very polished. From the tooling to the language itself and the Flutter framework - it's a joy.
Maybe I'm thick, but becoming competent in a new framework takes me a lot longer than a few days. For example, angular, ploughing through courses on plural sight slowly to properly absorb the lessons. Even after that I'm flailing about trying to do anything useful.
> prefers to test applications on a Linux machine running an X server
Apple won't allow you to do that. Any binary submitted to their app store must be built using Xcode running on MacOS on genuine Mac hardware. It's a tax they collect from their developer community; if you don't want to pay, you won't get to play in their walled garden.
React Native may be a good bet, while testing with an Android emulator. However, you won’t be able to build an app-store-approved iOS app without Xcode tools, which are not officially available on Linux. The CLI tools for building mobile apps are definitely not up to par with the IDEs though.
Are you aiming at that? Flutter should work well for that scenario. I'd use an IDE to simplify testing in an emulator, but you could manage that manually from the terminal.
Ok, then I guess I'll wait for the day when WASM runs on these mobile platforms so I can bring my dev environment to them instead of the other way around.
(not op) This is not hamstringing. It’s a matter of preference. I prefer jeans to a tie and a costume. I prefer Emacs and Vim to Vscode. I choose jobs that allow me to wear jeans and code in Emacs.
I have worked as an Android developer for about two years, then had to do project in Flutter. Learnt it over a weekend and getting the UI right took me less time then if I were to do it in native Android (before compose).
The problem is OP going by the role Flutter dev and not just Mobile app developer, why limit yourself by a single tech? Your experience cuts through multiple fields!
They're even keeping GWT alive somehow. That was a major mistake, though. I remember building a large GWT project and the compile times just started getting into multiple minutes. Debugging was hard.
They are not. It's a third party fork that's keeping it alive. It's dead because Google didn't put any resources into it and just threw it out to see if it sticks. Then didn't keep up with the capabilities of JavaScript frameworks and didn't release any proper templates.
It never used GWT. They claimed GWT can be used to build apps like gmail and that was misleading. They didn't write it using GWT since it predated the existence of GWT.
I’m not sure why sarcasm is needed. Go lost to Rust as the mainstream safe systems language, k8s is a meme for wasted engineering resources, obviously Dart/Dash failed in its intention to replace JavaScript (I don’t know what ‘Chrome APIs’ are).
Despite ostensibly being a “systems language”. I see Go used more often for writing CRUD apps or APIs. There’s a lot more work in that then working in rust, thought I’ve admittedly been surprised with the amount of rust jobs I’ve seen.
Android is also terrible. As an Android developer it's the absolute worst when compared to iOS development. Google is an Ad company, everything else it does is a hobby.
I have worked for years with PHP, Apache, Ansible and MySQL. Nowadays not anymore. And in 7 years I’ll be using something else. Learn the fundamentals (which is not a one-time job, btw) and you’ll be fine. If someone asks for technology X in their job offers when you know Y, but you know you won’t have difficulty in learning X, just take a few days in learning X and then put it in your CV. You’ll get pass HR screening and then you’ll have a chance to explain in tech interview that your are more of a technology-agnostic dev. You’ll do fine.