I had initial thoughts, but I read the article and noticed the author is an academic.
The author mixes up How and Why of software engineering. Learning is part of the How of software engineering. The Why of software engineering is to develop and deliver solutions to business clients. Most business client don't care if you learn something or not, they expect results.
True, I am an academic (btw is that something to be ashamed of?), but I have worked 10 years in the industry - and am still doing projects for real clients.
I agree, I could have differentiated a bit more on the How and Why, but I think in the end it applies to both: do the customers REALLY always know what they want? They think so, but it is not really the case. Often it is muddled under a premature idea of a solution the client already thought up. Therefore, its better to start with a minimum viable solution (prototype) so the client actually sees and touches something tangible, which will very often change their idea of what they actually REALLY want.
Software development is a knowledge business, as Fred Brooks has realised nearly half a century ago [0]. In order to build any kind of working software, you have to learn a lot of different things first, on all levels -- from how to write a list comprehension in Python all the way to why a certain end-user needs a particular functionality.
Strongly disagree. Why of software engineering is to formalise business processes so they can be replicated and automated. The code is most definitely "how" we get there.
The author mixes up How and Why of software engineering. Learning is part of the How of software engineering. The Why of software engineering is to develop and deliver solutions to business clients. Most business client don't care if you learn something or not, they expect results.