Comment by oatmealsnap
3 years ago
I mean, there's a time and a place for speed reading. Part of being good at speed reading is identifying the areas you need to slow down for and pay attention to.
Another aspect of writing code is to think about future speed readers. Can your code be skimmed and understood on a cursory level?
The best code is the code that doesn’t need to be read at all. This takes a lot of skill in abstraction.
For example code a “user data cache” with lots of user concerns and people will be reading that code a lot.
Code a “generic cache” and test the hell out of it and it’ll never need to be read (or rarely)
There will need to be code that deals with users but it can interact with the cache so where business logic ends and caching begins is obvious.
Then repeat: how can you split the user code up into generic concepts? Users vs. roles vs. credentials?
Of course it will have to be read, what makes you think you can guess what people will have to read? This seems such an anti-pattern, instead of writing readable code that lives inside the domain where its used, you make an unnecessary abstraction. This is exactly how redundant complexity gets made and you wind up with 16 abstraction layers where each is used just once and a completely unreadable mess.
The advantage of good abstracting is you can unit test one layer and make it super solid, then build the next layer with less mental load.
I am not advocating making “unnecessary” abstractions.
I’m not even advocating abstracting from the get go: sometimes you need to see the messy to appreciate the abstracted.
This is modulo all common sense trade offs!
2 replies →
this.
While it is important to separate concerns where applicable (might be user related functionality and caching) generalization most of the time just adds complexity.
Good insight
For me, speed reading is trusting that the comments are correct.