Loved the store, and the mailer as a kid. Really inspired me to build things. Really wish more stores like it still existed. Anytime I'm back in MKE, it's one of my first stops.
I think that's the point AI agents are trying to sell. Spend more time on the type of coding tasks you want to do, like coding cool new code, and not the tasks that you don't want to do.
Is this really a common problem? What are these tasks that can't be deterministically automated and also not avoided entirely, and also don't fit nicely into where you need to think about some other task for a while before you go implement a solution to it?
I think they are suggesting that you can focus on the code that you want to write - whatever that is. Especially since the first line is, "Jules does coding tasks you don't want to do." I took the first image as being someone working on the computer. Or, take back your time doing whatever you want - e.g. cycling, table tennis, etc.
All of the work that currently gets pushed back with 'no capacity maybe in Q+2' will become viable and any brief moment of spare capacity will immediately be filled.
A new backlog will start to fill up and the cycle repeats.
Maybe, though, the backlog of the future will actually be less important than the backlog of today? Bug fixes will go out, software quality will increase?
> Or, take back your time doing whatever you want - e.g. cycling, table tennis, etc.
That might be true for hobbyists or side projects, but employees definitely won't get to work less (or earn more). All the financial value of increased productiveness goes to the companies. That's the nature of capitalism.
I don't think it's meant to be literal, more tongue-in-cheek. Obviously, developers aren't going to be playing table tennis while they wait for their task to finish. Since it's async, you can do other things. For most developers, that's just going to mean another task.
Probably because they are just a hobbyist and not an expert in the field (nor do they assert that they are). Maybe be a little kinder on the internet. It sounds like it was just a minor oversight.
I really did think about whether or not to write that last paragraph. But the thing is, it's the truth. And I think it's going to be more helpful in the long run for authors to know these things.
Believe me, I've been on the receiving end many times and it's made me a vastly better writer and communicator. When somebody stops reading your article because of a howler, it's much better for you to hear why so you can learn from it.
(And you don't need to be an expert in the field to realize that discs that flip are mechanical, or that they don't have a "near limitless lifespan". These aren't exactly subtle mistakes, and it's one of the main justifications presented in the introduction itself.)
You're seriously insinuating that a person has to be an expert in the field to be able to identify that a device with moving parts has... moving parts in it?
> But why is it Apple's responsibility to accept a non-legit/unknown serial #?
I don’t think anyone is arguing that it’s Apple’s responsibility to accept fake serial numbers.
The serial number is an implementation detail and not the core issue, which is Apple’s intentional degradation of the non-iMessage experience, and their stance against interoperability.
If this was all about security, they could accept something other than an Apple serial #, and provide a UX that makes it clear the user is interacting with a non-Apple user. This would address most spam/abuse issues.
But we know that this is about lock-in and not security.
> I don’t think anyone is arguing that it’s Apple’s responsibility to accept fake serial numbers.
Can we confirm if that's what is happening here or not? How else is Beeper Mini able to work given Apple's requirement "iMessage auth + read/write requires valid_serial_number"?
The “How Beeper Mini Works” post from a few days ago doesn’t mention the serial number, so I don’t know.
But whether this is happening or not is immaterial to the broader philosophical issues being raised.
For sake of argument, let’s say they’re faking a serial number to make the app work. How does that change the impact of Apple’s anti-interoperability stance?
Again, if the real issue is security, nothing stops Apple from providing a secure alternative. And again, this takes us back to: this isn’t about security.
It’s not, and they don’t. This is a cat and mouse game. Apple is free to block these and people are free to keep trying to get around it. Everyone should be acting in good faith
They (Apple) don't accept requests without a valid serial #, but Beeper Mini is working (for users without iDevices), so there's some kind of exploit, no?
