Hacker News Reader

Comment by yxhuvud | Hacker News Reader

"But is downplaying the importance of math a sustainable message for future generations of engineers?"

No, but most programming is definitely not engineering. Math savvy people will definitely be needed - more in some areas than in others, but it is silly to have something most people don't have use for in their daily work as a requirement.

The point being is that there is a need for people with engineering skills, but there is also a need for people with craftman skills. Perhaps what we are seeing is the early stages of different education paths to the different roles?

As for the different points:

"Number theory. If you’re ever asked how one algorithm or data structure performs over another"

Err, no. That would be courses in analysis, calculus or numerical calculation courses, or courses in discrete analysis if you can find one. Number theory is what you use to understand stuff like encryption.

(Also, the popups was very annoying on the page)

View on HN

Yeah, items 1, 3, 8, 9 and 10 are somewhat nonsensical (3 might need geometry, but it would be more about physics).

> The point being is that there is a need for people with engineering skills, but there is also a need for people with craftman skills.

I disagree. We don't need people with craftman skills, or better to say, we shouldn't need. Because once you can define what is craft, then computer can be programmed to do it.

At work, I still code in (mainframe) assembler sometimes. It's a craft, but it has been largely replaced by compilers. Where it cannot be replaced by compiler (which is definitely not the case of my job), it becomes engineering.

Potentially all of the programming can be, and most likely will be replaced by machines, so it's a moot point. Until then, there are tons of programming jobs that are poor fit for automation but are definitely thin on engineering challenges.

It really depends on what you consider to be engineering. Traditionally, engineering was creation of a "blueprint". Once you had that, someone had to actually build the thing in the real world (the craftsmen). But in software? The blueprint is the final product!

Of course there is messiness that was mostly introduced by people, which makes lot of engineering rather trivial, and you can call it a craft if you stretch it. But that's mostly an artifact of doing things wrong.

I would argue with waterfall model (naïve translation of engineering to software) being out of favor for decades now, almost nobody actually makes "blueprints" for software. Agile, XP and TDD is basically "put something together and make sure it doesn't fall apart when we ship it".

Now what actually requires engineering is a whole another perspective. I'd argue most software development jobs are closer to "renovate the kitchen" than "calculate building wind load" type of work. Also remarkably in construction, the latter task turned out to be much easier to automate.

> most software development jobs are closer to "renovate the kitchen"

And why people need different kitchens? Cannot the differences required be resolved by configuration, do they have to be resolved by programming?

I argue that everybody having different kitchen is inefficient and wrong approach to software development.

Waterfall was never in favor - IMHO programmers (or software engineers) always recognized that there software has no good analogue to reality, and there is nothing like a blueprint for software.

There are ISO standards for what is known as waterfall model, from block diagrams (the actual blueprint) to project flow. It was the only model in widespread use before time-sharing systems and then personal computing came to dominate the market. The Mythical Man-Month was written as an argument against established practice in the field then.

> And why people need different kitchens? Cannot the differences required be resolved by configuration, do they have to be resolved by programming?

Sure, if all your want is say IKEA kitchen with IKEA appliances. Some people have genuinely different needs.

Engineering is the process of modelling reality mathematically to save time and money while building useful things.

If you skip the modelling part and just build things you hope are going to work - and you can't be precise about when, if, or why they might not work, or how long it's going to take to build them - you're not doing engineering.

I disagree. There are plenty of people who I would consider excellent engineers, both in software field (Linus Torvalds) and outside it, but they are not doing any mathematical modelling (except in the sense I outline in the other comment). They are just using lots of heuristics, experience and common sense. But in more mature fields, like mechanical or electrical engineering, such approach is more historical, since the theory and modelling is very well developed. Still, to restrict engineering only to that sounds very wrong from the historical perspective.

> We don't need people with craftman skills

> I still code in (mainframe) assembler sometimes. It's a craft

You seem to be contradicting yourself. Unless you are saying that you use assembler even though you don't need to.

He explained it above (and in the very next sentence):

"It's a craft, but it has been largely replaced by compilers".

> Unless you are saying that you use assembler even though you don't need to.

Yes, that's what I am saying. The use of assembler is historical legacy, so that's similar to how my mother does embroidery for restoration work (and also for fun!) even though she could just use CNC loom or something fancy like that.

That's why your incomplete quote is continued by "or better to say, we shouldn't need".

Reply on news.ycombinator.com