1. The bug tracker is there to document and prioritize the list of bugs that we know about, whether or not they will ever be fixed. In this world, if it's a real issue, it's tracked and kept while it exists in the software, even though it might be trivial, difficult, or just not worth fixing. There's no such thing as closing the bug as "Won't Fix" or "Too Old". Further, there's no expectation that any particular bug is being worked on or will ever be fixed. Teams might run through the bug list periodically to close issues that no longer reproduce.
2. The bug tracker tracks engineering load: the working set of bugs that are worthy of being fixed and have a chance to be fixed. Just because the issue is real, doesn't mean it's going to be fixed. So file the bug, but it may be closed if it is not going to be worked on. It also may be closed if it gets old and it's obvious it will never get worked on. In this model, every bug in the tracker is expected to be resolved at some point. Teams will run through the bug list periodically to close issues that we've lived with for a long time and just won't be fixed ever.
I think both are valid, but as a software organization, you need to agree on which model you're using.
... or there's a software engineer somewhere who simply assumed that three letter navaid identifiers were globally unique, and baked that assumption into the code.
I guess we now need a "Falsehoods Programmers Believe About Aviation Data" site :)
And this is why you always use surrogate keys and not natural keys. No matter how much you convince yourself that your natural key is unique and will never change, if a human created the value then a human can change the value or create duplicates, and eventually will.
Yea, you don't have to fight back in order to be punished under "zero tolerance." You just have to be involved, including as the victim. Kids get punished all the time for rolling up into a ball while the aggressor beats them.
If only you could rely on common sense! But companies have been allowed to run roughshod for so long and sell things that are deceptively labeled for so long that the law finally had to step in with bureaucracy. You can't apply common sense when companies are allowed to label things as X when they aren't X.
Does something labeled "butter" contain milk? Does something labeled "milk" contain milk? This thread shows the answers to these questions are not straightforward and cannot be determined with common sense.
We -have- to have strict labeling rules around allergens and destroy products that don't comply because if we didn't, it would just be the wild west like it is with products that are not allergens.
For example of why it's not always so easy - Vanilla ice cream is being sold in the UK with 0 vanilla, 0 milk and 0 cream. No minimum milkfat requirements - they can use any fat they want.
Products are confusing, we shouldn't expect people to know how today's industrial food process works.
> We -have- to have strict labeling rules around allergens and destroy products that don't comply
No, this is absurd. We don’t have to destroy products that can otherwise be put to good use. The minuscule number of people who are simultaneously deathly allergic to milk and unaware that cream is milk would be just as well served by a recall that said to destroy the product if you have a milk allergy.
This is a black eye on the FDA, and at a time we can least afford the agency to have one. They should have worked out another solution with Costco.
I think it's actually refreshing to see the top comments and constructive criticism be about privacy concerns. It shows that even for little "Show HN" projects, there is growing intolerance of half-assing it. Not saying OP in particular is half-assing it, but it's good to see these questions being regularly asked front and center. I honestly wish the Tech Media paid more attention to privacy and security instead of just copy-pasting companies' PR statements as "articles."
My opinion is that the OP shouldn’t even half-ass it. Ignore anybody who has complaints about privacy and 0-ass it. People just love complaining and telling other people The Right Way To Do Things.
As the OP, I wasn't even complaining about privacy of the app or site per se. It was just feedback on how that part of the landing page copy made me, a potential consumer of the product (I'm in the process of buying a house rn) made me feel in the moment. Could be a quick copy change to fix.
As a home buyer, I've been beaten many times by an all-cash offer that was significantly lower than my financed offer. For example, a $450K all-cash offer where they'd close in 7 days beat my $525K 80/20 offer where it would have taken me 25+ days to close.
This makes sense for the seller depending on how often a financed offer falls through. Our agent mentioned that in Amsterdam for example over 1/3rd of the offers with a financing condition fall through. And they do so weeks after the signing of the agreement so it costs the seller significant time and money.
With such a high chance of not actually getting the sale done, sellers are motivated to take 475 immediate cash instead of 525 with a 1/3rd risk of having to do it all over. Especially if they need the cash to buy their next home.
> I've been beaten many times by an all-cash offer that was significantly lower than my financed offer
Note that all cash commonly means no financing contingency. I put in an all-cash offer and financed it. I just didn’t have an out if I couldn’t find financing I liked. (Legally.)
Your reply does not deserve to be flagged. "Holistic medicine" is just one of the many rebrandings of "alternative medicine." Maybe I wouldn't have put it exactly that way, but "holistic" is definitely one of those key words that should gently sound the quackery alert. Like "herbal" and "detox" and "homeopathy" and "naturopathy" and so on.
I admit I've been hired once from just a friendly chit-chat, but I can't see how this could be reliable. There are so many bullshitters in the industry, who, during character creation put all their skill points into Charisma. They are smooth talking, good looking, and have all those charming Ivy League mannerisms of an Investment Banker or Enterprise Sales person. And while they might not be able to be technically deep enough to fool an engineer interviewer, they will absolutely fool the director or VP who does the final screen and has the final say. These kinds of people flock to companies who don't do robust technical screens.
I can see your point about the bullshitters being able to fool a VP, but in that case they wouldn't be doing the coding interview anyway.
On the other side we're also seeing bullshitters that can ace any leetcode challenge, but not actually design anything of value or work well with others.
There's probably not a one-size fits all, but if you're going to do coding interview do them well and understand many don't do well in these types of interviews because they don't see the value, or feel that their other skills are being ignored.
Unfortunately, you often have to ask the interviewer (which is tough when it's a coding challenge and you have no way to ask for clarification on the rules). I know interviewers who will say "You didn't cover edge case A, B, and C, your solution is incomplete!" and other interviewers who will say "You are overthinking this, I'm just looking for an MVP."
1. The bug tracker is there to document and prioritize the list of bugs that we know about, whether or not they will ever be fixed. In this world, if it's a real issue, it's tracked and kept while it exists in the software, even though it might be trivial, difficult, or just not worth fixing. There's no such thing as closing the bug as "Won't Fix" or "Too Old". Further, there's no expectation that any particular bug is being worked on or will ever be fixed. Teams might run through the bug list periodically to close issues that no longer reproduce.
2. The bug tracker tracks engineering load: the working set of bugs that are worthy of being fixed and have a chance to be fixed. Just because the issue is real, doesn't mean it's going to be fixed. So file the bug, but it may be closed if it is not going to be worked on. It also may be closed if it gets old and it's obvious it will never get worked on. In this model, every bug in the tracker is expected to be resolved at some point. Teams will run through the bug list periodically to close issues that we've lived with for a long time and just won't be fixed ever.
I think both are valid, but as a software organization, you need to agree on which model you're using.
reply