Hacker News new | past | comments | ask | show | jobs | submit login

While reading, it made me think:

It’s important when approaching architecture—and probably software problems in general—that you do not start by reasoning in terms of the constructs of a particular language (e.g. classes and interfaces). The philosophy underlying this is: your range of potential conceptions becomes wider as abstraction increases; and, as you become more concrete you inevitably introduce auxiliary problems that result purely from the features of the particular language you are expressing with, which means you are prematurely diverting thought from, “what is the correct description of this thing” to, “what is the best wording for this description”.

Also:

Working at a higher level of abstraction has a lot in common with looking at a scene from far away, a mountain range for instance: the further away you get, the easier it becomes to change which mountain you are experiencing: you merely turn your head a quarter of an inch and now three new mountains have entered your consciousness. If you’re trying to decide which mountain to climb, this is an extraordinary benefit—but at the same time, if you are too far away, you can’t perceive the features of the mountain clearly enough for optimal decision making. A similar tradeoff is always present in working at one level of abstraction or another, and understanding these tradeoffs helps you figure out where to stand more effectively.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: