271–280 of 308 posts
Are mobile stacks so specialised that it's difficult to switch between them? Out of curiosity, how long would it take a flutter dev to become productive in some other stack?
Earlier quoted context omitted.
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 A…
Here have a go at it, https://support.google.com/googleplay/android-developer/answ...
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.
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”.
Earlier quoted context omitted.
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…
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.
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.
Earlier quoted context omitted.
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".
> You're just arguing semantics 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).
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
The team has a culture where the leads know less than they do and they are okay that?
There is a persistent attitude that developers are interchangeable, that the tech matters less than the knowledge of how to apply tech to solve problems. I think that for architecting systems that's probably true, but as technology becomes more specialized and ecosystems become more complex it's harder for individuals to pick up and run with. Consider if someone has written lots of PHP and jQuery Now tell them to wri…
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.
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 e…
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)
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…
My really-learned language is C#
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.
I feel C#, but I only can use C.
Earlier quoted context omitted.
The team has a culture where the leads know less than they do and they are okay that?
You're generalising to win an argument. The lead may know less than them about some things. That's OK for us. But what's important is they know more than the team about other things. For example, we would rather have a lead that knows when to say "How do you know this is performant? Show me." and understands statistics and how to read perf dumps ... than how to profile whatever PHP script or whatever hands-on. Sorry…
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.