Yeah, I've definitely found that nobody reads more than maybe 10 words of the PR description.

I've also never seen anybody but myself write substantial PR descriptions at my previous 4-5 jobs

But if nobody writes them, they don't have the habit of reading them either.

However, also make sure your PR descriptions are not "substantial" in the "there is a lot of it" sense, but only "substantial" in the "everything of substance is described, but not more" sense :)

I've often thought this could work if the code reviewer was full-time, but rotated regularly. Just like a lot of jobs do with on-call weeks, or weeks spent as release manager - like if you have 10 engineers, and once every ten weeks it's your turn to be on call.

That would definitely solve the "code reviewer loses touch with reality" issue.

Whether it would be a net reduction in disruption, I don't know.

Doing code review as described (actually diving deep, testing etc) for 10 engineers producing code is likely not going to be feasible unless they are really slow.

In general, back in 2000s, a team I was on employed a simple rule to ensure reviews happen in a timely manner: once you ask for a review, you have an obligation to do 2 reviews (as we required 2 approvals on every change).

The biggest problem was when there wasn't stuff to review, so you carried "debt" over, and some never repaid it. But with a team of 15-30 people, it worked surprisingly well: no interrupts, quick response times.

It did require writing good change descriptions along with testing instructions. We also introduced diff size limits to encourage iterative development and small context when reviewing (as obviously not all 15-30 people had same deep knowledge of all the areas).

You could do some interesting layering strategies if you made it half time, for two people. Or maybe some staggered approach: each person does half time, full time, then half time again, with there people going through the sequence at a time. Make each commit require two sign-offs, and you could get a lot of review and maybe even induce some cooperation…

"Interesting" is the word I would use as well, but also cumbersome and complicated.

    Those damn plebs just have no idea what's best for them.

Most people are not an expert in a single field, much less multiple fields, and never every field.

So yes, we need experts to play a substantial role in running things.

Perhaps even more importantly: it's not solely about what's best for every individual. You know what would be best for me? If the government gave me a free giant SUV that gets 4mpg fuel economy, and also let me drive as fast as I wanted while also subsidizing 90% of my fuel costs. Also it should drive itself so I can sleep while driving.

Sometimes we need to consider what's best for society and the planet, too.

France tried something clever pre-covid.

You can read about it here: https://en.wikipedia.org/wiki/Citizens_Convention_for_Climat...

Totally random people could draft new laws on climate (at least, they were told this). They met with lobbyists, both pro-oil and pro-climate for two weekends, experts on three other weekends, once in a conference-style where very generic stuff is said, two other in focus groups with more specific expertises, depending on the subject the focus group is on.

Experts were real experts though, with multiple publications and PhDs (or in some cases, engineering degrees, especially during the conference week), and tried to only talk on their subject matter.

In around 8 weekend, the 150 random people made ?148? law propositions, helped by lawyers, and most experts agree that they were both good and reasonable. What's interesting is that most of the 150 people said that before really learning about the subject, they would never have made this kind of propositions.

All that to say: experts don't have to run things, and imho, they should not. They should however have an advisory role to the random people drafting new laws.

I agree completely. I think the main difference is that it's important for your average people to become educated on topics by experts. Thats the part that is missing today.

I don't think the author was presenting it like some kind of "new to the world" discovery. It was just something they recently learned.

I'm confused by the responses to this document, as if developers were expected to memorize it or consult it after every line of code.

The obvious expectation here is that these rules would be incorporated into some kind of automated linting tool.

I really need to get the fuck out of this industry.

    In this case, a 141 page highly dense (and frankly 
    boring to read) document is in its essence a liability

So, do you think that the intent was for developers to memorize this document?

Or do you think the expectation was something more reasonable, like using this document as a tool to configure linting tools so that developers could get realtime feedback as they code?

No, that is not what I mean. The efficiency of a piece of knowledge is not only a function of its intrinsic value, but also how easy it is to understand. Sure, the people who are expected to read the document are smart and this is probably the best way to do it, but even Lockheed engineers are fallible.

If anything, the enemy will be defeated before they have had the time to understand the document in case it gets leaked xD

The big problem for me is using FaceID in bed. Unless you sleep on your back, the pillow obscures your face.

All you typically need to do is lift your head up so FaceID can get a clear look... but when I'm sleepy, it's annoying.

Ideally, the phone would just have both... somehow... but this seems technically infeasible so I get it

I find both of them equally (un)reliable. I feel like they both work(ed) about 80% of the time.

The most annoying failure case for FaceID for me is using it in bed. I'm a side sleeper so half of my face is mushed into the pillow. I realize how lazy this sounds, but when I'm half asleep... that is exactly when I don't feel like tapping out a PIN or repositioning my head.

    A fingerprint reader inside the powerbutton 
    is the way to go IMO

I really wish the phone had both methods, TBH.

I love the "reader inside the powerbutton" idea, but... phone cases....

Yea, the faceid in the bed thing is very annoying when using my "tinker iphone" in the bed. Havent found Fingerprint auth unreliable, but my hands and phone mostly stay very clean and i have my finger added 2-3 times for faster and more reliable scans.

My phone has the fingerprint reader in the power button, all cases just leave the powerbutton open.

The Apple Watch knows that it's you, or at least somebody that knows your PIN.

It's tied to your iPhone and Apple account during initial setup.

Each time you put the Apple Watch on, you have to enter your PIN to unlock it. It can only perform automatic unlocking of your Mac and iPhone in this unlocked state.

The watch does automatic wrist detection and it will automatically RE-lock itself as soon as you take it off.

This is reasonably secure for most needs, though of course you can disable all of this automatic unlocking if you want more security. I forget if it's on by default or not. IIRC I had to enable it but I'm not too sure.

TouchID is biometric so these are not equivalent authentication methods.

As a watch user i will also say that the Bluetooth wake is unreliable enough to make this a poor replacement. Frustrating, even.

I'm not sure that "PIN + hardware dongle that requires continuous skin contact" is meaningfully less secure than a fingerprint sensor, but at least Apple puts you in the driver's seat to choose the level you're most comfortable with.

I've found the Bluetooth connectivity quite reliable. When it doesn't work, it's because the watch re-locked itself.

I do not think the initial decision-making process was "hey, screw working-class people... let's have a 120GB install size on PC."

My best recollection is that the PC install size was a lot more reasonable at launch. It just crept up over time as they added more content over the last ~2 years.

Should they have addressed this problem sooner? Yes.