3 ms·

The Present and Future of Engineers

2 points by eternalban 5y ago

eternalban 5y ago
A reason this is submitted is that I found Chavez's consideration of the distinction between long standing engineering disciplines and software engineering to be the most cogent and convincing one I've read to date: "In the US, where I live, there is very little in the way of self-organization among engineers. There have been noteworthy unionization drives among software development employees (including those with Software Engineer titles) in recent years, including those at Alphabet (Google), The New York Times, and NPR. Despite many of the participants holding titles containing the word “engineer,” software engineering and development tend to be very different from the types of engineering described in this essay. Software engineers play both the role of rationalizing technical expert and that of hands-on craftsperson wielding particular knowledge of the work medium (code). A software engineer, despite the title and generally heftier salary, is more akin to a very skilled and creative technician than to an engineer whose job it is to command, directly or indirectly, “low-skilled” labor. Attempts to introduce the traditional technical division of labor into the software realm are simply not very effective, as software is a much more abstracted practice than most other forms of engineering. Engineering utilizes abstract concepts to manipulate concrete phenomena that fundamentally require human labor time. A 3D CAD model of a machine component is abstract, but the human labor needed to fabricate the component is concrete. A circuit schematic is very abstract but ultimately useless if it is not manufactured into an actual circuit board by a person operating a machine. The process specification for a manufacturing cell exists only so that the cell succeeds in manufacturing concrete goods, otherwise the specification is useless. In contrast, software, with its cascading layers of languages, compilers, and assemblers, is much more abstract. While software controls the very physical phenomenon of electrons racing around computer components, these concrete processes are not dependent on human labor time to function. Sure, someone had to manufacture the CPU and the motherboard and the memory, but this labor was controlled by mechanical, electrical, and manufacturing engineers. Software tends to control that which is inhuman; it is a tool that can be used to automate its own development processes. Where it cannot automate its own development, there is nobody left qualified to perform these un-automatable tasks except for the software engineers/developers themselves, as the expertise required is often too high to pass the work off to anyone with less of an understanding. This is not to say that attempts at rationalization do not occur. They are simply far less effective than those that have historically occurred in manufacturing. "Not all software exists in the abstract, however. Software embedded in machines, or software used to manage the labor of others, certainly functions similarly to the type of engineering abstractions used to entrench division of labor in other engineering disciplines. Machine-user interfaces, warehouse sorting algorithms, and ride-sharing apps are examples of software development that absolutely uses abstractions to enforce a technical division of labor in line with older engineering disciplines. This type of software engineering is different from the work of the software developers who are beginning to organize in their workplaces."

2 points by eternalban 5y ago

A reason this is submitted is that I found Chavez's consideration of the distinction between long standing engineering disciplines and software engineering to be the most cogent and convincing one I've read to date: "In the US, where I live, there is very little in the way of self-organization among engineers. There have been noteworthy unionization drives among software development employees (including those with Software Engineer titles) in recent years, including those at Alphabet (Google), The New York Times, and NPR. Despite many of the participants holding titles containing the word “engineer,” software engineering and development tend to be very different from the types of engineering described in this essay. Software engineers play both the role of rationalizing technical expert and that of hands-on craftsperson wielding particular knowledge of the work medium (code). A software engineer, despite the title and generally heftier salary, is more akin to a very skilled and creative technician than to an engineer whose job it is to command, directly or indirectly, “low-skilled” labor. Attempts to introduce the traditional technical division of labor into the software realm are simply not very effective, as software is a much more abstracted practice than most other forms of engineering. Engineering utilizes abstract concepts to manipulate concrete phenomena that fundamentally require human labor time. A 3D CAD model of a machine component is abstract, but the human labor needed to fabricate the component is concrete. A circuit schematic is very abstract but ultimately useless if it is not manufactured into an actual circuit board by a person operating a machine. The process specification for a manufacturing cell exists only so that the cell succeeds in manufacturing concrete goods, otherwise the specification is useless. In contrast, software, with its cascading layers of languages, compilers, and assemblers, is much more abstract. While software controls the very physical phenomenon of electrons racing around computer components, these concrete processes are not dependent on human labor time to function. Sure, someone had to manufacture the CPU and the motherboard and the memory, but this labor was controlled by mechanical, electrical, and manufacturing engineers. Software tends to control that which is inhuman; it is a tool that can be used to automate its own development processes. Where it cannot automate its own development, there is nobody left qualified to perform these un-automatable tasks except for the software engineers/developers themselves, as the expertise required is often too high to pass the work off to anyone with less of an understanding. This is not to say that attempts at rationalization do not occur. They are simply far less effective than those that have historically occurred in manufacturing. "Not all software exists in the abstract, however. Software embedded in machines, or software used to manage the labor of others, certainly functions similarly to the type of engineering abstractions used to entrench division of labor in other engineering disciplines. Machine-user interfaces, warehouse sorting algorithms, and ride-sharing apps are examples of software development that absolutely uses abstractions to enforce a technical division of labor in line with older engineering disciplines. This type of software engineering is different from the work of the software developers who are beginning to organize in their workplaces."