[averros]

Nope. Dijkstra was and still is right.

The newfangled ways of teaching how to code managed to produce a generation of really poor-quality software "engineers" producing atrocious slow and buggy bloatware.

You cannot be a good engineer if you reason with analogies and metaphors instead of understanding how things actually work, at multiple levels, and knowing what and when can be abstracted and which lower-level details are important and should not be ignored.

So... if you want to become a decent software engineer, start with learning digital electronics and assembly. This way you won't need "metaphors" for arrays and such - because you will know that a static array is just multiplication by constant followed by addition to a constant and dereferencing of the resulting address.

[Twisol]

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

[acbart]

I believe you misunderstand how the process of learning occurs. If you really want to deeply understand something, it's a whole process of connecting up existing facts and schemas in your brain. That happens more smoothly over time by processes like seeing metaphors. A good teaching metaphor always involves a description of how the metaphor fails. Learning from metaphors is not a weakness, nor is it the only plank to build a house of knowledge on. Eventually, you will need to understand the mechanics too, but there's nothing wrong with starting with metaphor, or examples, or visualizations, or interactive simulations, or any other teaching scaffold.

Also, don't gatekeep the field, unless you have a citation that proves that modern teaching techniques have really led to a decrease in quality of software engineers. I really doubt you have any concrete measure you can point to that won't be anecdotal, but if you have one I am interested in hearing why you think you can strongly believe that folks have gotten wore over time because we got better at teaching.

[mlyle]

> Also, don't gatekeep the field, unless you have a citation that proves that modern teaching techniques have really led to a decrease in quality of software engineers.

I don't think modern teaching techniques have. I think the profession has done admirably (but not good enough) at cultivating the basics in more people than managed it ever before.

But when you multiply the size of the profession by so much, even if teaching improves greatly, odds are you're including a lot more volatility in the amount of ability/intrinsic interest/talent.

There's people who are making it today who'd never have been good enough 20-40 years ago. We need a bunch more programmers and software engineers now, so we tolerate it. And thankfully, improvements in tooling, debugging, and instrumentation, along with a bunch more available performance and storage, limit the harms.

[rfrey]

From your comment history, you appear to be shadow banned. A perusal of your dead comments does not immediately reveal why.

[dredmorbius]

https://news.ycombinator.com/item?id=20110663

[meroes]

Is it the method of teaching really? Or is it that good-enough, quickest to market, and diverse programs often win in a capitalistic market?

Capitalism is all about finding new opportunities. Nothing is static. Pedagogy or otherwise.

[forgotmypw17]

.

[averros]

Thank you, I guess. I've been a practicing software engineer for over 40 years now, and watching the decline of my profession over the decades is quite painful.