dickersnoodle

Per https://www.phonearena.com/news/iPhone-vs-Android-How-often-..., a relative handful of users switch between Android and iOS. That does not seem to qualify as "all the time".

> Most of the crap told on Apple nowadays are complete memes from the second wave of Apple cultist (most of them arriving with the iPhone) that completely ignore the true history of Apple and how it got to launch such successful products.

Apple Watch, Apple TV and HomePod would like a word.

There is. It's called iOS.

The BoD is likely in cahoots with the McDonnel-Douglas suits. It would take a shareholder revolt to can them all and put engineers back in charge.

The company has been run by spreadsheet mechanics and now the bill is coming due.

And when they start seeing that extra expense they'll go whining to the EU regulators again.

I've had similar experiences over the years. The Indian devs who were worth their salt were salaried employees; the ones that took all the ELI5 hand-holding were the contractors who seemed to have just graduated from a 60-day programming bootcamp and wouldn't tell you they had a problem and needed help if their lives depended on it.

I have always attributed this to the management of the consulting companies that supply the contractors - they're all about the billable hours, and quality control isn't really their problem so they don't focus on it.

>But that is also why the "best of the field" get laid off - why pay FAANG salaries to get the best, when entry/mid-level salaries to get "good enough" still meets business needs?

Maybe a better chant for town hall meetings would be "We're number 2! We're number 2!"...

Oh, I'm aware. On the way to getting a bachelor's in Chemistry I was drilled on the importance of sigfigs as a way of preventing data contamination by artificial precision (e.g. trying to weigh 16.0000000000 lbs with a bathroom scale). It just seemed funnier this way...

You could, but you'd be wrong. I've worked with outsourced devs from India, Ukraine, Russia and the 'stans and hands down the worst experiences have been with ones from India. The individual devs, when I could drill down, were bright and capable and with enough experience under their belts would be the equal of devs anywhere; the companies, however, very much had a "turn 'em and burn 'em" approach that meant any domain knowledge went out the door. I'm convinced it's a cultural/management thing. They seemed to be trained and actively managed to wait for explicit instructions for what to do instead of taking initiative and communicating it. (DISCLAIMER: This is just my own experience. Others' mileage may vary.)

puts on grumpy old man hat Yeah, back in my day you had to learn about significant digits because we still used slide rules and the calculators didn't have as many functions and we liked it! removes grumpy old man hat

It's more than that. In an org with an architecture of silo'd teams that all work on their own independent federated services, you'll need people to test out all of the variations on content, timing and error handling for the software as a whole. Depending on automated testing to handle all of that, in a live environment, is a fool's errand no matter how much it makes the development cycle seem to go faster.

It's worse if your team uses a house-built framework that's too complex for its own good. There's a whole team devoted to the care and feeding of a framework that could be replaced with source code templates or just a clear architecture document with a "cookbook" style set of accompanying documents. God forbid you try to use something else; you'll get inundated with "But that's the company standard!" style job protection complaints.

My inner middle-schooler is giggling over the headline.

>It’s like saying you don’t need a qa team because the developers tested it.

Strangely enough, that's happening at a few companies (run by Amazon refugees IIRC) where they think that making devs do QA and removing QA/QE roles will speed delivery. I'm in one of those companies now, and I'm waiting for the #FAFO loop to happen.

IMO this isn't the correct take. Starbucks' stores are their own property and as long as they follow applicable laws regarding public accommodations, health and safety and the like they're free to run their stores however they want to. Where I live, we've got a plethora of Starbucks but we've also got Peet's and a whole bunch of small coffee roasters/shops that seem to be doing just fine. To me, Apple's App Store is the same way - it's Apple's property, run by Apple and branded by Apple. Everyone who develops for it knows the rules and (for the most part) follows them, because Apple makes sure you read the rules in multiple different places.

>So the legal argument would be that, because Apple allows for a single messaging app, and interacting with that app requires an iphone, they're effectively preventing messaging app competition.

That is weapons-grade horseshit. You can put WhatsApp, Facebook Messenger and Signal on your iPhone and message to your heart's content. (I know, because I've had the first two on my phone before and they did not get killed in their sleep by Apple's native messaging app).

"Human capital stock". Every time someone says "human capital" some HR drone loses what's left of their soul.

>> Tests can only tell developers they made a mistake. There is no gain at that moment.

This is the dumbest thing I have seen on HN in a long, long time. Full test coverage supported by good mocks is one of the quickest and most efficient ways to find regressions that I know. Don't discount the value in helping developers see when they've made mistakes, especially when you're rotating junior and mid-level developers on and off your team.

Word. I work for a reasonably large online retailer that fancies itself a "tech company" and you'd be amazed at the pushback I kept getting for insisting on a proper test infrastructure for their mobile apps - dependency injection for mock API endpoints with captured data, fuzzing to capture UI weaknesses and the like. But no, they need to go fast because... well, because their product/market fit isn't that stable and they're using "data driven" decision making to justify chasing one rabbit after another to try and juice the stock price.

For a ton of people and roles there's nothing really magical about being in an office. If you're any good at remote communications you can connect with people over Zoom, Slack or (ugh) Teams and form professional connections. Personal connections are a different animal.

Try the "Swift Playgrounds" app for a programming-friendly environment.

You'd have to get past the lobbyists for the residential REITs and private equity lenders who don't want anyone to help with the housing crises because it'll cut into their profits.

>Relationships, communication, and culture pretty much set themselves up in office. While remote you have to work extra hard for it and it just doesn't seem to be happening for most people.

While I understand the motivation for this take I do not agree with it. You have to be intentional about supporting remote teams from the get go, which means you have to select for the skills that let those teams thrive when you're staffing them and especially their management chain. Expectations have to be clear, time needs to be protected from calendar pirates, outcomes need to be measured and accounted for, team members need to be able to talk to each other and management needs to keep reasonably close (but not oppressively so) tabs on team ops. It can absolutely work but it doesn't happen by accident.

You can do the same thing the other way around - https://github.com/apple/swift/blob/main/docs/Android.md.

Spoiler alert: We (iOS developers) don't.

Sort of but not really. SwiftUI is reactive, with view changes triggered by changes in Swift variables and those changes triggered using Combine. The later iterations of Swift include async/await to greatly simplify async code (normally but not always focused on network endpoints). You can write everything you need without having to drag Kotlin into the mix, and including Kotlin will require bridge code that seems (to me, at least) an unwanted obligation just to let some executive say "We saved some money by sharing code!".

u/spez from Reddit would like a word...

iOS dev here. What you're missing is that a ton of native-code developers (me included) aren't interested in adopting an abstraction layer that has to be tweaked to approximate the look and feel of the native OS UI layer when we could just built it natively to begin with and save all that effort. We've seen PhoneGap/Cordova, we've seen React Native and we'll keep seeing money thrown away on pretending that there aren't real platform differences when there are.

This reads like a ChatGPT version of one of those "Remote Work Is Harmful!" pieces in Business Insider that clutter up LinkedIn and Reddit.