Exception i encountered recently was needing ternary state boolean. a set of flags where true and false indicates outcome and undefined indicates "not yet processed". I suppose some sort of 0 timestamp could work but... No, I think I'll stick with boolean.
As a human being he wasn't perfect, but I come back to images from his film in my head time and time again and they help me look up from my work and consider bigger things on an ongoing basis. His films create space in my head which I go to for help when I need it most.
One of the hard things to get right when writing one of these "Tips for being a great X" is that they're usually written from the point of view of someone who is a clear leader in their field.
With some exceptions, the people who write this sort of article have the confidence (or presumption) to see themselves as ahead of the pack. It is rare to see articles like this written by teams of people who, in cooperation, balance tasks like product management, architecture, engineering, operations and customer success between them. And yet that is, imo, the best way to do it.
When I read and article like this advising the reader to do X to "their team" (in this case let your team get on with work), it falls into this category where the "how to be a great X" applies to a particular structure - where "X" is somehow in control of the rest of the team, rather than an equal participant.
Is there any indication that the numbering change reflects a significant technical shift (eg preparing to target ARM specifically)? Or is this just aesthetics?