Tell HN: If your HN submission doesn't get any upvotes, don't worry about it - <AUTHOR> I've recently been seeing many comments on Hacker News complaining that their submissions don't receive any points. As a result, they believe that vote manipulation techniques such as begging friends for votes on social media and using sockpuppet accounts to counteract this injustice are justifiable and that "everyone's doing it". While blatant voting manipulation may be the status quo at a certain other startup-oriented link aggregator, it is never good because it breaks the integrity of the service.
However, the lack of upvotes is just how link aggregators work.
The goal of many HN posters is to hit the front page. If you've received 10 points, you'll probably have hit the front page. However, depending on time of submission, you have a 10% to 20% chance of hitting 10 points: http://i.imgur.com/MdUvMB9.png
That's low, even if your blog post or startup is the Next Big Thing.
However, what's the typical behavior for HN submissions? Here's a chart of the median points for HN submissions at each timeslot: http://i.imgur.com/SN5BuAJ.png
The median is either 1 (no upvotes) or 2 (just 1 upvote), which reinforces how the typical behavior of HN really is.
Yes, it's possible for submissions to slip through the cracks. HN allows resubmission of links if they haven't had any discussion (as long as you don't delete-then-resubmit to obfuscate the fact that it's a report). If your submission doesn't get points, submit again later.
(Code and data for the two charts are available in this GitHub repository: https://github.com/minimaxir/hn-heatmaps) <comment><USER2> I think the problem is how easy it is to game HN, how effective it is to game HN, and how random and spurious it is if you _don 't_ game HN.

It's _really_ difficult to just have your post get to the front page organically. It's possible (and probable) that when you submit there just aren't enough people looking at the /new page, so a lot of it comes down to sheer luck. A lot of good/great posts go by unnoticed. Getting 1 or 2 friends to upvote would probably increase your likelihood of being on the front page by 90%.

I've been gravitating towards things like [http://lpushx.com](http://lpushx.com), both because they're smaller, and because everything has more of a chance to "survive."

Ironically, this post just exposes how helpful it is to do the behavior it discourages. When you're trying to kill a lucrative behavior (especially something that exposes a loophole), saying, "Please don't do this behavior" is probably the worst way to do so. Now several people just figured out that you _can_ game the system. I would recommend dang kill this.

<comment><USER3> This just occurred to me and I'm sure it's probably already been considered.

The home page should have display a sidebar or similar with the top 5 or so 'new' items. They then have a chance to catch someone's eye and get voted up to the 'real' front page.

I'd love to spend more time on 'new' \- I just tend to forget about it. Something that improved the visibility of new items would help me (..help HN)

<comment><USER4> The average post in /newest is so bad that it's not clear you want to promote any of them to the frontpage randomly. I'd guess on average on a 30 item page of /newest I might click through two links, and upvote one.

I actually wonder if the stats in this post can possibly be correct. Never would have guessed that anywhere near 10-20% of the submissions hit 10 points. There's a lot of spam and offtopic stuff, and it is indeed really common for great posts to get lost in the noise with just a couple of votes.

<comment><USER5> What about the first five posts from the 2nd page of /newest, with the added addition that at least one newer than it must be dead (e.g., moderators have at least looked at the queue)?

<comment><USER6> [dead] stories are often, perhaps mostly, killed by software.

</comment></comment></comment></comment></comment><comment><USER7> Great points. Non-submitters seldom realize how often new content goes ignored around here. Unless you're one of the top 20 most recognized names here or unless you're writing about fad-of-the-week, submissions are mostly ignored.

 _is never good because it breaks the integrity of the service._

vote manipulation is called _hustling_ these days. it tends to be okay if you're in the blessed class allowed to manipulate people or are doing it for a good cause (a private for-profit startup needing "exposure").

 _They delight in breaking rules, but not rules that matter._ [http://www.paulgraham.com/founders.html](http://www.paulgraham.com/founders.html)

</comment><comment><AUTHOR> Clickables:

10+ points chart: [http://i.imgur.com/MdUvMB9.png](http://i.imgur.com/MdUvMB9.png)

Median chart: [http://i.imgur.com/SN5BuAJ.png](http://i.imgur.com/SN5BuAJ.png)

GitHub Repository: [https://github.com/minimaxir/hn- heatmaps](https://github.com/minimaxir/hn-heatmaps)

</comment><comment><USER8> I always try and 'remember to upvote'. So much great content goes through here, I think many members forget to upvote things they thought were interesting. I often forget to hit upvote on an article I clicked through to and read/enjoyed.

Might lead to upvote inflation but I think extra positivity isn't a terrible problem to have.

</comment><comment><USER9> > While blatant voting manipulation may be the status quo at a certain other > startup-oriented link aggregator, it is never good because it breaks the > integrity of the service.

 _Why_ does it break the integrity of the service? Sockpuppets, sure, but why does asking friends/acquaintances with established HN accounts (presumably the HN software can distinguish these cases) for upvotes work contrary to the goals?

Presumably if you have an account and you "vote well" \-- that is, your upvotes are well-correlated with what other people upvote and don't downvote -- you know what people like to see. If a friend asked me to upvote their spam listicle, or a question they could just ask me and get an answer, or some politics story irrelevant to hackerdom, I'd say no. If I "manipulate" a friend's post, I'm making as much of an endorsement of the content as HN- appropriate as if I upvoted something I saw on the front page. (And if I abuse that, my upvotes should get disregarded.)

To be clear, I'm not advocating that bugging your friends for upvotes is a _good_ system. I am advocating that posters asking people who care about HN for endorsement is explicitly desirable, and the software and community norms should be designed to reflect this, instead of the community norm deciding that vote manipulation is an acceptable means to an otherwise-technically- unsupported end.

</comment><comment> vezzy-fnord I've been noticing recently that submissions I post will go for hours without upvotes, and then at some point around the 7th hour or so they'll climb to the middle of the front page with around 15-20 upvotes.

Is this manual intervention, or is HN testing out some new heuristic?

<comment><USER10> This is just how things on the internet work.

Think about it logically. Not every person is going to see every single new submission. It takes time for the submission, if it is any good, to gain momentum and rise to the level that more people will see it. The more people that see it, the more votes it will receive.

Unless your submission is really popular or noteworthy for some reason, 8 hours seems fairly typical for an average submission.

<comment> vezzy-fnord Except from my observations, at such a timeframe most of them simply die from lack of visibility, or even if they do gain upvotes, they don't actually hit the front page (I think a time-based penalty?).

I was thinking out loud because dang has been speaking of HN testing out a new feature to resurrect posts from hellbanned users (and because HN has been sending out emails asking people to repost stories), and assumed some other mechanism is also being tried out.

<comment><USER6> You're referring to a few different experiments, but the one relevant to your question upthread is what I wrote about at [1], specifically "reviewing the story stream for high-quality submissions and occasionally lobbing one or two of them onto the bottom of the front page".

How this currently works is that when we notice a substantive overlooked story, we add it to a pool. Every now and then software picks one from the pool and randomly places it near the bottom of the front page. It does that by reducing the time decay and/or adding a small number of points. If too much time has gone by for a small change to suffice, the software doesn't try, and instead we sometimes email an invitation to repost the story.

This system would never add 15 points, nor place a story as high as the middle of the front page, so if that's what you saw it means the community noticed the post at the bottom and took it from there—which is the intent of doing this in the first place. We don't much care which stories get taken up this way vs. which don't. The idea is to do the minimum necessary to give high- quality stories a second chance and mollify the cruelty of /newest.

1\. [https://news.ycombinator.com/item?id=8790134](https://news.ycombinator.com/item?id=8790134)

</comment></comment></comment></comment><comment><USER11> It's worth noting that there are two sorts of posts that people will try to game the voting process - submissions by people who want the status of higher karma among their peers and submissions by startup founders who want "traction"[1]. That is to say, people believe there is actual, real tangible value in getting upvotes. To that end, while it'd be nice for HN to be more organic, unless there's a penalty for gaming the system it's not going stop just because people ask nicely.

[1] The traction you get on a site like HN is useful for feedback but it probably won't covert to sales unless you building something for other startups. It's not _real_ take-it-to-the-investors traction.

<comment><USER12> I would point out that, getting karma using submission isn't that hard. Considering that Hacker News is very tolerant to re-submissions, you can usually land your submission to front page, posting some of the many awesome articles that you might have read from here. Some of the articles have been posted dozens of times, yet they articulate interesting discussion, even after being posted nth-time.

<comment><USER6> True, but there are two distinct cases.

1\. You post something awesome that you saw on HN that didn't get any traction. This we encourage! It's a kind of community service and deserves karma, though arguably the original submitter should share some.

2\. You post something that has had significant attention on HN already. This is ok, but only for the very best stories and only after a year or so (cf. the FAQ linked at the bottom of the page).

<comment><USER12> Does HN penalize submission violating the second point?

<comment><USER6> We bury the post as a duplicate.

</comment></comment></comment></comment></comment><comment><USER13> I can say from personal experience that it is much easier to get on the frontpage if you have a group of four or five people ready to upvote your content. It is possible to get a post to rise without that, but it often takes a handful of reposts.

I believe the crux of this issue is not enough people frequent the new page ([https://news.ycombinator.com/newest](https://news.ycombinator.com/newest)). If that page got enough traffic, the legitimate votes would outweigh all but the most systematic attempts to 'game' the system.

<comment><USER14> I can speak for myself that I often forget that the new page exist.

</comment></comment><comment><USER15> Idea for a fix: Perhaps HN should have separate karma to reward upvoting on /new on links that are successful later, much like reddit used to have (or still has?) trophies for correctly predicting that a link reaches the frontpage. If there is more incentive to vote on new items you get more accurate estimates of the link quality, and it also _does_ warrant reward to sift through lists with such a low SNR.

</comment><comment><USER16> We've seen some legitimate posts consistently reported and removed. There are definitely fishy dynamics.

<comment><USER17> The stuff they do to detect voting rings is broader than you might expect, so if you're submitting things and having them fail, consider not telling your friends about it.

</comment></comment><comment><USER18> Despite all of these problems, I always have a good reading here on HN.

<comment><USER19> The issue isn't that content rises which isn't good, it's that good content doesn't rise. So there might be 3x more good stuff getting posted than actually makes it onto the frontpage.

<comment><USER18> Yes, thinking a little bit more, I agree with you. But in my case, just as it is, HN has so much good content that I can't read it all.

</comment></comment></comment><comment><USER20> I have better luck getting upvoted on weekends or as a side article to a topic-of-the-day, but I tend to submit articles that are either directly computer related or about systems that are not going as planned.

</comment><comment><USER21> HN really should allow resubmissions after a certain number of days. Its fine to have an imperfect algorithm, its rather frustrating to pretends its perfect.

<comment><USER17> It does. Just put ?resubmitted=true (or any other junk) at the end of your URL. Wait a couple days before doing it.

Don't resubmit if your original submission generated a thread, or hit the front page (you can resubmit if that happens later in the year).

<comment><USER22> Or, more simply and without actually sending query parameters to the site, append an empty anchor '#'.

<comment><USER17> The one reason I have not to just put empty anchors on pages is that people might write comments saying your story is a "dupe" if you don't make it obvious that was intentional.

(But then, they may do that anyways).

</comment></comment></comment></comment><comment><USER23> No worries, it's just not worth it to post on HN.

</comment><comment><USER24> Sure, don't worry about wasting your time submitting links that have a 80-90% chance of being ignored. Do what I do and, once you manage to get enough karma points to no longer care about them, simply stop trying to contribute.

There's always lobste.rs for when you really want to share something with your peers.

<comment><USER25> lobste.rs is only accessible through invitation, can you send me one?, echo bUBqYXZpZXIuaW8K | base64 -d

<comment><USER24> Invitation sent. I don't know when they disabled the form to ask for an invitation. I used that more than a year ago when I joined. Maybe it's the curse of any online community to get shittier as the time passes...

<comment><USER26> Stefan, would you please send me an invite to lobste.rs?

</comment></comment></comment></comment><comment><USER27> I love the irony of this post.

</comment><comment><USER28> > While blatant voting manipulation may be the status quo at a certain other > startup-oriented link aggregator

As I was recently told...

> No acerbic swipes on Hacker News, please.

Let's try to avoid double standards, OK?

</comment><comment><USER29> >it is never good because it breaks the integrity of the service.

So you are trying to imply that HN(or any other link aggregator) have integrity?</comment>


The White House should end the bulk collection of Americans' phone records - <AUTHOR> http://www.washingtonpost.com/opinions/the-white-house-should-end-the-bulk-collection-of-americans-phone-records/2013/07/26/c3c0103e-f553-11e2-9434-60440856fadf_story.html?tid=rssfeed

<comment><USER2> Notice the word "American" in the title, as a citizen of an allied nation which always stood by US it pisses me off being snooped on since what the NSA is doing would violate all the privacy and data protection laws here and is well just plain wrong

<comment><USER2> ... furthermore

How would "Americans" feel about some other nation spying on them? Do you guys realise that you are handing a get out of jail free card to Chinese, Iranians, Russians to continue censoring and surveying their citizens and YOU LOT as well

<comment><USER3> What's with the preaching?

First, quite a few other nations already spy on us and did so long before the NSA put all their cards into the digital basket. They would continue to do so regardless of anything the US did.

Second, your own government is cooperating and probably adding quite a bit more to the mix.

Third, "Americans" have little do with it. I don't condone it and I have no control over it. Many are apathetic, sure, but many more are apathetic in _your_ own country. Most of the outrage in the media and political circles has been in the US. Explain that?

<comment><USER4> Personally, I'd say we need to remain aware that we have a leader role on this tiny planet. What we do will always be kind of seen as "the future".

We have _much_ more power than any nation and therefor we have _much_ more responsibility. If _we_ f#ck up, the world's f#cked. It may sound arrogant, but that is the power balance of today as I see it.

We have more power and therefor more potential to do good and to save the planet than any other nation. But recently, we have used it pretty much against that goal...

</comment></comment></comment></comment><comment><USER5> What is the oath of office is for an attorney general? It can't be anything about upholding the constitution, obviously, otherwise Eric Holder would have been indicted already. Holder could go down as the worst AG in American history. He's even worse than the guy who lost an election to a dead man, and wanted to make dancing illegal.

<comment><USER6> [http://www.answerbag.com/q_view/41797](http://www.answerbag.com/q_view/41797)

All the way to postal employees.

</comment></comment><comment><USER7> ..and the worldwide hoovering up of internet traffic, for surveillance purposes.

<comment><USER8> Yeah, to me that seems like a much bigger issue, considering that all communications are moving on the Internet (even "voice" calls). But I suppose they are pushing for this first, because a lot of politicians are old, and fear the phone spying much more than they fear the Internet spying.

<comment><USER4> _But I suppose they are pushing for this first, because a lot of politicians are old, and fear the phone spying much more than they fear the Internet spying._

That is probably true. And so frightening. Basically, those politicians don't really know how tech works and what the real dangers are. And they're supposed to protect the citizens with their decisions...

Plus, when you get old, you have much less of an incentive to think "long term", obviously. There should probably be some rule that restricts older politicians to a "consulting-only" role.</comment></comment></comment>


Color Founder Plots Data Atom Bomb - <AUTHOR> http://www.adweek.com/internet-week-blog/startup-color-founder-plots-data-atom-bomb-132316

<comment><USER2> "He said Color Startup will make advertising more relevant to consumers since it will know where a person is, who they are with, and what kinds of behaviors the person demonstrated in similar situations."

Utterly horrifying if it's true. If this is an indication of what's to come I'll be avoiding any offerings from Color like the plague. Is it out of the question that someone could base a software company on a service that doesn't involve marketing or invasion of privacy? Is that too much to ask?

</comment><comment><USER3> Cool story, but what is a data atom bomb? I might be blind or something, but I don't see any mention of atom bombs in the article...</comment>


Stripe put my startup out of business before I launched - <AUTHOR> https://justink.svbtle.com/stripe-put-my-startup-out-of-business-before-i-launched <comment><USER2> > charge-control.js was the front-end JavaScript that users add into their > existing checkout page. It essentially just monkey patches

You can't do that. Essentially you advocated using a man-in-the-middle library. Running that running javascript client-side would completely break PCI compliance. Stripe literally couldn't stop you from operating, but they could break integration with you (i.e. not allow you to collect money via their own API). They could also refuse services to anyone who used your middle-man application.

What you should have done instead is have a backend application that operates _after_ the token is created. Once you have a token, do fraud scrubbing and throw away the token if it fails.

You can't break PCI compliance, if you do, then you open yourself, your clients, and everyone else on the chain who knew you existed and did nothing to litigation----or worse, simply being banned by VISA, thus dying completely as a company. I've known a few payment processing companies who inadvertently went against a regulation, and VISA banned them for life. It's a monetary death sentence, and VISA tends to track _everyone_ associated with building the company and refusing to work with them in the future too because it is seen as risky.

I don't really blame Stripe for seeing "client side javascript" then immediately burning any bridges.

<comment><AUTHOR> Back up. I never transmitted any credit card details. All the inputs were heuristics about the end-user (ip address, GeoIP location, user-agent, referer, language, etc) or transaction meta-data (price, etc). Card number, expiration, CVV were NOT part of the inputs in Charge Control.

<comment><USER3> > _I never transmitted any credit card details._

PCI compliance is only partially concerned with transmitting CC details, and is very much concerned with "YOU SHALL FOLLOW THE RULES".

 _The rules_ say you are not allowed to do what you were doing. It's completely irrelevant if what you were doing is not a security or data transmission issue, it's simply against the rules.

PCI compliance is an absolute nightmare, and is not something to be reasoned with, trust me. Logical thought and analysis has no place in PCI compliance. Follow the rules or else.

<comment><AUTHOR> I'd be curious if you can point to a specific section of PCI that states that a 3rd party cannot collect user meta-data. If that is true Google Analytics and Intercom could not track on checkout pages.

<comment><USER4> I don't think it's a question of collecting user metadata or not. Here it really depends on "are the credit card details touching any non-PCI-compliant code?"

Section 6.3.2 requires you to verify any "custom" code released to a customer that handles credit card information.[1] The way I see it, since your code touches that information, you must be PCI DSS compliant or you're breaking the chain of trust.

1: [https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2....](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf?agreement=true&time=1477005719371#page=55)

(This is my opinion, which should be taken with a grain of salt.)

</comment></comment></comment></comment></comment><comment><USER5> I've posted this idea before on HN, but: if you believe you have a better way to detect fraud, put your money where you mouth is, and price and sell insurance on a per-charge basis. If a chargeback is made for for fraud, you would cover the loss.

What stripe has done is great, but is really a rules engine, and the challenge will be keeping those rules up to date and making the business decisions to feed into the rules. If you price and take-on the risk, it becomes a very simple business decision for your customers: "am I still making a profit?"

This is of course a much harder business ... but don't give up just yet!

<comment><USER6> Unfortunately this wouldn't really work. If you're selling insurance, you're going to have a strong incentive to play it safe. If you run a business, you're going to be furious if legitimate customers are rejected (which is unavoidable at some level, but no matter what level that is you're going to make the business furious when they discover a legitimate charge being rejected).

<comment><USER5> I wasn't thinking about outright rejecting any charge, but rather that you would price some charges more expensively than others. As a seller of insurance, you're going to price above your estimated percentage, to give you some profit and compensation for the risk, but if you price too high you have no revenue.

It also becomes a much more interesting market if there are multiple competing providers of insurance that bid against each other (just as ad networks work, for example).

As a buyer of insurance, I would always have the choice to not buy the contract and take on the risk myself.

If the market works (which is a big if), it should become an efficient transfer of risk to companies that are experts in evaluating it.

Very interested to hear more of your thoughts though, as you're obviously part of the target audience at your dayjob!

</comment></comment></comment><comment><USER3> That's a very clickbait title.

What you mean to say is "Someone beat me to the punch".

<comment><USER7> Or I built a startup on shakey ground.

It's the equivalent of using hubpages instead of your own domain name for a marketing site. Or relying solely on SEO etc.

Your fate is on the hands of another company that can pull the rug.

</comment></comment><comment><USER8> It may not be a bad idea to position your product as "Stripe Radar for the rest of us." Basically, companies that can't use Stripe for whatever reason can still get Radar-like protection through your product. This will be a lot more integration work for you, though.

</comment><comment><USER9> From the article: _" The entire premise was to piggyback on Stripe and allow Stripe users to specifically create rules to prevent and reduce fraud and chargebacks."_

That's usually a bad business concept, unless you have patent protection. If you get successful, the big guy takes your idea.

<comment><USER10> Not really. If that were the case, using the API of a company to build a business on would always be a bad idea. If it's a good idea, and you can execute quickly (something big players generally struggle with, for reasons good and bad), getting traction with users is the key.

<comment><USER11> Not always a bad idea, but always a huge risk. You're farming out your core competency and are 100% subject to the whims of whomever controls that API.

</comment></comment></comment><comment><USER12> > Business model

> Pricing was to be charged per successful request (accept) > and similar to > Sift Science in terms of a handful of cents > per request. Reject requests > were to be free.

That strikes me as a weird way of doing the pricing. If a request was successful but should really have been rejected, the user is paying. If the request was denied but should really have been successful, the user of the service (of the fraud detection service) is loosing.

Also, this part sounds really scary when you're dealing with payments:

> . It essentially just monkey patches Stripe.card.createToken() to call our > api first

Would probably brake the payment as well if Stripe is updating the script (and since the script HAS to be loaded from their domain, nothing you can "guard" against)

</comment><comment><USER13> I was forced to create something similar to Radar (minus the fancy machine learning) as we've been seeing huge amounts of fraud, it's been running nicely and the fraud/disputes rate went down around 98%, what I found to be a great factor in determining if a user is a scammer is the user's behavior before purchase, so in the end what I wan to say is that there's plenty of improvement to be done in the space ;)

<comment><AUTHOR> Would you mind sending me an e-mail (in profile). Curious to hear about your experiences and factors.

</comment></comment><comment><USER14> Your mocks look really nice! If you're interested in the fraud problem, you might try some of the other fraud detection startups, like Sift Science (which you mention), Forter, Riskified, or Signifyd. I'll bet you'd bring a unique perspective, having built parts of Charge Control.

<comment><USER15> Am I missing them? All I see is a landing page. The screenshot of the rules is actually from Radar.

</comment></comment><comment><USER16> It's hard to imagine that you didn't once consider this outcome? At Control (the Android/iOS/Web app for Stripe) we knew Stripe was making an iOS app and we continued to make ours anyway, because we knew we were able to offer a different featureset. If Stripe is integrating such a system, then that helps validate your business model.

Since we built on top of Stripe, we kept an open dialogue with them so we wouldn't be caught by surprise like this. I think it's really important to have an ongoing conversation with _all_ of your most important vendors to be aware of their roadmap, especially startups because things change so quickly.

There are multiple companies who have written an API similar to Stripe's, have you considered applying your API to Braintree, Alipay, or any of the other many worldwide processors? If you really have a working anti-fraud product, the worst you could do is sell it. Don't just throw it in the trash.

<comment><USER17> He says in his post that his product would've revolved around allowing merchants to set rules on who could buy. Radar is a product centered around Stripe using deep learning with their own data to detect fraud; allowing merchants to set rules is just the cherry on top.

OP mentions Braintree but is rightfully hesitant. The release of Radar might send them playing catch up and OP is a solopreneur that could just as easily be working on something with less competition.

<comment><USER16> Sorry, I'm not sure what you're getting at, I read the post and I'm more than familiar with what Stripe is up to.

There are _countless_ startups building on Stripe's API, if Stripe hadn't done this there would have been plenty of other competition. I would expect OP's service to have planned to differentiate themselves by target market, effectiveness, price, or payment processor.

Stripe just has a really easy API, but the competition has almost caught up to them. Anti-fraud is a hard problem, so if OP's solution is really novel, it should be applicable to other platforms.

</comment></comment></comment><comment><USER17> Beyond the PCI compliance issue, this would've been a solid idea.

I don't think there's anything wrong with piggybacking - it's shrewd if anything - though this time you definitely got bested by the venture funding. One idea closer to a winner.

How did you plan on marketing this?

</comment><comment><USER18> Justin -

Sorry this didn't work out well.

Been watching your other projects over the past few years and have been impressed.

Not sure if you have started a new project yet, but I think I have something you might be potentially interested in.

Send me a DM on Twitter, handle is "marak"

</comment><comment><USER10> Have you reached out to Stripe? While they obviously won't be replacing Rader with your product, they might have some ideas about what to do with the work you've done.

</comment><comment><USER19> What happens if an attacker simply blocks your JS?

</comment><comment><USER20> I'm happy no CC details had to live inside your hipster bs stack.

</comment><comment><USER21> Why is this on hacker news?

<comment><USER4> Because someone posted it. But it'll likely fall off the front page soon.</comment></comment>


'F for Fake': Orson Welles' masterpiece of oddball art cinema - <AUTHOR> http://dangerousminds.net/comments/f_for_fake_orson_welles_asks_what_is_reality_in_dazzling_masterpiece_of_odd <comment><USER2> This video from "Every Frame a Painting" about 'F for Fake' is good as well: [https://www.youtube.com/watch?v=1GXv2C7vwX0](https://www.youtube.com/watch?v=1GXv2C7vwX0)

<comment><USER3> I'll go ahead and give my vote of confidence for all of "Every Frame a Painting" \- for a complete newbie like me, it was an amazing introduction to film in general and understanding what to pay attention to, and why certain movies or directors are interesting or exciting to some people. Now I can't help but see more of these details everywhere.

The Akira Kurosawa one, the Ensemble Staging one, the Satoshi Kon one, the Wolf Children one are some of my favourites.

Nerdwriter1 does similar stuff but it's a bit more hit or miss for me. Some of it I love, versus some is a bit too out on a limb.

<comment><USER4> I'm glad I'm not the only one who feels that way about Nerdwriter1. I loved his Shane Black and Lord of the Rings leitmotif videos but some of the more conceptual stuff can be pretty hard to take. A good example would be his Bon Iver video which mostly seems like conceptual waffle.

<comment><USER5> I think he [the Nerdwriter1] tries a bit too hard to keep a regular schedule.

Compared to Every Frame a Painting who seems to release videos when he finished it.

</comment></comment></comment></comment><comment><USER6> [http://www.teemingbrain.com/2013/05/09/orson-welles-on- chart...](http://www.teemingbrain.com/2013/05/09/orson-welles-on-chartres- cathedral-authorship-and-the-purpose-of-human-existence/) This particular video is worth watching even if you don't watch the whole movie.

<comment><USER7> This is definitely the best scene. Everybody should watch this.

</comment></comment><comment><USER8> If you enjoy this, I also highly recommend "Filming Othello", a similar video essay. Will be available hopefully in higher quality on the upcoming Criterion release of Welles' Othello, or right now on Youtube: [https://www.youtube.com/watch?v=fvqeQt8aLnU](https://www.youtube.com/watch?v=fvqeQt8aLnU)

</comment><comment><USER9> On a general Welles note: I also recommend One Man Band [http://www.ubu.com/film/welles_oneman.html](http://www.ubu.com/film/welles_oneman.html) which is actually where I first heard of F for Fake and talks a lot about Welles ' creative process (or well talks about how he was creative).

</comment><comment><USER10> I loved that film! It is pretty weird, but whole heartedly recommend it.</comment>


Software Checklist - <AUTHOR> http://www.solipsys.co.uk/new/SoftwareChecklist.html?ColinsBlog <comment><USER2> What I object to here is the core principle that there's something to fix in software development terms here.

There's not. We've got robust, reliable tools for creating nearly bug-free software. We have the usual engineering principles; we have automated testing; we have virtual machines and documented environments and specifications and APIs and all the rest.

The problem is, there is a cost associated with preventing software bugs, and it's a big one. There's a reason Facebook kept saying "move fast and break things" \- their software was buggy as shit, but the cost of that was minimal; in situations where bugs don't matter as much, _time invested in robust bug- free software is an undesirable expense_.

In the Heartbleed case, this is reversed. There's a highly-sensitive, critical bit of Internet infrastructure; there have been minimal resources invested into it, but it is relied on by a lot of key systems.

So the problem is a "social" one, in a sense. OpenSSL as a project did not invest enough in reducing the occurrence of bugs, and this resulted in the vulnerability. It's not the maintainers' fault, really; it was irresponsible for so many of us to rely on the software without considering it's quality.

I suspect we'll start seeing renewed focus on bits of important software like OpenSSL, and greater attention to the engineering tradeoffs. So there's an upside to the whole thing...

<comment><USER3> > We have the usual engineering principles

No. We don't. As Alan Kay said, programmers don't have a solid concept like an arch to build on. In real engineering, when you build a bridge, a single rusty rivet won't cause it to fall down. In software, a single pair of misplaced braces give you critical "goto fail" bugs. (And don't fool yourself into thinking that static analysis catches all these errors.)

It has become fashionable to say that automated tests somehow turn programming into a rigorous discipline. This is bullshit. Tests are a decent band-aid which kinda help sometimes if you spend half your programming time writing them. And will still miss plenty of horrible bugs. In truth, programming remains a poorly-understood endeavor. Checklists as auto-written automatic tests might actually be a step in the right direction, especially if compilers start to analyze the kinds of mistakes individual programmers tend to make.

<comment><USER2> _No. We don 't. As Alan Kay said, programmers don't have a solid concept like an arch to build on. In real engineering, when you build a bridge, a single rusty rivet won't cause it to fall down. In software, a single pair of misplaced braces give you critical "goto fail" bugs. (And don't fool yourself into thinking that static analysis catches all these errors.)_

Yes, we do. Misplaced braces can cause catastrophic failure, but that's _precisely because engineering principles were not followed_ ; the system was left with a critical vulnerability which meant that a typo could cause catastrophic failure.

We can, however, build systems that don't suffer from these problems. Look at the Shuttle, for instance; multiple redundant machines making the same calculations, and additional machines running _totally independently developed_ software. AFAIK the system has never failed.

So I dispute that there's a problem here in terms of our ability to develop critical software with engineering-level quality. The problem is that software in an order of magnitude more complex to reason about than e.g. a bridge, and as a result developing software to the same level of quality would in most cases be a waste of time.

<comment><USER3> > software [is] an order of magnitude more complex to reason about than e.g. a > bridge

I think you're trying to flatter our profession. Software is not more complex; it's just that we don't know what we're doing well enough to have useable, reliable components. Like arches. Or even just rivets.

To stretch the bridge analogy further (probably almost to its breaking point), it's as if I'm about to start work on the Hoover Dam Bridge, but I have to start by getting some rivets. So I first go out and pick up some pieces of iron ore, and start trying to figure out how to build a smelter that can introduce just the right amount of carbon into them to make decent steel. Knowing a bit about smelter designs, I decide to use a Japanese tatara furnace. I still don't have rivets, but I figure that in a few weeks I'll have enough steel to start making them. (After I make the buy-or-build-build decision on the furnace, that is. I'm not allowed to reuse the one I made for my last project of building music stands, and the commonly-used open-source design has been known to mysteriously turn iron ore into lead instead.) The rest of the bridge has yet to be tackled...

Point being: this is not a "we know enough, it's just complicated" problem. We know _almost nothing_ and our tools are appallingly primitive. To quote some classic hacker humor: "I was taught assembler / In my second year of school / It's kinda like construction work / With a toothpick for a tool." Assembler and Haskell have much more in common than a toothpick and a Caterpillar D9.

</comment></comment></comment></comment><comment><USER4> Using wiki's in two different companies provided us with these checklist like capabilities. We used MoinMoin at a prior company and now use MediaWiki, but the technology isn't the point.

Everyone contributes to the wiki and it accrues knowledge from experience. Some process documentation is carefully reviewed for accuracy, but it also left a bit free-form so as to accommodate situation specific variations from the norm.

The verification team (I dislike the term QA) encapsulates as much as possible into the testing framework, but since the wiki based descriptions are so much more rich, they remain a go to resource.

Recently I moved the IT/Networking staff to start making their project plans in the wiki. Their defect rate has plummeted to nearly zero - mostly because they are making plans! But what they've discovered is that they now have frameworks of plans (checklists) from which they can derive their next plan.

Others have mentioned Dr. Gawande and I would recommend his book [http://atulgawande.com/book/the-checklist- manifesto/](http://atulgawande.com/book/the-checklist-manifesto/)

Good discussion. Don't have an internal wiki? Start one, you'll never go back.

<comment><USER5> You can also read Gawande's original article in the New Yorker magazine that his book was based on:

[http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_...](http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande?currentPage=all)

</comment></comment><comment><USER6> My current team is the first one in my career as a software engineer in which our testing infrastructure is robust enough to think like this. I just resolved a bug this week by writing a test that failed due to its presence (and leaving a comment with the ID of the bug), changing the code, then re- running the test to ensure that it passed. This confidence in our code base is wonderful; I have never felt so little fear when deploying.

Looking back, it amazes me that I ever didn't develop software this way.

<comment><USER7> May I ask what language this code base is in?

<comment><USER8> Probably Ruby. No other language makes testing that easy or fun.

<comment><USER9> Go does. So does Rust. Both languages have some sort of unit testing facilities packaged with the standard distribution. And both are dead simple to use.

<comment><USER10> You can't mock out your dependencies as easily in Go as you can monkey patch them in Ruby.

However I've found the explicit error handling in Go to be more valuable in making reliable software than a torrent of test in Ruby, or Java.

</comment></comment></comment></comment></comment><comment><USER11> Whenever I introduce a bug that could have been caught automatically I either add the missing unit test or I add a new git hook (there is of course a hook to run unit tests). From missing license files, build failures, to just spelling mistakes in the commit message there is no reason for these to exists in the repository.

I created [https://github.com/icefox/git-hooks](https://github.com/icefox/git- hooks) to manage hooks across repositories, users, and system wide. For example if in a project I add a new hook making sure I never commit an invalid xml file, all repos that have xml files will get the hook for free.

<comment><USER12> I am loving the look of the git-books - got to try it tomorrow

</comment></comment><comment><USER13> I find the comparison of software development and surgery/flying an air plane very lacking. It restricts the term "Software" in the post title to very critical systems (OpenSSL admittedly being one of them).

The author proposes automated tests/Software "checklists" as the solution to all problems. The problem with automated tests is that they can only catch "expected" bugs. The author describes an idea for an automated test that _might_ have caught the Heartbleed bug. Big deal, now that we know all about the bug. A next unforeseen type of vulnerability will come, and no automated test will catch it.

I think the article greatly exaggerates the applicability and capabilities of automated tests (or "check lists"). I'm a big fan of all things TDD and consider myself a very rigorous programmer (surely often to the detriment of speed/pragmaticism). But I don't need a check list of the complexity of a flight check to describe the rules I use in my work.

<comment><USER14> > A next unforeseen type of vulnerability will come, and no automated test > will catch it.

But Heartbleed _wasn 't_ a new type of vulnerability. It's the same type of vulnerability we've known about at least since the dawn of C. Almost all bugs are of known types. How often do we see new types of vulnerabilities? Maybe a couple a year. If we had only a couple vulnerabilities a year across all software, we'd be many orders of magnitude better off.

<comment><USER13> Sure, I'm not saying the proposed automated test is bad. I think it might be sensible to add it. As I said, I'm 100% for automated tests (I should be, as the co-founder of a startup specializing in test automation tools). But ascribing magical capabilities to catch all future bugs to automated tests / "check lists" is IMHO detrimental to the cause because it leads to too high expectations.

<comment><USER15> They don't, and the article doesn't imply this.

A lot of stuff that gets on checklists is because not knowing about it killed someone. Other documented procedures came from time in the simulator - somewhat anagolous to manual user testing.

To be honest, the only people I know ascribing "magical capabilities" to unit testing are those disparaging it. The rest of us think it's great, and makes life a lot easier, but we've all been bitten by that unexpected bug when you see it working in the real world.

<comment><USER16> Exactly. I've always hated the "You can't test what you don't know so it's worthless." Well sorry, I can test what I do know and make sure that I don't break that. As new errors come upon, you add it to your tests (akin to checklists, essentially), and make sure you don't break that use case again.

</comment></comment></comment></comment></comment><comment><USER17> Checklists have been proven to work, but the software I write (low-level high- security/crypto software) is less repetitive than (most) surgeries. I haven't managed to use anything checklist-like while writing code; however, quickly pattern-matching against a mental library has been exceedingly useful when _reviewing_ code.

Here are some sources I would recommend to people building their own mental checklists:

\- The Art of Software Security Assessment (thanks to tptacek); I actually learnt most of this from bits 'n pieces scattered over the web, but it's a very convenient collection;

\- Common crypto flaws. Always look for authentication, _then_ encryption, _and_ replay protection. (The latter is often forgotten even in otherwise good protocols.) If a password is used anywhere, consider bruteforcing it (bcrypt may stop such attacks - or not.) Check that IVs are used as demanded by the mode (in particular, that CTR or GCM IVs are not reused.) Look for timing attacks; the easy-to-spot and high-impact ones are use of memcmp() with HMACs and use of CBC on unauthenticated data (padding oracle).

\- Buffer overflows may be bad, but integer under-/overflows are much more common (in decent code.) Basically, you need a check before any operation involving a user-supplied length, and this is very commonly forgotten. (Using functions with internal overflow checking, like a decent calloc, helps.)

\- Consider the wider context. Spotting a buffer overflow is easy. Noting that you forgot to <? include auth.php ?> is harder. You likely won't notice that the latest "cleanup" leaves the firmware updater open to the internet unless you actually spend five seconds thinking about the wider system.

(I'm quite interested in other's tips; the above is clearly _very_ slanted. Also, I feel vaguely guilty about doing all of this in memory instead of from a paper checklist - does anyone have positive or other experiences with those?)

</comment><comment><USER18> Thing is, software doesn't happen in a vacuum.

Perhaps it's worth considering that maybe the reason that checklists aren't the norm in the FOSS "meritocracy" is that they hinder progress, for a certain value of progress. Maybe there was a stealth project that could have been OpenSSL, developed with scrict adherance to checklists, but OpenSSL won because it didn't have that burden? I suspect this applies more broadly to startups, too.

Maybe checklists are a silent killer in the natural selection of the software ecosystem, and that's why so much of our software is tripping over peacock feathers?

Just a thought.

</comment><comment><USER19> I use this very frequently, helps a lot: [http://www.boxuk.com/upload/2014/02/Relaunched-Ultimate- Webs...](http://www.boxuk.com/upload/2014/02/Relaunched-Ultimate-Website- Checklist-2.0.pdf)

</comment><comment><USER20> With software this should be your test suite. No test is too simple. No feature or detail too small to test. Replace the line "relentless checklist" with "relentless testing" and you're good to go. Don't deploy before all tests are green and that's the same as not flying without running through your checklist.

I grew up flying with my dad in his Cesna 172 and admiring how well the pre- flight checklist worked. When I first heard about TDD, I immediately recognized it as the same process, except automated.

<comment><USER21> That's what I first thought. Then I realized that test suites as most people think of them would not have caught the Heartbleed bug, whereas a checklist like this would have done so.

Testing is testing, but there are different ways of thinking about it, and different ways to have it embodied. Test suites are one embodiment, and higher-level checklists can complement them.

<comment><USER20> I guess I've always thought of my integration tests as the higher-level checklist. I've only done web development, so that works. I could see how if you're writing software for something as important as OpenSSL then you might need an extra set of checks, but there's still room for human error. Seems like there should be someway to automate everything required to deploy software.

But I realize this is an idealistic approach. The reality is that a good test suite with higher-level checklists is probably more practical.

</comment></comment></comment><comment><USER22> > This can be automated! This could be mandated as a procedure to be gone > through before the code is released. And doing this would prevent this kind > of bug from ever happening again.

I might be missing something, but this sounds to me very much like a usual test case. :) Having one in a suite of system or acceptance tests would indeed prevent further occurrences of the bug.

</comment><comment><USER23> The optimist's response to "What could possibly go wrong?" is a swing for the fences. The pessimist's response is a checklist. It's seeking to avoid the worst outcomes and allowing success to come in due time. It's braking early and accelerating from the apex as opposed going full speed and breaking things fast.

<comment><USER24> This seems like a fallacy of false dilemmas. The optimist can swing harder because, thanks to professional pessimism, the bat won't crack halfway through the swing, the stands don't collapse before the ball reaches them, the ball doesn't explode on contact, and the rules for what constitutes a home run don't have to be constantly reinvented by each player individually.

<comment><USER23> Yes, we agree that the optimist's imagination limits the list of things that could possibly go wrong to the absurd. And as you suggest perhaps an optimist's optimism derives from a concept of professionalism born the love child of dunning-kruger. Or perhaps the horns are grown on a strawman dividing the world into naught but optimists and pessimists according to the law of the excluded muddle.

</comment></comment></comment><comment><USER25> I tend to use checklists for everything. It saves a lot of thinking. I would recommend Zim or other personal wiki.

</comment><comment><USER26> I think he's missing an important point. C should not be used for safety critical systems code if possible, period. A language that prevents those leaks should be employed in its place.

Checklists are good, but you need to enforce them. If such a language is used instead, these errors are impossible by design.

<comment><USER21> I think you're missing the point. Whether or not we're talking about C is a detail, what is more important is that the lessons we learn need to be encapsulated and encoded into procedures that everyone can apply and learn from.

Equivalent mistakes can be made in any language powerful enough to do real work. Off-by-one, behaving inappropriately on parameters outside those expected, lots of things can go wrong in any language. Capturing your knowledge in a form that can be used for testing is the idea, and that seems to be missing entirely from computing.

<comment><USER27> Languages _can_ eliminate large classes of such mistakes.

Taking your own two examples: most off-by-one errors go away if you replace "for (i = 0; i < datalength; i++)" with "for i in data" or something like that; and by replacing < or <= comparisons with checks for range membership. A checklist might say - "don't have assignments in your if statement conditions like 'if (x=0)', it's risky"; but your language or tools around it may make it impossible to do it.

"Behaving inappropriately on parameters outside those expected" is correlated with the frequency of getting unexpected parameters. No static typing? You'll have to check at runtime if the parameters are of the type that you expect. Null/undefined values? Again, you may remember to check everywhere or the language can force you to check _really every time_ , not almost every time. Niche languages like Eiffel can help you ensure that you _know_ that the parameters are within the expected range, etc.

Capturing such knowledge and encoding in a way suitable for everyone is done in this way - it does break backward compatibility and requires rewriting code and abandoning libraries or even languages; but the checklist equivalent of "don't ever turn on the engine before checking X, even if you think it's okay" is "don't use C strcpy ever, even if you think you know it's correct there".

</comment></comment></comment><comment><USER28> Using a system like this really helps for complicated and/or important code. All of our safety critical and embedded code references a checklist before it is made into a pull request. It really helps catch all of the "rubber ducky" bugs.

</comment><comment><USER29> This is essentially describing a "process".

Except instead of emphasizing team-level details, it calls for an emphasis on code-level details. I really like this idea.

<comment><USER24> Watts Humphreys was probably the first to the idea of scaling development processes _down_ , rather than up, arriving in the 90s at the Personal Software Process.

The PSP is very data-intensive. You're meant to log pretty much everything you do.

For example, you log your mistakes. Missed a semicolon? Log the mistake. Typo in a variable name? Log the mistake. Critical misunderstanding of how a library works? Log the mistake.

After a while you use your data to correct your common errors with ... checklists! And other tools and practices, of course, but checklists are a big part of the PSP.

It's worth reading _A Discipline for Software Engineering_ , even if you never apply it.

</comment></comment><comment><USER30> Tried to make something similar to this once:

[http://konvention.vadosware.com](http://konvention.vadosware.com)

Suffered from the false premise that people would willingly contribute en masse though...

<comment><USER11> On the main page the link for "Copy arrays with array#slice" is 404

<comment><USER30> Yeah, I haven't touched the site in what feels like forever...unfortunately, don't have the time to fill it up with information... I might return to it one day

</comment></comment></comment><comment><USER31> Isn't this what static analysis, penetration testing, and various other automated smoke tests made for? Instead of adding to a checklist these tests are updated to account for new vulnerabilities.

<comment><USER32> The checklist is about making sure you have used those tools.

This is not how I would recommend running the average startup, but for mission critical software having someone other than the author review all the code using a checklist is probably the best way to ensure quality. The author of the code would have the same checklist and would be expected to hit all the points before handing the code over to the reviewer.

</comment></comment><comment><USER33> Can anyone point to the studies done about using checklists in surgeries?

<comment><USER21> A quick Google search[0] returns these:

[http://news.bbc.co.uk/1/hi/health/7825780.stm](http://news.bbc.co.uk/1/hi/health/7825780.stm)

[http://www.nrls.npsa.nhs.uk/resources/?entryid45=59860](http://www.nrls.npsa.nhs.uk/resources/?entryid45=59860)

[http://www.who.int/patientsafety/safesurgery/ss_checklist/en...](http://www.who.int/patientsafety/safesurgery/ss_checklist/en/)

[http://www.bmj.com/content/338/bmj.b220](http://www.bmj.com/content/338/bmj.b220)

[0] [https://www.google.com/search?q=surgery+checklists](https://www.google.com/search?q=surgery+checklists)

<comment><USER34> You should probably also mention this:

[http://theincidentaleconomist.com/wordpress/when- checklists-...](http://theincidentaleconomist.com/wordpress/when-checklists- work-and-when-they-dont/)

Atul Gawande is probably the foremost proponent of surgical checklists and in that article is responding to an Ontario study reporting that checklists were not significant---it sounds like a pretty bad study.

Surgeons don't particularly like checklists.

" _For starters, the most controversial idea for teams to accept is perhaps the simplest item in the checklist. Require all team members say their names prior to the launch of the procedure.

"'This has been one of the most important things that help people feel comfortable speaking up' if they're unsure or unclear, for example, that this is the right patient, right site, right procedure.

"'It acknowledges that you're part of a team and are allowed to speak.'

"Gawande says that there has been resistance to accepting checklists at another level. 'The concept has forced us rethink what it means to be great at what we do. And I hadn't grasped this until I saw it recur over and over again. There's a set of values in the idea of a checklist, and they're in distinct conflict with some of the values we have in medicine.'

"'We value physician autonomy, which works well when there are just two full time equivalents providing care, but when we have 19.5 FTEs trying to make things work, it becomes a problem.'_"[1]

Any of that sounding familiar?

[1] [http://www.healthleadersmedia.com/page-3/QUA-262159/Gawande-...](http://www.healthleadersmedia.com/page-3/QUA-262159/Gawande- on-Checklists-Why-Dont-Hospitals-Use-Them)

<comment><USER35> Great reference. That first point relates more to Crew Resource Management (CRM)[1], an important concept making its way from aviation to surgery. After a decade flying F-18s for the Navy, I value checklists but communication is probably even more important and often overlooked. Finding the courage to speak up is more challenging then it seems. It's so easy to assume that the Captain, Surgeon, or whoever is in charge knows what they are doing. One of the worst accidents in history[2] that helped kick off CRM, could have likely been prevented if the co-pilot had assertively told the Captain that they weren't cleared for take-off.

I still remember the Navy's version and believe it's applicable to many places other than aviation.

D - decision making A - assertiveness M - mission analysis C - communication L - leadership A - adaptability / flexibility S - situational awareness

[1] [http://en.wikipedia.org/wiki/Crew_Resource_Management](http://en.wikipedia.org/wiki/Crew_Resource_Management) [2] [http://en.wikipedia.org/wiki/Tenerife_airport_disaster](http://en.wikipedia.org/wiki/Tenerife_airport_disaster)

</comment></comment></comment></comment><comment><USER36> Rather than asking more from the developers, donate more money to the project and get more developers to test the software.

</comment><comment><USER37> I think this is a great idea.

</comment><comment><USER38> Software already has checklists - using names like 'regression tests', 'automation scripts', etc.</comment>


Uber says Levandowski on his own for $180M to Google - <AUTHOR> https://www.bloomberg.com/news/articles/2020-04-18/uber-says-guilty-engineer-on-his-own-for-180-million-to-google <comment><USER2> Uber's lawyers be lawyers and try to save their client $180M dollars, Levandowski's lawyers also be lawyers and try and save their client from being totally and utterly bankrupt. It's not mentioned in the article but it's a safe bet that Google's lawyers are also being lawyers and trying to earn the company $xxM dollars by forcing Uber to pay whatever Levandowski can't afford to.

That's basically the entire contents of this article... well except for the last part which I added. I really wish journalists would actually look into the legal arguments and comment intelligently instead of just reporting one sides legal brief as if it was some form of moral argument.

<comment><USER3> >I really wish journalists would actually look into the legal arguments and comment intelligently

That's what the opinion page is for. I absolutely do not want newspaper journalists making commentary on legal briefs.

<comment><USER2> Intelligent commentary doesn't have to be opinion, it can be bringing in the relevant facts.

What court is this in front of? What documents publicly exist (hint: lots of them) and where can we find them? What rulings has the judge already made? What legal standards have been cited by the parties? What precedent has been cited by the parties? What are the relevant past rulings in the related cases? When can we expect further development.

Instead they've just cited some sound bytes from a few lawyers in a way that doesn't even acknowledge that there is a justice system that this is working its way through.

Not to mention this isn't really news... it _belongs_ in the opinion section. Right now it's basically just repeating the opinions of Uber's lawyers instead of the opinions of the journalist (except for a small portion where they repeat the opinions of Levandowski's lawyers).

<comment><USER4> It is generally beyond the scope of an article like this to provide a full case history.

If you want something like that there are professional journals that provide in depth legal reporting.

<comment><USER2> This comment... is really a reply to my top comment not the comment you replied to. Whether or not this is in scope has nothing to do with the discussion of whether or not the report could comment more intelligently without making it an opinion piece.

A large part of the the point in my top comment could be phrased as "the scope of this article is so small as to be entirely pointless".

</comment></comment></comment></comment></comment><comment><USER5> I dislike Uber as a company, I'm still not over susan fowler and the way they skirt the law in most municipalities is definitely criminal.

However, I have to agree with Uber here.

I work on video games, if I bring some engine code from my current employer to a new employer that's theft. Anything I made on company time or with company resources is not mine to take. However taking learnings is totally fine (because: of course it is) and that factors into things because it's experience.

If he did this without Uber knowing then he's alone. If Uber knew he might do it or promoted this behaviour then that vindicates my feelings towards them and they definitely should be punished as hard as the law allows.

"Take nothing but memories" applies to more than just nature.

<comment><USER6> [https://arstechnica.com/cars/2020/04/levandowski-says- uber-m...](https://arstechnica.com/cars/2020/04/levandowski-says-uber-must- pay-his-179-million-judgment-to-google/)

 _Levandowski claims that Uber was fully aware of the circumstances of Levandowski 's 2016 departure from Google.... Levandwoski says he cooperated fully, giving investigators access to his email accounts and personal files....

Kalanick wasn't concerned. "Uber eats injunctions for breakfast," he allegedly told Levandowski....

Uber's acquisition terms for Otto included a sweeping indemnification commitment for Otto employees, including Levandowski.... Levandowski says Uber specifically promised to protect Levandowski if he was accused of misappropriation of trade secrets or breach of loyalty to a former employer - two of the key accusations Google later leveled against Levandowski. The indemnification clause said that Uber would pay any expenses arising out of a lawsuit from a former employer, including damages._

<comment><USER7> Unclear without additional details. What did Levandowski tell Kalanick?

"Travis, I'm sure if you acquire me, Google will claim non-compete, trade secret theft, and all that. Will your legal department cover me?"

\--or--

"Travis, I'm going to steal trade secrets from Google and bring them with me. When Google finds out, will your legal department cover me?"

<comment><USER6> Yeah, I know. That's why I posted it. It's a response to a comment that couldn't see how Uber could possibly be on the hook.

</comment></comment></comment></comment><comment><USER8> Quote:

"[Levandowski] agreed to plead guilty to trade-secret theft and was driven into bankruptcy when Google won a contract-breach arbitration case against him -- he was counting on Uber's promise when it first hired him to provide legal cover, known as indemnification, from his former employer.

Uber now says it has no obligation to reimburse Levandowski for the $180 million."

</comment><comment><USER9> Reposting an old comment on Levan's lawyers thoughts:

> A friend of mine heard his personal attorney speak at a law school class. > Even his attorney thought Anthony was a "jackass" for stealing the IP; his > defense fell on him being an engineer who, at the end of the day, just > wanted to build cool shit and wasn't malicious.

<comment><USER10> Sounds like an egregious breach of attorney client privilege if true.

<comment><USER11> A lawyer's own opinion shouldn't be privileged although it's probably unprofessional to share it for other reasons.

</comment></comment></comment><comment><USER12> Wait, the then ceo Travis Kalanick was in on this wasn't he?

<comment><USER13> What are you suggesting? Corporations exist to shield the owners from the company's liabilities to a limited extent.

<comment><USER14> Legally, to encourage taking inevitable risks needed to run a business. Not to shield greedy sociopaths from the social consequences of their unethical decisions.

</comment></comment></comment><comment><USER15> One of the reasons why I'm careful to get involved with trillion dollar companies. A job there may be gainful and prestigeful, but getting stomped into the mud by an army of ill willing lawyers with infinitely deep pockets over any sort of workplace invention issue is bound to be a road to ruin.

<comment><USER16> That can happen when you willfully steal trade secrets.

<comment><USER17> I think different people have different moral intuitions regarding that. Some might consider that trying to keep trade secrets is a zero-sum or maybe even a negative sum game, from the perspective of society.

Assuming you don't identify with Uber or Google, you might not assign any monetary value to this episode, and therefore there could be cognitive dissonance at the weight of "$180 million" and actions taken proportional to that.

<comment><USER18> You can still imagine to do all this research Google paid upwards of $180M to it's employees.

</comment></comment></comment></comment><comment><USER19> [https://archive.md/lUvyt](https://archive.md/lUvyt)

</comment><comment><USER20> That seems fair, given that they know that he got $120 million when he left Google.</comment>


Vampire Porn: a cautionary tale of a single, monopolistic owner - <AUTHOR> http://www.slate.com/articles/technology/technology/2014/10/mindgeek_porn_monopoly_its_dominance_is_a_cautionary_tale_for_other_industries.html

<comment><USER2> To be fair, websites are distributors of physical goods because it's so, incredibly easy to type another URL or for that matter search for other sources.

Monopolies in physical goods or even operating systems (per the late 90s) are quite different; the analogy doesn't fit well.</comment>


Zeno scrolling - <AUTHOR> https://https.www.google.com.tedunangst.com/flak/post/zeno-scrolling <comment><USER2> I never scroll past 3 pages. It's always such an _effort_ to browse an infinite scrolling page. When surfing, they often interrupt a browsing session and demand more attention than other pages. They are a dark pattern[1]

[1] [https://en.wikipedia.org/wiki/Dark_pattern](https://en.wikipedia.org/wiki/Dark_pattern)</comment>


Mazda, Suzuki, Yamaha Motor apologize for improper vehicle tests - <AUTHOR> https://www.reuters.com/article/us-mazda-suzuki-motor-emissions/mazda-suzuki-yamaha-motor-cheated-on-fuel-economy-emissions-testing-japan-government-idUSKBN1KU023 <comment><USER2> Now if you could just get Mazda to apologize for the CVT transmissions they've made for the past 25 years.</comment>


Dingo – An opensource Trello clone in Laravel - <AUTHOR> https://github.com/zeeshanu/dingo-project-managment <comment><USER2> If it meets the guidelines, this might make a good "Show HN".

Guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)</comment>


She tried 960 times - <AUTHOR> http://www.nytimes.com/2010/09/04/world/asia/04driver.html?_r=1&ref=world <comment><USER2> To me, this is an extremely sad story about the way we treat knowledge and learning. How absurd is it to cheer for someone that memorizes questions and answers without having contextual knowledge about the actual meaning behind those questions? It's not dedication, it's thick-headed stubbornness.

The lady has been at it for about five years now. If she did it the right way, she could have _learned to learn_ , then learned to read and write, and then passed the exam, plus come out with other valuable skills. Doesn't this remind you of those college graduates that go through the motions, but when they sit down and are asked to do something on their own simply fail to even understand what they're asked? I remember back in college I would sometimes participate in study groups, and so often encounter students that relied simply on memorizing problem types and the ways to solve them without actually having any clue about what they were doing. It seemed more common with students hailing from asia, and surely had something to do with the way school and knowledge is treated there.

<comment><USER3> She's 60+ years old and has been selling vegetables and working on farms most of her life. She doesn't remind me of college students or graduates at all.

For her, learning how to learn is probably much more difficult than you think it is.

<comment><USER4> Well its not so much that learning to learn is more difficult, but learning to learn in a given domain. If you don't have someone to teach you, figuring out the ideal way to learn something can be tricky.

For example, the Rubiks Cube. I'm sure there are great ways to learn to solve this puzzle, but I learned using a very time consuming technique with a lot of failure. While I have a really good schema for book learning, I have a relatively poor schema for learning the optimal way to manipulate items in 3space, despite the fact that I live that space.

<comment><USER5> Learning to solve the puzzle would mean that you learned how to solve it without memorizing a technique.

There is a big difference between actually solving the cube and learning how to 'solve' it using some technique someone else came up with.

Solving it means that you analyzed the workings of the cube, figured out a way to return it to its original state without access to some outside source of information on how to do it.

Screwdrivers probably shouldn't count as a 'solution' in this sense ;)

</comment></comment></comment></comment><comment><USER6> > "Sajeonogi," or "Knocked down four times, rising up five."

Is Korean really that much more efficient than English, or is that word a label?

The instructors started to teach her after 949 tries - 949 tries, of watching this poor woman fail! - then she did learn, and got it on the 11th try after that. Teaching her was frustrating to them, I think mainly because they weren't really teaching her about driving, but a subset of civil administration and technology concepts, such as "regulations" and "emergency light".

The tragedy is that she could not afford "Middle school", despite dreaming of it so painfully that taking the driving test daily became a joyous wish fulfillment of attending school... an attitude of which the stereotypical student is too invisibly wealthy to properly conceive.

<comment><USER7> > > "Sajeonogi," or "Knocked down four times, rising up five."

> Is Korean really that much more efficient than English, or is that word a > label?

No, it's a 사자성어 (sajasongoh), or 4 character idiom. They originally come from Chinese, in which they're called chéngyǔ (成语 or 成語, in simplified and traditional characters, respectively), meaning "set phrase", and also exist in Japanese, in which they're called 四字熟語 (yojijukugo, literally "four character Chinese idiom").

Because of their origin in classical Chinese and their brevity, they're impossible to understand unless they're explained to you. In Asian countries, memorizing/understanding these proverbs is a big part of schooling.

I don't know the details of this particular sajasongoh, but I'm guessing that it either comes from classical Chinese or is a modified version of one that does. Modifying these proverbs to fit a particular situation is a common form of wordplay in Chinese, Japanese, and Korean. For example, the Chosun Ilbo (a big Korean newspaper) loves doing this in their headlines.

<comment><USER8> so it's like Brangelina

<comment><USER9> More like acronyms, I'd say. For example, "HTTP" = hyper-text transfer protocol.

It's funny that the word 사자성어 (meaning: 4-character idiom) is itself a 4-character idiom. East Asians like 4-character groups so much, they even read numbers in groups of 4 digits. For example, 1,234,567,890 would be read 12 억 3456 만 7890.

<comment><USER10> I doubt they like it. 4 is considered unlucky in East Asia. Elevators always read 1->2->3->5->...

<http://en.wikipedia.org/wiki/Tetraphobia>

<comment><USER11> Although 4 is considered unlucky in Chinese, decimal numbers is represented in 4-number groups, instead of 60 thousand, we'd have 6 wan, 800 million would be 8 yi, etc

</comment></comment></comment></comment></comment></comment><comment><USER12> It's probably a webdesigner-thing to think of 960 as a nice round number, but that's the first thing I thought upon reading that.

<comment><USER13> I confess: I thought "960 Times" was a newspaper fixed width stylesheet template of some sort at first.

<comment><USER14> Haha, I was thinking exactly the same thing :) Professional handicap I guess.

</comment></comment></comment><comment><USER15> This is quite possibly the most inspiring story of human tenacity and sheer grit I've heard in quite a while. It really made me smile.

Clearly her method was not optimal but it... eventually worked for her. Just goes to show that perseverance pays off even when starting from absolute zero.

Good for Cha Sa-soon!

<comment><USER16> And she got a free car out of it:

 _In early August, Hyundai presented Ms. Cha with a $16,800 car.

Ms. Cha, whose name, coincidentally enough, is Korean for "vehicle," now also appears on a prime-time television commercial for Hyundai._

Go Grandma!

</comment></comment><comment><USER17> She tried the WRITTEN test 960 times.

She passed the driving test in 4 tries which is probably like the average american teenager these days.

At $5 a pop though, she could have hired some personal tutors.

</comment><comment><USER18> Either this is a common occurrence in South Korea or the media keeps recycling this story, I first read about this on Sept 6, 2009 and then again on May 7, 2010.

[http://www.huffingtonpost.com/2009/11/06/cha-sasoon- skorean-...](http://www.huffingtonpost.com/2009/11/06/cha-sasoon-skorean- woman-_n_349290.html)

</comment><comment><USER19> Perhaps she didn't realize that she could study for the test and then pass it after one try. According to the article she has almost no formal education, so that seems possible: "It was not until she turned 15 that she joined a formal school as a fourth grader. But her schooling ended there a few years later."

<comment><USER19> I spoke too soon. On the second page, the article says she did study, but did so "phonetically" and thus didn't understand what she was studying.

<comment><USER13> This reminds me of something: I saw a documentary about championship Scrabble players and a lot of them aren't English speakers or even Latin alphabet language speakers. They treat Scrabble as a visual pattern game rather than a verbal one.

<comment><USER20> Pretty much been my experience playing. It's more about memorizing lists of words without really bothering to know what they mean and figuring out which words to use when and how to place them to maximize your point total on each play.

<comment><USER13> I mean no offense by this but.. is English your mother tongue?

I used to play Scrabble a ton and adopted a more verbal, etymological style that, I'd assumed, would be more common amongst native English speakers (but maybe not!)

<comment><USER20> It is, but my primary strategy has been to commit a huge list of words to memory, especially the two-letter words to join new words together for point efficiency.

</comment></comment></comment></comment></comment></comment><comment><USER21> To me, this is less about the fact a single woman had to memorise a written driving test by failing it 949 times, and more about the mismatch between the test itself and the populace.

Surely she is fairly indicative of a rural inhabitant? Why is the test so inaccessible, and how many others are there like her?

<comment><USER22> >Why is the test so inaccessible, and how many others are there like her?

The test should ensure that a driver can read read and understand street signs both symbolic and textual ones and respond correctly ... oh yeah, and drive the relevant vehicle. They should also be able to service the car sufficiently to keep it safe - pump tyres, check fluids, know mostly when it needs attention from a mechanic.

Not everyone can do all these things hence the test appears "inaccessible".

</comment></comment><comment><USER23> I wonder what are the odds of passing the written test with random answers. I assume it's multiple choice.

<comment><USER24> Here's what we know from the article: (1) 40 question test, (2) Multiple choice, (3) She passed it with "60 out of 100"

My assumptions: (1) It's graded on a simple "percentage right" basis, so 24/40 questions necessary right to pass, (2) 4 options for each question

Her score on an individual test is a random variable X following a binomial distribution with 40 trials and chance of 0.25 for each trial. Her chance of passing by guessing randomly, P(X >= 24), is an infinitesimally small 2.826E-6.

The probability that she fails all of the 960 tests, assuming independence of tests, is (1-p)^960. So the probability that she will pass at least one test is:

      1 - (1 - p)^960

Plugging in p = 2.826E-6, the chance is still practically 0, so a naive guessing strategy would not work.

However, under the above assumptions, she could practically guarantee her success by combining this guessing strategy with a simple test-taking strategy like eliminating 1 or 2 obviously wrong answers per question, or just remembering the answers to several of the same questions that are probably being recycled from test to test.

<comment><USER25> _just remembering the answers to several of the same questions that are probably being recycled from test to test._

I assumed this is how she did it, but assuming all questions are recycled, 4 options in 40 questions, perfect memory, no knowledge, and a naïve strategy, she should have passed in just 29 tries (1.75 retries per question, 10 initially right, 24 needed). Mastermind isn't _that_ hard a game. So clearly, some assumptions are wrong.

<comment><USER26> Change your assumptions to assume a larger set of questions, not 40.

</comment></comment></comment></comment><comment><USER27> The test givers must be quiet stubborn to, can't imagine something like that ever happening here for some kind of similar test, she would just get passed or turned away in the first 10.

Interesting question is that now that she got 60/100 does she understand things much better than 3 years ago, some form of understanding would spike the scores quickly, while the slow improvement can only seem to be the result of slightly better memorisation of question->answer each time without much better understanding.

</comment><comment><USER28> _Off-Topic: Most stories... they'd cover on TV news [or newspapers], [are] probably off-topic._ A story that man bites dog I think would be in this category.

 _On-Topic: Anything that good hackers would find interesting. That includes... anything that gratifies one's intellectual curiosity._

That she took the test 960 times is interesting to know, but hardly gratifying.

</comment><comment><USER29> Sadly, all she got was a drivers license. It's not like she hit success with her startup after 960 tries and became a happy member of the fym club.

<comment><USER30> She was a poor rural villager. She got the right to drive _and a free $16,000 car_. Its like getting magic powers and a king's ransom. I'd wager her life changed more for the better as a result of these events than most of ours would if we did get that big fym exit.

In her world, she joined indeed.

<comment><USER31> Well, after deducting 960 * $5 fee ~= $5k, plus 960 * unknown bus fee (let's assume it's rounds to $1k), it's more like a $10k car. Also, this car is given to her, so her value for the car may not be $16k (imagine she's given $16k towards the purchase of any car, she'll probably ended up with a different car). Finally, not sure of tax laws in Korean, so she may have to pay taxes on it before the $6k fee deductions. She still comes out ahead, but probably close to half of $16k value.

But her fame from the story is priceless.</comment></comment></comment>


The US Director of National Intelligence Perjured Himself.  Do We Care? - <AUTHOR> https://www.truthmapping.com/map/1404/

<comment><USER2> yes we do.

but like most people who are enraged by the lack of accountability at the top, i feel powerless to do anything about it. except maybe bitch about it on sites like hn, but what good does that do... other than to get you flagged as a rabble rouser or banished from sight/site.

i looked at the map but before i start agreeing and critiquing, what are we supposed to be doing here. sure i understand the endpoint, but it feels out of context. i'm not sure how to use or follow it? can you give us a walk though?</comment>


News app code and search - <AUTHOR>

I was wondering if YC can/has released the source code for this wonderful social news app. I love its lightweight and simplistic approach.
Also, a search feature will improve things a lot.
Keep up the good work! <comment><USER2> whats so bad about table layouts?

</comment><comment><USER2> i love it too</comment>