Yeah, they don’t care that senior talent left because that was the whole point.

Looks like my Lemmy-client of choice did some retrying when I had poor connection, sorry about that.

I think trying to go cheap on native apps was always kind of a fool’s errand, tbh. Cordova, Xamarin, React Native and so on - all pretty sub-par solutions leading to poor experience without actually materializing the desired savings.

Looks like my Lemmy-client of choice did some retrying when I had poor connection, sorry about that.

I think trying to go cheap on native apps was always kind of a fool’s errand, tbh. Cordova, Xamarin, React Native and so on - all pretty sub-par solutions leading to poor experience without actually materializing the desired savings.

Looks like my Lemmy-client of choice did some retrying when I had poor connection, sorry about that.

I think trying to go cheap on native apps was always kind of a fool’s errand, tbh. Cordova, Xamarin, React Native and so on - all pretty sub-par solutions leading to poor experience without actually materializing the desired savings.

Looks like my Lemmy-client of choice did some retrying when I had poor connection, sorry about that.

I think trying to go cheap on native apps was always kind of a fool’s errand, tbh. Cordova, Xamarin, React Native and so on - all pretty sub-par solutions leading to poor experience without actually materializing the desired savings.

If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.

If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.

If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.

If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.

If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.

If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.

• General purpose LLMs are starting to replace everyday queries I used to posit to Google. Perplexity can be quite good for this.
• Copilot as enhanced autocomplete when writing code. A particularly good use-case is writing tests: with a few test cases already written, a sufficiently good test name will most often generate a well-written test case.
• LLMs for lazy generation of SQL queries can sometimes be quite nice.
• Writing assistance for things I find myself struggling to get written by myself. A writing unblocking tool, if you will.

It’s reducing the effort and time I have to put into some things, and I appreciate that. It’s far from perfect, but it doesn’t have to be perfect to be useful.

Are we looking at Manna becoming a reality? https://marshallbrain.com/manna1

It’s mostly stopping the world to re-write everything from scratch that is a mistake.

Good practice is to refactor the codebase until it’s modular (if it’s not already sufficiently modular), and then proceed to replace modules gradually until you reach your desired state of re-writtenness.

This has the benefits of actually getting you up to speed with maintenance over time without having to halt new feature development, giving you the best of both worlds.

I don’t mean to be rude either, but you shouldn’t assume that someone doesn’t know what they are talking about or understand.

From professional experience I can speak pretty confidently on the subject that staffing opex is almost universally going to supersede cloud opex.

EDIT: I noticed that I was being a bit unclear when saying fixed. What I mean by fixed in this context is that you need to develop the whole e-commerce infrastructure regardless of if you have 1 game or 1000 games - a simplification as you do need to take care to scale well when growing, but it is good enough for the purposes of demonstration. The more games sharing the same e-commerce infrastructure, the less the e-commerce infrastructure costs on a per-transaction basis.

You need to employ relatively fewer people to maintain and remain on-call for a service as you grow it - this is part of the point I’m trying to make. Having fewer games is a disadvantage for Epic, not an advantage.

But hosting is basically a rounding error in the equation of selling games on an online store. The actually significant cost is going to be in developing and maintaining the software powering the online store, and that cost is fixed. This in turn means that having less games in the store is an obvious disadvantage, not an advantage.

I’m not sure what you mean by ‘despite’ here.

Few feelings are more freeing than closing basically all of them down. Usually I don’t even miss them, essentially all upside.

You upload the binary to the App Store, and as a part of the release process they may inspect the binary to figure out what it’s doing.

They of course don’t do that for everything as it’s a bit complicated to do for everything, but it can be an effective means to for example figure out when an app is calling an API in a prohibited manner.