|
Although I agree with the core of your argument, I think this position is a little reductionist. Yes, you really do need to understand what's going on under the hood (though, choose your hood). But you're also almost-but-not-explicitly saying that analogies and metaphors are not valuable tools for engineering. I really strongly disagree with that. As one example, I find analogies downright necessary when working with a complex domain -- you have to find ways to speak domainese in the software world, or speak programese in the domain world, and analogies are precisely the tool for that job. It's easy to think that domain concepts should have a 1-1 representation in the software world, but in my experience, that's neither true nor productive. You do need to understand (and document for others!) the mappings between those concepts, but they shouldn't be so rigid. On a related note, I'm reminded of Terence Tao's thoughts on rigor in mathematics [0]. He divides expertice into pre-rigor, rigor, and post-rigor phases. It's necessary to understand the rigorous elements, but those (a) build on intuititons built up over time in the pre-rigor phase and (b) support expert, formalizable intuitions in the post-rigor phase. [0] https://terrytao.wordpress.com/career-advice/theres-more-to-... > So... if you want to become a decent software engineer, start with learning digital electronics and assembly. I disagree here too, though less strongly. I think it's important to have approximate intuitions that can be refined, rather than trying to manufacture a precise understanding out of nothing. Those intuitions can be built up by trying, failing, and accomplishing projects that you're motivated by. Even if Djikstra is right about "radical novelty", you obtain a certain amount of mechanical sympathy just by fighting with the computer and learning its needs. The "Purpose-First Programming" research [1] that this article's submitter also submitted today seems relevant. [1] https://news.ycombinator.com/item?id=25256874 |