I feel like I made a mistake investing professionally into Flutter

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.

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.

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

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.

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.

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.

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.

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.

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.

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)

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…

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.

The HN bubble strikes again.

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

Its Flutter:

``` class MyHomePage extends StatelessWidget { @override Widget build(BuildContext context) { var appState = context.watch<MyAppState>(); var pair = appState.current;

    return Scaffold(
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            BigCard(pair: pair),
            SizedBox(height: 10),
            ElevatedButton(
              onPressed: () => appState.getNext(),
              child: Text('Next'),
            ),
          ],
        ),
      ),
    );
  }

versus SwiftUI:

``` struct MyHomePage: View { @StateObject private var appState = MyAppState()

    var body: some View {
        VStack {
            BigCard(pair: appState.current)
                .padding(.bottom, 10)
            
            Button("Next") {
                appState.getNext()
            }
            .padding()
            .background(Color.blue)
            .foregroundColor(.white)
            .cornerRadius(8)
        }
        .frame(maxWidth: .infinity, maxHeight: .infinity)
        .padding()
    }

versus React Native:

``` const MyHomePage = () => { const [pair, setPair] = useState(/* initial pair /);

  const getNext = () => {
    // Logic to get the next pair
    // You'll need to implement this function
  };

  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      {/* Replace BigCard with appropriate React Native components */}
      <BigCard pair={pair} />
      <View style={{ marginVertical: 10 }}>
        <Button title="Next" onPress={getNext} />
      </View>
    </View>
  );

Is this supposed to be a bad thing? :(

Code generation (and modification) tools are there to help you. You can choose to walk everywhere but once the car becomes ubiquitous, why walk?

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.

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

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.

Maybe not, but interviewing often is.

What else is the candidate lying about?

[1]: https://familylink.google.com

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