Just because it doesn’t look like this has been mentioned already. I’m not sure that the time it takes to process and recognize a character in milliseconds is t

Just because it doesn’t look like this has been mentioned already. I’m not sure that the time it takes to process and recognize a character in milliseconds is the primary bottleneck to understanding code. It is merely assumption, but I assume that code comprehension is far more difficult and slower for most than standard reading. There can be a significant mental burden when working out all of the fine details of how the code will operate, especially if written by someone else. It can be even more difficult when the code isn’t intention revealing. On another note, there are the often cited user studies that show that interfaces that are purely more aesthetically pleasing tend to be used more efficiently vs the exact same interfaces with “uglier” presentation. So a color scheme that is most aesthetically pleasing to each user might provide a subconscious boost in wielding their editor and its features. As a third and less related thought, I think we could make much bigger strides in understanding code by creating better tools, better static analysis, better IDEs, etcetera. This is just my opinion but I would guess that additional tooling to help you discover and analyze the behavior, relationships, and history of the code you’re reading could yield better results than the 15ms character recognition optimization. I would also guess that for most, far more time could be saved speeding up builds and tests. That’s not to say that it’s not worthwhile to optimize character recognition speed. But I would guess that character recognition speed is not the main processing time in the mental “stack” when reading code.