Any shaved ape can code. One thing that distinguishes worthwhile coding from crap is adherence to engineering principles. Nitpicking about the semantics of the word “engineer” avoids the incontrovertible fact that empirically derived principles and best practices exist and that software engineering is a thing.
Coincidentally, my MSc is in mathematics and statistics, after a dual BSc in math and physics, so we’re from similar starting points. My education as a software engineer and later as a systems architect only came once I began coding. There’s a considerable body of empirical knowledge in the literature (along with too much irreproducible fluffy bullshit), but in my experience, the general awareness of that knowledge is worse among the newer generation of coders than older ones. I suspect that’s because they generally assume that the toolchain and processes do it for them.
The widespread adoption of Scrum has been another source of knowledge loss: it’s used in a number of situations where it does more harm than good, and even where it could succeed, it’s often misapplied (partially because some agile principles are impossible to implement in most real-life organizations, so misapplication is the only posssible kind of application). There are times when architecture and design matter greatly, and some agile practicioners seem to actually believe that they can be done on the fly or major shortcuts can be taken. “We’re not doing waterfall!” You know what? I’ve been in the business since before some of those fools were born, and I’ve never done a waterfall project. It was already an anti-pattern in Fred Brooks’s 1970 magnum opus. Agile vs waterfall was always a false dichotomy. It’s just that some of the OG agile people were too ignorant to know that, or too self-interested to admit it.
Any shaved ape can code. One thing that distinguishes worthwhile coding from crap is adherence to engineering principles. Nitpicking about the semantics of the word “engineer” avoids the incontrovertible fact that empirically derived principles and best practices exist and that software engineering is a thing.
Coincidentally, my MSc is in mathematics and statistics, after a dual BSc in math and physics, so we’re from similar starting points. My education as a software engineer and later as a systems architect only came once I began coding. There’s a considerable body of empirical knowledge in the literature (along with too much irreproducible fluffy bullshit), but in my experience, the general awareness of that knowledge is worse among the newer generation of coders than older ones. I suspect that’s because they generally assume that the toolchain and processes do it for them.
The widespread adoption of Scrum has been another source of knowledge loss: it’s used in a number of situations where it does more harm than good, and even where it could succeed, it’s often misapplied (partially because some agile principles are impossible to implement in most real-life organizations, so misapplication is the only posssible kind of application). There are times when architecture and design matter greatly, and some agile practicioners seem to actually believe that they can be done on the fly or major shortcuts can be taken. “We’re not doing waterfall!” You know what? I’ve been in the business since before some of those fools were born, and I’ve never done a waterfall project. It was already an anti-pattern in Fred Brooks’s 1970 magnum opus. Agile vs waterfall was always a false dichotomy. It’s just that some of the OG agile people were too ignorant to know that, or too self-interested to admit it.