7 ms·

your comment is gold to it I'd add that this is also the difference between the $20/hour programmer and the $200/hour programmer -- speaking in broad strokes,

your comment is gold to it I'd add that this is also the difference between the $20/hour programmer and the $200/hour programmer -- speaking in broad strokes, knowingly, and if you'll indulge me charitably. Because the difference between the commodity "let's ship something!" programmer/engineer and the one who truly knows his/her stuff, and who truly thinks about and knows about and cares about the edge cases, the big picture, the total system, all possible states in the state machine space, is what justifies those differences in (ostensible) upfront cost. If you only want "the user is in location X and so icon Y should be rendered on their screen at point P" then you can get that pretty cheap, at globalization-plus-crowdsourced-plus-cloud-reduced prices But if you want that above but also, with good performance, correctness, stability, scale, all edge cases handled reasonably and gracefully, and in v1.0, and well documented, and with good English, and maturity, curtesy, legality, i18n, etc... well, then you're going to pay. Or you should expect to pay. There's no such thing as a free lunch. Ever. If you think you have a free lunch, or a reduced cost lunch, then all it means is that somebody else off-stage is paying for that difference. And that difference may come back to bite you.

2bitencryption 10y ago
> to it I'd add that this is also the difference between the $20/hour programmer and the $200/hour programmer You could have a hundred "$200/hour programmers" on the team for this app, but if management says they need to ship three weeks early to catch the buzz, or something like that, it doesn't matter. We can't say the developers were bad. I mean it's possible, given how poorly the game handles network disconnections, among other bugs. But unfortunately we don't live in a utopia where the guys writing the code get to decide when they want to release. Or if features get added in the last minute. Etc.
- syngrog66 10y ago
  so many HN replies say 'you're wrong and you implied <what-you-didn't> therefore should feel bad'. yet this did not. well said, agreed. you added signal. in many situations, an owner/manager/lead is making decisions where, frankly, the company has no revenue so they know their ostensible default spending path is equivalent to a ticking time bomb. or... they don't truly know whether or how well the engineer can deliver, yet they do know for sure definitively what their dollar spend will be. thus, the results we see.
- buzzybee 10y ago
  We totally do get to say that in this case. This game inherits issues that have been present in Ingress for years. Years! Ingress gets away with it most of the time because it's not operating in a worst-case scenario where the backend has to suddenly scale from limited beta to millions of active users, so fewer of these bugs present. The actual architecture work underneath is poor; client code should not crash, softlock, or lose frames because of a temporary connectivity issue. But TBH, that is probably not about how much the engineering team is paid, it's about what culture they have. Nintendo's console development teams would never ship something with this many catastophic bugs. Niantic has probably decided that the way they're doing things is "industry standard" (within the context of mobile and their particular silo) and does not need substantial improvement. Edit: How poor is this code, you ask? It does not let me rename my Pokemon. A race condition occurs where it tries to pop up the Android keyboard and close it at the same time.

2bitencryption 10y ago

> to it I'd add that this is also the difference between the $20/hour programmer and the $200/hour programmer You could have a hundred "$200/hour programmers" on the team for this app, but if management says they need to ship three weeks early to catch the buzz, or something like that, it doesn't matter. We can't say the developers were bad. I mean it's possible, given how poorly the game handles network disconnections, among other bugs. But unfortunately we don't live in a utopia where the guys writing the code get to decide when they want to release. Or if features get added in the last minute. Etc.

syngrog66 10y ago
so many HN replies say 'you're wrong and you implied <what-you-didn't> therefore should feel bad'. yet this did not. well said, agreed. you added signal. in many situations, an owner/manager/lead is making decisions where, frankly, the company has no revenue so they know their ostensible default spending path is equivalent to a ticking time bomb. or... they don't truly know whether or how well the engineer can deliver, yet they do know for sure definitively what their dollar spend will be. thus, the results we see.
buzzybee 10y ago
We totally do get to say that in this case. This game inherits issues that have been present in Ingress for years. Years! Ingress gets away with it most of the time because it's not operating in a worst-case scenario where the backend has to suddenly scale from limited beta to millions of active users, so fewer of these bugs present. The actual architecture work underneath is poor; client code should not crash, softlock, or lose frames because of a temporary connectivity issue. But TBH, that is probably not about how much the engineering team is paid, it's about what culture they have. Nintendo's console development teams would never ship something with this many catastophic bugs. Niantic has probably decided that the way they're doing things is "industry standard" (within the context of mobile and their particular silo) and does not need substantial improvement. Edit: How poor is this code, you ask? It does not let me rename my Pokemon. A race condition occurs where it tries to pop up the Android keyboard and close it at the same time.