MiyamotoAkira

That's interesting. Whenever I have an issue with a flag it gets picked up on dev/test/uat environments (all gets tested, especially around the code behaving the same as before with the flag off). The code change never reaches production. And if for some reason the code under the flag is wrong, and it has reached production (something unexpected, unseen), undoing the change is whatever long it takes to switch the flag back (and the cache to update if you have a cache).

Regarding checklist people like Hollnagel, Wears, Braithwaite, Dekker, ... have done a bit on investigation (Hollnagel mostly on Healthcare, Dekker started on air industry but spread from there). Read the "Safety-I vs Safety-II" paper or the "When a checklist is not enough: How to improve them and what else is needed" paper

I've used quite extensively Pair Programming, and at its best is better when both people tend to be senior, as you can bounce design ideas out of each other much easier, and is more likely that a bad decision (or test, or ...) gets caught earlier.

With junior devs is too easy to become something in which the senior dominates the conversation.

Going from nothing to some quality control is always an improvement. The point being made is that is not as good as other options.

After having used both PRs and Pair programming with a strong CI setup I found the later much better for quality, design and efficiency.

Pascal had indexes starting at 1 too.

Starting indexes at 0 makes sense when you want to enable the developer to manipulate memory (for example, C)

Indexes starting at 1 matches with a more natural ordinal sequencing.

Bulk, for a mail delivery company, refers exclusively to volume. You get discount on volume. Creating massive volumes of customized mails has been trivial for years.

GDPR is the best thing since sliced bread

done today on python

someMock = SomeMock()

Also, inconsistency. The example that they put is SHOWLN and showln, and they use all over the place showln, but then they write ReadLN. Driving me cranky :-)

Not case sensitive.

> This might be unusual but I would prefer to read someone's mental model of how the code works than the code itself.

The hypothesis under Peter Naur's (the N on BNF) "Programming as Theory Building" paper is that transmitting (by talking) the mental model is far more important than other format of documentation to understand a system.

> as a code-input robot while developers around him bark commands at him is actually productive.

Nothing to do with mob/ensemble programming. At the end, is a discussion that a) make code easy to understand b) create shared knowledge c) avoid unnecessary work.

> Sounds like you would just have people breaking `master` constantly to me. And how do you do code review? Or don't you?

Pair and Ensemble programming

I love TBD. But it has its places. For mobile apps I've used (and would use) release branches. You have a hard requirement on the way that app stores work.

You can still do TBD for most of the development of new features, though.