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.
empirically derived principles and best practices exist and that software engineering is a thing.
The thing I find most vexing about “software engineering” is that the majority of it comes down to sociology/psychology more than it does science. People make mistakes. They mis-communicate, under-specify, assume, overlook, forget, and screw up.
Programmers practice somewhere between lawyers, authors and graphic artists, and other than the graphic art side of their endeavors, most people never “read” their product. The most valuable principles of software engineering have nothing to do with the complexity of sort algorithms, logic trees or other abstract concepts they were teaching in “computer science” back in the 1980s. The most valuable principles come down to: how do you manage the problems inherent in the situation of human beings writing a bunch of code that almost nobody ever sees which can be fraught with problems that almost nobody will detect until years after the original authors have all but forgotten what they did?
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.
The thing I find most vexing about “software engineering” is that the majority of it comes down to sociology/psychology more than it does science. People make mistakes. They mis-communicate, under-specify, assume, overlook, forget, and screw up.
Programmers practice somewhere between lawyers, authors and graphic artists, and other than the graphic art side of their endeavors, most people never “read” their product. The most valuable principles of software engineering have nothing to do with the complexity of sort algorithms, logic trees or other abstract concepts they were teaching in “computer science” back in the 1980s. The most valuable principles come down to: how do you manage the problems inherent in the situation of human beings writing a bunch of code that almost nobody ever sees which can be fraught with problems that almost nobody will detect until years after the original authors have all but forgotten what they did?