paxunix

It could get even more people to ride the bus if they extended the idea of dedicated lanes for buses farther into the suburbs and along major corridors (like I-5, but they'd get crucified by all the car drivers if that were to happen).

I absolutely hate my commute because on the very best of days (i.e. minimal traffic, which is almost never), it's 1h20m long (were I to drive on that exact same day and conditions instead, it would be 30 minutes--that's a steep price to pay for me to prefer public transit). 10 years ago it was great--40 minutes max by bus, but commuting from point A to point B almost only ever gets worse over time, never better. I'd love to take the bus all the time if it was much more consistent--but it never will be.

"Mass murder weapon" versus "justified homicide weapon" is just a situational distinction that does nothing to address the fact that the physical thing is identical and inextricably tied to horrible, irrevocable actions. Your gun doesn't become a "justified homicide weapon" until after the fact. Up until then, it's always just a weapon because you can't prevent or enforce its use for a particular, sanctioned purpose.

If you are going to argue about terminology, argue first about how can there be a "design space for the socially acceptable uses of weapons". The phrase is laughable. Weapons are for killing--that's why they're called weapons. Arguing about what to actually call the physical thing that does the damage is missing the point and is trying to draw attention away from the real purpose of the thing.

> What more money buys you, now and in 1916, is social status.

It goes well beyond that. With more money, I can pay someone to keep my house clean and maintain my yard, own a more reliable car, buy and eat better quality/healthier food. I don't have to care about how much it costs me to go to the dentist, nor how much I have to pay to vacation for two weeks in South America.

You can exercise money to buy social status, but at the heart of it, money buys ease of life. I bet Bill Gates very rarely thinks about how much money he has or how much something will cost him; your housekeeper thinks about that much, much more often.

> Your response is like saying "human rights violations are such a big problem that we shouldn't do anything about it".

No, it's not like saying that at all. I'm saying that companies are large, impersonal things nonetheless filled entirely with people with very personal goals and problems all uniquely their own, and all those people have to work together. At the base of it, these are people's decisions affecting other people. Are there bad things that happen to decent people at Amazon? Of course there are, just like at any other company. Acknowledging it doesn't mean condoning it, just as you pointing it out in an inflammatory way shouldn't imply Amazon neither knows nor cares about it. Amazon is not the sum total of the bad people decisions aired out in the online press.

Recognizing there are problems but not doing anything about them? _That_ is an issue worthy of scorn. If anyone's company does nothing when people problems are brought to the fore, _that_ is a problem that needs fixing.

Amazon's problems are under the magnifying glass in forums like this because Amazon is doing things that make the company exceedingly visible: the good and the bad shows up under that same lens. How often do you read on Hacker News about bad people decisions that IBM or HP are making? It's naive to think that because we don't hear about them that they have never had, don't have, and never will have any of the problems for which you are excoriating Amazon.

You must work for one of those other companies with 340,000 employees that always makes the right decisions, always puts people before policy, always maximizes shareholder value, always engages positively with the community, and always makes sure every single employee and customer and client and partner is 100% happy with everything that happens at all times. You should write a book about how easy that must be. It would be a bestseller. You could even sell it on Amazon, I bet.

That is terrible. It's extremely team-dependent at Amazon, whether you get the "you have to work long hours forever" team or the "I don't care if you put in your timeoff, just live your life outside of work while still getting your shit done" team. There are many possibilities, and recruiters aren't trying to match on what's important to you as a candidate, they're trying to fill the square hole with any peg they can.

How often are you restarting your browser that this would matter?

A number of people have commented about the quality (or its lack) of Amazon's "this fits/doesn't fit your car" data. Let me explain a little about how that works:

In North America, this fitment data conforms to a popular (but not the only) schema called ACES (Aftermarket Catalog Exchange Standard). It's a long and pretty well-defined XML schema that specifies things like year, make, model, and all kinds of attributes like engine configuration, fuel type, wheelbase, etc., as well as brand name, part number, quantity, and so on. Fitment data providers create an XML document according to this schema and populate it based on the products they say fit particular vehicles.

For example, say you are the manufacturer of a FRAM oil filter (FRAM is a common aftermarket filter brand in the US). It has a part number A123. You know it fits the 2000-2010 Honda Accord with engine XYZ. You add to your fitment XML document an entry for this filter that specifies brand=FRAM, partnumber=A123, parttype=oil filter, years=2000-2010, make=Honda, model=Accord, engine=XYZ. Now, you (or some 3rd party you designate that specializes in turning your catalog of products into fitment data), sends this fitment document on to companies that care about fitment information because they are selling your FRAM oil filter and want to be sure their customers can tell if it will fit their car or not (Amazon, Ebay, Rock Auto, etc.).

They take that fitment data and join it against their product database and out pops the yes/no fitment data you see on their website.

Now scale it up: there is no requirement that only one company produce these fitment records. Anyone else can produce a fitment record that says all the above, but for the 2000-2010 Honda Civic. Maybe that's a mistake, but as a receiver of the fitment data, Amazon or Ebay can't know it's a mistake--they can only presume the fitment data they are given is valid.

Now, complicate it further by adding the human element: e.g. some fitment data providers have fitment data in Excel spreadsheets. Some poor human fat-fingered that data from the spreadsheet into XML and maybe they left off the leading 0 on all the part numbers (because that's Excel's default for number cells). Oops. Now none of those fitment records will match to any parts in the database of the companies that sell them. Or they're entering this data off a piece of paper and can't tell if that's a 0 (zero) or an O (oh). Oops.

Or, worse: the fitment provider gets the wrong vehicle ID (because the schema is all based on IDs, not human-readable names) and submits fitment data that says that FRAM filter fits a 2000-2010 Tesla Model S. Well, that's extremely unlikely, but the receiver of the fitment data is a machine and the machine doesn't know that is completely ridiculous.

Or equally bad: the fitment provider says it fits a 2000-2010 Honda Accord, but doesn't specify the engine type at all. Now, Amazon's machines see that and think "the customer only needs to tell me their year, make, and model". A smart human knows it also needs the engine configuration, but the machine can't easily know that because none of its data specifies an engine configuration is needed for fitment. So Amazon sends out the filter because its data says "it fits!" and the customer is unhappy.

So, in the end, the customer is displeased because Amazon shipped them an oil filter that can't possibly fit their car, even though it told them it would because they can only go on what the data tells them.

A closely related problem is that sometimes a seller will have a product that they know should require fitment data (like an oil filter), but there has been no fitment data submitted for it. In that case, the company can neither say it fits, nor it doesn't fit--it doesn't have enough data to make the determination. This is common as the new model-years start to hit the marketplace: the car exists; you can buy it; you can buy parts for it; however, the aftermarket fitment data hasn't caught up with the car's attributes yet. It also happens when Amazon has fitment data for some models but not for others, even if the part will fit those other models--without data saying so, there's no way to say "yes that will fit your new 2017".

To complicate it even further, if you're talking about this stuff outside of North America, there are other schemas and data providers with very little overlap of the NA offerings. This is visible in the very different fitment experience you see in most EU countries on Amazon (for example, try https://www.amazon.co.uk/auto and select a car).

The takeaway? Unhappy customers result when you have complex data quality problems, and sometimes it's no fault of the implementation at all.

/bin/true

Without fail, it has always done exactly what I wanted it to do. Simple. Solid. Reliable.

That is not a good argument at all. It's a side-effect of collecting metrics. Uber has no reason to know the battery status of my phone--them knowing it will not help them improve service to me in any way.

If a site can email you your password, they are basically storing it in clear text. Otherwise they could not send you your password (because they would only have the hash of it). This is clearly a huge security risk.

I didn't even read the article because I know there is no secret.

We don't hire the best people. We hire average people, some good people, some great people, some mediocre people, and some people who aren't very good at their jobs. Some of those mediocre and average people turn out to be great people after all. There's no secret to it. We like telling ourselves there is a secret because everyone likes to feel special and we think if we can mirror other companies that we think are successful then we can be successful just like they were.

In the end, you have people working with people. If you're fortunate, you get the right people interviewing the right person at the right time, and you get a great hire. At best, you can filter out the obviously bad ones. The rest, you'll find out about as you go. Some will surprise you, some will meet your expectations, and some will be disasters. Fire the bad ones; coach and mentor the average ones; keep track of the great ones.

Go build some shit with people you like building shit with and stop trying to figure out how to make hiring objective. You can't.

You must pay attention to the details if you will ever become a good programmer (not necessarily the same as being detail-oriented). This may mean different things depending on context: designing a system? The implementation details aren't very relevant yet. Building the system? Those details become very important.

I've been programming for over 20 years and I've come to think the two most important factors contributing to a "good" programmer are communication skill and attention to detail (both of which can be learned, though some seem innately good at both at the outset).

For example: let's say you are reviewing someone's code. You notice they've missed some null checks, haven't properly handled exceptions or ignore some failure cases, aren't doing object comparisons properly, etc. They insist the code works fine (if you're putting up untested code for review, you should be beaten), but those little things now consume the reviewer's valuable time and head-space when they should have been sorted out before the review was ever posted. As the reviewer, you get caught up in an endless stream of niggling little details and nitpicking, rather than focussing on the logic and design and structure of the code. Meanwhile, the programmer feels very productive ("hey, I've just churned out a whole new module") and moved on to the next task, essentially relying on everyone else to finish his job.

Missing some things like this now and then doesn't make one a bad programmer, but consistently neglecting/forgetting them implies a lack of attention to detail and makes me wonder what else they're missing that I'm just not seeing (slog through several hundred lines in a code review and you will inevitably start missing things (http://www.ibm.com/developerworks/rational/library/11-proven... )). It also creates a lot of busy-work churn for the whole team that has to deal with that code. They may seem to be very productive, but they're actually dragging down the overall productivity of the team because everyone else has to point out the little things that were missed, as well as most likely re-review the code once all the small-detail changes have been made.

EDIT: fixed link

I had a similar experience back when I'd interviewed with Bloomberg. I was scheduled for a set of interviews with one team in the morning and another set with a different team in the afternoon. 1pm rolls around and the Bloomberg recruiter tells me the 1st team wanted to make an offer so there won't be afternoon interviews. I'd been looking for work for quite a while so it was really gratifying to have things just suddenly fall into place. Plus now I had the rest of the day to explore NYC a bit.

A reddit user has started a tumblr to catalog ad-less, up-front-purchase, single in-app-purchase Android games:

http://honestandroidgames.com/

No white on black?!