Agree in principle. Nice article - I like the idea of designing code (or looking at code) with the perspective of how it gets parsed by a human mind. Great co

Agree in principle. Nice article - I like the idea of designing code (or looking at code) with the perspective of how it gets parsed by a human mind. Great code _looks_ super simple, effortless, until you try to write something similar to it and realise that there is a lot of effort in factoring it to be that simple. That said - I don't think minimising object members are the main point of attack. I don't find the number of _members_ to be that taxing to working memory. It seems to be naturally chunked: the members I'm working with and everything else. I don't need to keep all the members in mind. It's like stuff in a drawer - it's in one file so I can rummage to find the bits I need and keep them "in hand", going a small factor over the working memory limit is fine. (I'm not saying there isn't a retrieval cost, more members increase retrieval cost, potential confusion, etc. etc.) What seems to be a lot more taxing is keeping reference to relationships to other objects. Stuff NOT in the current file. Having to keep the relationships between a number of other objects/classes in mind is more taxing, because those need to be in working memory - and putting them there either means they are in long term memory (e.g. with a known codebase or library), or parsing it out by navigating through the codebase, tracing the relationships and understanding the intents. Ironically super-factored code can be a lot of effort to "get" at first, while intermediate quality code reads pretty easily. I find my mental map of a nicely factored object is more tied to it's intent/purpose or "meaning" rather than just the raw number of its members. Your PerfEvent example I'd parse it the same way, though.