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.
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.
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.
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.
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?
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.
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.
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.
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?
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.
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.
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.
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.
