3 ms·
> Would you go to a doctor that knows how to remove an appendix, but doesn't know how the circulatory system works? The ability of a surgeon to successfully re
by boomlinde 7y ago
> Would you go to a doctor that knows how to remove an appendix, but doesn't know how the circulatory system works?
The ability of a surgeon to successfully remove an appendix necessarily involves a fair amount of knowledge of the circulatory system, so the analogy is flawed. In my experience some people get by just fine only knowing how to address a problem through some particular framework. The point of abstraction in the end is to release people from the burden of considering the details.
I think that this is a better analogy: would you go to a massage therapist who knows how to release tension in your back by manipulating your tissue, but doesn't know how neurons and axons work? Perhaps greatness can be achieved by a a therapist who knows the ins and outs of every aspect of your body, but as a patient/customer I am really only interested in the skills of the therapist insofar that they manifest in the ability to relax my back and shoulders. And really, a lot of development problems are like that. People perform well at their development jobs without a firm understanding of the mechanisms and inventions that enable them to perform it in the first place. It's by design.
The real problems arise when there is something you really ought to know. For example, if I don't know how memory is allocated by the black box framework I use and memory use suddenly blows up through my interactions with it, the only thing I can fall back on is a lower level understanding. But usually this is fine, and it is someone else's lower level understanding that you fall back on. If you're working high up in a web front-end perhaps you have to consult someone who contributed to a web framework you're using. Maybe you have the wrong approach in a way that leads to instantiating too many objects. On the very low end of software development you may end up having to consult someone who laid the board out and can reason about the operation of the application in terms of the electronics involved. Maybe these two buses shouldn't be used at the same time because of a reflection problem.
- username90 7y ago> would you go to a massage therapist who knows how to release tension in your back by manipulating your tissue, but doesn't know how neurons and axons work? You should know one abstraction layer deeper. In this case one abstraction layer would be that the therapist knows what muscles there are in a back and where they are. You can administer massages without knowing it just by memorizing patterns, but you would get a lot better and can handle more cases if you know about the muscles. Similarly you can become productive using a framework without knowing anything about how the framework works underneath just by memorizing patterns which works, but you would get a lot more productive and can handle more cases if you had a decent understanding how the framework is implemented.
- boomlinde 7y ago> You should know one abstraction layer deeper. More generally, I'd say that it's a matter of what improves your ability to perform the work you want to perform weighed against the possibly diminishing returns of investing time and energy in understanding things in more and more detail. Depending on the circumstances of your work, this may favor digging into more than a couple of abstraction layers (for example, an embedded developer that knows both software, digital circuit design and electricity can be immensely useful) or it may favor unquestioningly accepting the layer of abstraction you target as the whole truth (for example if I'm working on expressing some performance insensitive business glue logic for some proprietary platform, in which case I don't even have a choice).