My favorite liar (2009) | Hacker News Reader

My favorite liar (2009)

zenmoments.org

148 pointsbelter33 comments

I have too many colleagues who rubber-stamp my pull requests. I'm tempted to include a significant mistake in each one to see who's paying attention. Unfortunately I have done so too many times by mistake with nobody noticing. Maybe if we gamify it a bit and start keeping score. I don't have authority to make a bonus contingent on the result, but it could be money well spent.

I prefer the people who only comment when they have something useful to say. Either way the responsibility for the correctness is with the code author, not the reviewer. Writing whatever and hoping for your coworkers to correct it is equivalent to asking them to do your job.

Disagree. Finding those mistakes is the whole point. When I miss one in someone else's PR, the resulting problems are my fault.

I can never claim I can find all the bugs, I’m not even that smart. Thus I can comment on style, overall compatibility with existing mechanisms. Ask/remind which tests were run.

Trivial stuff is easy to catch, refactoring parts I’m familiar might help with pitfalls known to me.

Still I can’t see how one can claim finding all bugs is possible.

They're not your fault, they're at most your responsibility. You should be paid triple what your coworkers earn if you're willing to accept fault for what they produce.

Are you perhaps a team manager and insisting that all your team PR's go through you? Might I suggest that instead of signing off on all PR's yourself, setting up a good testing framework may help you sleep better at night?

In my experience there is a scale of how thorough the review can be. The scale is continuous, but most reviews fall into one of three buckets: informational "hey this is what I am doing", light guidance "hey can you check out broad outlines without getting bogged down in details", and coauthors aka "one person writes the code, but all are responsible for the outcome".

Generally the bucket review falls in depends on code criticality, code simplicity, company culture, how much reviewer cares about the code you are changing, how much reviewer cares about you/your changes (mentorship etc.), and how tired / overwhelmed the reviewer is. It follows, that assigning reviewers that care about the code/author and not reviewing code while tired tends to produce higher quality reviews.

In the end author, reviewer, and thoroughness of the review is an engineering call. Both author and reviewers should be able to understand where they are on the scale and be able to substantiate why.

Always assumed the way the loop and game should be played was:

Assuming Developers A,B,C,D of somewhat similar experience and expertise. For one month, randomly assign Developer A,B for example, as committers and C and D as reviewers:

1) Developers A and B create code and submit pull requests.

2) Developers C and D are randomly assigned as reviewers.

3) IF there is a future bug, on code that passed the review, its not up to A or B to fix it. One of the originals reviewers, ( ex C or D) are randomly assign to fix the reviewed code. NOT the original Developer.

4) Developers A and B while as committers, get a value metric on how much code passes reviews and gets committed to production.

5) As no Developer A, B, C,or D ever wants to have to fix the code of somebody else...Reviews are very thorough.

6) Next month... A and B are on the reviewers team and C and D on the committers.

Nice one! I heard/read a similar story where in some math exams the teachers provided “faulty” calculators to all students in order to see which students relied to the result of the calculator screen and which of them used their logic and common knowledge to understand when a result is wrong. The calculators didn’t produce errors obvious like 1+1=3 but more like 22/7=3. Nice tactic and highly educational lesson :-)

You might as well ask them to do the exam on a cliffs edge, or with a gun pointed at them. Fucking with students during an event that can have huge long term consequences for their future is shamefully cruel, if you ask me.

The shamefully cruel part is that some random exam can have long term consequences.

Well, I don't agree with messing with people in stressful situations, but at this point we are better controlling the consequences of those exams.

You need to measure learning, you can't make exams trivial. If the consequences are that large, they will always be problematic.

Frankly, even a working calculator can induce the same problem. My school allowed calculators with a “solve” function to be used on calculus tests, and a staggering number of people would directly transcribe whatever output it gave, regardless of how nonsensical. “NaN” was a favorite.

'so lets start with the efficient market..'

All models are wrong, but some are useful.

I agree. I think efficient market is a great zeroth (or even first) approximation, with obvious and rather narrow limitations. Unfortunately too much is build upon this approximation.

The overall idea seems quite fun, but I'd be cautious about the lecture where he doesn't actually lie. Although the author seems to have taken it quite well, it could easily have come off as a cheap trick to other students and reduced motivation to find future lies. One of those kinds of lectures might work, but much more might not.

Although on the other hand I do remember hearing something along the lines of inconsistent rewards having a stronger incentive effect than consistent rewards, so maybe not?

I recall seeing this anecdote on Slashdot a decade or better ago.

Possibly the same author, or, given the 'zen' in the site name, it is a koan?

Zen is extremely misunderstood in the west. Mostly because what we understand of it comes from a conman and his followers who appropriated it a la scientology/mormonism.

Therefore, the default assumption when seeing 'zen' mentioned is that it's the bogus religion version.

That's interesting, what was his name and where can I read more about it?

If most of what we know of Zen in the West was disseminated by him and his followers, that points to DT Suzuki. I'm not aware that he was a con-man, although he appears to have had some pretty distasteful opinions.

This may be a leak of the pet theory of /r/zen that Dogen, the founder of Soto Zen, was a fraud and that Zen is somehow not Buddhism. I haven't seen this theory taken seriously anywhere else.

Calling it a 'pet theory' is extremely disingenuous. Of course every scientologist will 'not take seriously' claims that their founder was a conman, because to do so is to admit their beliefs are based on falsehoods. It's a self reinforcing system.

Isn’t it a lie to to invite folks to a lecture where it’s understood that you will lie, only to tell the truth instead?

I'd consider it a type error: he's declaring Lie<T> but providing Lie<Lie<T>>.

Can you draw the truth table of this lie about lying?

Is it a Type 3 error, specifically? I’m not great at coding, but I’m learning with your help!

I’m only half-joking. I have only rudimentary formal logic education, or else I would myself. :P

https://en.wikipedia.org/wiki/Truth_table

What I was trying to get at is that it was agreed that he would lie in a certain context, but he instead lied in a different context that wasn't part of the agreement.

If you buy tickets for a magic show, it's agreed that you will be tricked. But if the trick is that there is no show and they're simply scamming you out of your money, that wouldn't generally be considered acceptable. The show itself and buying tickets for the show are different contexts.

Similarly, a box of cookies is not same thing as a box of boxes of cookies. The contents of the outer box in the latter case wouldn't be very tasty.

> If you buy tickets for a magic show, it's agreed that you will be tricked. But if the trick is that there is no show and they're simply scamming you out of your money, that wouldn't generally be considered acceptable.

This is a great explanation. I was immediately reminded of Joker’s “magic trick” with a pencil during his interrogation in The Dark Knight.

https://youtube.com/watch?v=L3oOldViIgY

Of course, this was all key to the crew of the Enterprise escaping the evil clutches of Harry Mudd.

That’s a deep cut. I need to watch Enterprise all the way through.

The strategy used here is called something like "volitional obstacle" and is a known learning strategy.

> “Ah ha! Each of you has one falsehood in your lecture notes.”

Wouldn't that itself be the lie for that lecture?

The lecture had ended, so no.

Oh I see. I guess it depends on what you call the lecture—that class session, or the academic material taught on that day.

Reply on news.ycombinator.com