Hacker News new | past | comments | ask | show | jobs | submit | atom_arranger's comments login

https://www.rockstargames.com/careers/openings/position/5761...

"Scrum", "Agile", "Lean".

The devs were may have been too busy "sprinting" and getting their assigned tickets done to think about higher level concerns like "is this good? can we make things faster or better?".

I think your points also stand though.


They calculate tips after fees and before discounts, so customers are tricked into tipping more. First noticed this after getting a buy one get one free deal and seeing a tip calculated at 2X what I'd expect


After fees is a bit tacky, but, at least in the US, I think it is considered good etiquette to tip on the original amount before discounts. I remember this came up a lot when Groupon was big offering a lot of BOGO deals.


I’ve never thought much about it, always consider it’s just a percentage. I am in Canada but it’s pretty much the same. Googling “tipping buy one get one” turns up this snippet from a Quora answer:

> The amount of effort the server devotes to your ordre is the same regardless of what the owner charges for your meal. So tip on the original, undiscounted price. And tip at least 20 percent.

Kind of funny, when it results in a higher tip I should consider the amount of effort.

I expect if I said I was only tipping $2 on a $100 bottle of wine at a restaurant because it isn’t any extra effort to grab an expensive bottle the poster might not agree.


100% of those tips go to the driver, and not in some sort of scammy door dash way that means uber pays the driver less. so it's important to note that "tricking" people into tipping more doesn't help uber's bottom line.


> it's important to note that "tricking" people into tipping more doesn't help uber's bottom line.

Of course it does. Their drivers presumably want a certain level of total compensation, but they dont care who it comes from. The higher Uber is able to convince people to tip, the less they have to offer in wages to retain drivers.


uber's bottom line ... as in what gets reported in the quarterly numbers. the tips absolutely do not go towards uber's income.

> The higher Uber is able to convince people to tip, the less they have to offer in wages to retain drivers.

this is unfounded speculation.

your complaint reads like you want to fault uber for not scamming the drivers. as someone else pointed out, after years of saying that uber would never be profitable it makes sense that there's some moving the goalposts here.


Yup, they will shower you with 'promo' offers like '2 for 1' (where the price is typically just doubled for a single item anyway), then try to charge you like a 36% tip. They also straight up steal many of the tips from their delivery people as evidenced my many such threads/concerns online.

https://www.reddit.com/r/uberdrivers/comments/xyk7cx/uber_st...

In general, never tip on ubereats.


What should Prettier should do in this case?

I think we can all agree there should be a line length limit, it has to enforce it eventually. You could say “it’s just a couple more characters” until the line is 200 characters long.

Semantic diff is maybe the solution.


It should put more weight on the length that the author has original authored it as. So between "always break" and "always expand" there should be an area of "leave it however it already is".


Prettier needs to be consistent regardless of the original input. Otherwise it won’t really work well.


I don't think it does. Plenty of code formatters are not completely, and work just fine.


It can safely ignore the line length, gofmt does this and I've never heard anyone complain about it. The VSCode formatter also doesn't touch line breaks and it works fine.

Last time I looked into it, the only reason I can't turn it off is that Prettier works off an AST that doesn't keep the line breaks that the user put into the code at all, and it "rebuilds" the whole code from this AST.

The problem is not the diff per se, the real problem is that I can't find a configuration of Prettier where I can have long lines where it makes sense and short ones where that makes sense.


I was with you until you said “make me Facebook for dogs”. I think a sufficiently pattern recognizing AI could probably make a somewhat useful/accurate application from that prompt, because most social media apps follow a set of patterns. Users (dogs) have certain attributes that go on their profile, they can share things with their friends, notifications should work. Where it gets tricky is the details, but maybe AI could get you a rough version at least by knowing social media app conventions. This is also how a motivated programmer would go about it, instead of asking the “idea person” a million questions they would just assume things.

I say this as someone who has looked at AI generated code and was not impressed though, so this is probably still a long way off.


The real issue with prompting a la "Facebook for dogs" is how ridiculously underspecified such a prompt is. You see the problem with this very clearly in text to image models: you might have a specific idea of your dog in your head, but no matter how often you prompt "cute white Maltese dog with a tuft of fur across its eyes", you will never get something that would pass as your dog. (A more obvious challenge would be to try to generate an image of yourself if you are not a celebrity). The amount of words needed to replicate every detail exactly would amount to at least a short essay. You give an AI the prompt "Facebook for dogs" and it could take that in SO many different directions.

Another problem that I'm personally more concerned about is that this way of coding will allow for so many security flaws to be built into the code. Even if it builds something that matches your expectations for the prompt, what's stopping it from generating something vulnerable to attacks that leak all your users' data? Humans already struggle enough with this, and we're feeding all our flawed codebases into these models.


I usually tend to do the refactoring without asking permission. Just spend 20% of my time on it, get it done, definitely pays off. I tend to be pretty productive generally and with this refactoring I'm not doing something like saying "give me a week to refactor from X to Y", instead I just do a little bit every day or two, so I've never had much problem with this from management.

If you're delivering features quickly it shouldn't matter if you spend some of your time making sure you'll be able to continue doing so in the future.


Exactly this. I also don’t ask permission because I consider this type of refactoring an implicit and fundamental responsibility.


IMO TypeScript nudges you away from bad patterns. If it’s a mess to type it, it’s probably a mess in general.

If you are in a very rare situation and think you know better then there’s “any”, although at that point you really need to think “I’m risking runtime errors and this code is confusing, is it worth it or is there another way?”


I tend to jump to the opposite conclusion. If a name is cute I assume it’s something open source, named for marketing or SEO. If a name is descriptive I assume it’s probably internal.


Could not disagree more.


Potentially can’t notify either if you don’t have a UA string


You can notify all users until a major browser vendor fixes a known bug without a user agent.


  - Keep your code reasonably clean
  - Use strong typing
  - Make sure your tests don't test implementation details if possible
    - e.g. using more integration like tests written with react-testing-library
    - e.g. using visual regression tests
  - If you sense something is off about the tech stack make a POC of partially migrating to something else as soon as possible
  - If the thing you tried is better come up with a plan to migrate and do it as soon as possible
  - If you've followed all the bullet points above then switching to a better solution shouldn't be that difficult
That's how I try to deal with it. Also if you're not sure which thing is better do POCs with both solutions. Alternatively if you're working on a greenfield project and a week in things don't feel right don't be afraid to try rewriting it with one of the alternatives you were considering, it'll be a slight hit to productivity for a day or two but it'll pay off long term.

By following these guidelines I've never felt on a project that I've painted myself into a corner with the tech stack, or chosen something very bad that is not reversible.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: