Hacker Newsnew | past | comments | ask | show | jobs | submit | JoelSutherland's commentslogin

Fatalities per 100 million miles driven is not a great metric for measuring the reliability of Autopilot.

That number is influenced not just by Autopilot avoiding accidents, but also by the overall safety of the car. Teslas are incredibly safe in accidents. The current 25% lead that Autopilot has over the average is probably not attributable to Autopilot at all, and instead to the overall safety of the vehicle.

* Fatality rates vary by make/model quite a bit (up to 8x). Some of this is surely attributable to the relative driving skill of purchasers, but most is probably the safety of the cars themselves. Given the spread seen in this IIHS report I would guess that Autopilot performs worse than the average human. http://www.iihs.org/iihs/topics/driver-death-rates


It's not even a good figure for comparing fatalities. See my comment here [1]

Those 100 million miles include non-divided roads, motorcycle deaths, adverse weather conditions, and cheaper, older cars.

[1] https://news.ycombinator.com/item?id=12087603


Zenefits does not do payroll, they "integrate" with other Payroll providers. Of the providers I've been most impressed with ZenPayroll so this is a very exciting announcement.


To a small business owner, I'm not sure they know or care about the difference. Zenefits advertises themselves as payroll, benefits, and HR.

Defintely see your point though it seems like a distinction customers won't know


They'll know when they have to go sign up with a separate payroll service like ADT. It makes the offering less attractive.



This is not really the attitude a company should have when they manage benefits:

On the flip side, with so many people contributing code mistakes are bound to happen. That’s normal – after all we’re all just people, and people make mistakes. One thing that I’ve found particularly admirable about our team here is that people own up right away, and strive to fix things as fast as possible. No one wants to ship buggy code, but it happens. The nice thing about working with so many smart and friendly devs though is that you can trust that someone will be there to catch you if you fall and help you fix things.

We've caught and reported 4-5 bugs in production to Zenefits on really basic features. Three of our employees have now been asked to send a screenshot of the dashboard with the JS console open...


> This is not really the attitude a company should have when they manage benefits

Why exactly? They are talking at the individual employee level, not company wide. The statement above is: "[As an individual developer] it is ok to make mistakes, just own up to them and take responsibility."

They didn't touch on test coverage, integration Vs. unit testing, code reviews, UI automated testing, code quality inspections (both automated and manual), regression testing, external audits, or a whole bunch of other things a company can do to improve the quality of their software over the medium to long term. These exist to help mitigate an individual's errors.

If we take what you said above at face value, you're essentially saying: "It is unacceptable for an individual employee at a company who manages benefits to make mistakes ever period." Which when re-phased like that is patently absurd.

Your anecdotes above may be legitimate reasons to gripe about the quality of Zenefits' software. But these are issues with organisational quality, not individual quality. Individuals can and will make mistakes at any endeavour no matter how mission or life critical, the way organisations detect and resolve these mistakes is what is key to quality, not pretending that people should be mistake free, that's a pipe dream.


I'm pretty understanding of occasional bugs, but Zenefits' site has been one of the most consistently buggy pieces of software I've ever used. Every flow has had broken pieces of UI, incorrect form validation, totally wrong calculations, or some other frustrating flaw.

It's an incredibly useful product (and leagues better than the competition) but when they can't even calculate your 401(k) contribution correctly, imagine what's going on behind the scenes...I'm trusting them with a lot of financial and personal information and it erodes a lot of the trust & confidence I would have in them to see such shoddy work.


The problem isn't with the first part ("it's OK to make mistakes"), it's with the second ("just own up"). When a mistake is made, it's because some part of the benefit coding process failed. I work in an insurance company where 100% of benefits coding changes are put through QC, and then another 25% are put through a second level of QC. The costs of screwing this up are pretty high, and will make people pretty mad. You need to have a process where the vast majority of mistakes are caught before they get out the door.

I really can't speak for the company—it's just a single sentence in a blog post on an otherwise unrelated topic—but I imagine that's what the OP was thinking about.


> I work in an insurance company where 100% of benefits coding changes are put through QC, and then another 25% are put through a second level of QC.

For electronic engineering this is a known fault mode of inspection.

When the first line inspectors are busy they'll shovel stuff theough with less inspection because there's someone else to do so checking. But now that other person is busy, and they'll shovel stuff through because if the first line of inspectors are doing their job properly it should be okay.

So it's interesting to see this not fail in an indistry tha is data driven and cash sensitive.

It'd be interesting to know what the difference is.


Give the second line guys a bonus for every error caught, and make the first line guys pay?


Yeah, lets pretend there is a perfect process and also punish people who own up to mistakes. That is stupidly what most companies do: add more process, make developers stand on their heads. The fact is that certain types of logic errors are likely never to be caught by SCA, code reviews, test cases, or anything else. It's just a fact that bugs are going to get through no matter what. It's is far better to have an environment where fault tolerance is built in AND there is no punishment culture for bringing bugs to light. If you rely on process you will get a) people hiding bugs, b) blame culture c) more disasterous failures.


> The costs of screwing this up are pretty high, and will make people pretty mad. You need to have a process where the vast majority of mistakes are caught before they get out the door.

Its interesting to reflect on this statement in the context of Zenefits vs the insurance industry.


This Buzzfeed article corroborates your findings: http://www.buzzfeed.com/williamalden/zenefits-hr-rocket-ship...

Glad my benefits aren't handled by Zenefits.


When working for a devshop a while back, one of our programmers discovered a SQL injection by using some non-alphabet characters in their health insurance password...

We informed them. Never checked to see if it was fixed :)


And here are the two discussing it today: https://twitter.com/ChancellorFolt/status/636306368861966341


This linked article that talks about web pages sucking is 1.3mb and is first visible/readable after 4.9 seconds:

http://www.webpagetest.org/result/150715_SE_YM1/

An article from the site it complains about sure uses a lot more bandwidth (2.9mb) but at least it's visible/readable in 2.2 seconds:

http://www.webpagetest.org/result/150715_KC_YQK/

The bandwidth/resource waste sure sucks but having ads load asynchronously isn't as bad as a blank screen for 5 seconds.


Visible, but not necessarily readable: "This does not necessarily mean the user saw the page content" [1]

[1]: https://sites.google.com/a/webpagetest.org/docs/using-webpag...:


The link I added has a filmstrip view where you can verify that this isn't the case. Alternatively visit the two sites yourself! The multi-second difference is perceptible to a human being.


If zooming is disabled, the browser can respond to clicks without a 300ms delay since it doesn't have to wait for a double-click zoom. It seems like the best solution to this problem would be to make a global toggle in settings.


Alternately, you can just require multitouch zoom and get rid of the antiquated notion that you can double-click to zoom.


Double tap to zoom is a standard gesture for mobile Safari, hardly antiquated.


That's true, but given that pinch to zoom is nearly ubiquitous, and given that the double tap gesture requires a 300ms lag before responding to single taps, the Web would arguably be better without it.


I can confirm that working around this issue is horrible. That dastardly 300ms makes quick operation of a mobile app a complete pain in the arse. Constantly having to wait for iOS to catch up with you. It really makes the experience horrible.

But that's how iOS want it. If they made webapps that performant then they'd have trouble imprisoning everyone in the App Store.


About an inch, but actually less than an inch and even less so for women. So women are ~1% taller and 18.5% heavier. I don't think height is a factor.


You're assuming increased height only leads to a stretch in the z axis. If you linearly scaled someone up from 5'3 to 5'4 in every direction, the increase in volume would be 5%. So maybe not the main factor, but definitely a factor.


While you have a point, weight doesn't go like height cubed (you don't grow equally in all directions). I read an article a while ago (can't find it now) that looked at the exponent for various species. I think it was typically about 2.5 rather than 3. I suppose you could look at a BMI chart and back out the exponent that is assumed.


The actual formula for determining BMI only squares the height component.[0] Healthy humans should not even approach being cube shaped!

[0]https://en.wikipedia.org/wiki/Body_mass_index


I too run a small company and am a Zenefits customer. We've now done ~15 payroll runs with Zenefits and only 3 have worked without my manual intervention to fix a problem at the last minute. I don't think this will be the only lawsuit in their future.


Having used both ADP and Peak Payroll at our company in the past we have experienced a lot of manual intervention at both. Usually things get ironed out until some/any out of the ordinary change causes problems that end up taking a payroll or two to correct. Basically I'm saying that all payroll providers seem to have these problems.

We're back on ADP after our company was bought as that is what the parent company uses.


I can second this. We've been with Zenefits for over a year now and the issues don't stop. Many of their "integations" occur in meatspace: when a change is made on the Zenefits dashboard, a Zenefits employee then manually updates the related service(s). This has resulted in a number of errors over the course of a year.

Additionally their are still issues with validation on their dashboard. We had a problem where the dashboard allowed an invalid value to be entered for a monthly 401k contribution that was a big pain to unwind.


This works amazingly well on a Surface with pen/touch. It's the fastest app I've seen for going from idea to wireframes. So impressive that this could be done with web tech.


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

Search: