| > I fully disagree Disagree about what? You've certainly recognized that professional engineers have tried to usurp the term for their own devices, but that was already called out earlier. There was never a disagreement there. The word "engineer" predates societies of engineers by several hundred years or more so there is no claim that those societies came up with it, so there is nothing to disagree about there either. > Doing a brick layer training doesn't make one a construction builder. If someone goes to a bootcamp and then, following that, sits on the couch watching TV until their end of days then you're right that they would not be an engineer. But I have never seen anyone claim that they are something when they aren't doing it. Someone who worked at McDonalds when they were 14 years old and never again don't still call themselves a fast food worker when they are a 50 year old CEO, so I am not sure this take logically follows. It was implied that there is associated action. |
| |
| ▲ | Jtsummers 2 days ago | parent | next [-] | | Engineering mostly isn't building either. AEs don't build the planes, they design them. EEs may prototype some boards, but as a profession it's also mostly design (intended for manufacture). Unless you're an EE working primarily on one-offs, and small ones at that, you don't build most of the products of your mind. MEs don't build the cars. CEs don't build the dams or bridges. Engineering is principally a design discipline, with a small fraction actually doing the hands-on building of their designs at least once they hit a certain scale of manufacture or get past prototyping. Technicians, skilled and unskilled labor, and machines do the vast majority of the building of those designs. | | |
| ▲ | awsglkhj 2 days ago | parent [-] | | I think we're in violent agreement: Source code is detailed design, and programming is an engineering design process. We can and do design at higher levels, too. |
| |
| ▲ | pjmlp 2 days ago | parent | prev | next [-] | | Yes it is, brick layers in this analogy are those that are only coders. Then we have the whole team of engineers, architects, solution architects, that lay down the work for the coders, more often than not, some offshoring team. | |
| ▲ | win311fwg 2 days ago | parent | prev [-] | | The toolchain does the detailed design work too. The job is more like driving a train — engineering, if you will. The toolchain can do its thing, but it can go off the rails, so you still have to know when to hit the breaks. | | |
| ▲ | awsglkhj 2 days ago | parent [-] | | I think the closer analog is developing schematics for circuitry, where one might design in terms of existing ICs or adhere to a specification about input and output signals. Turning the schematic into a real device would then involve a host of processes, of varying degrees of automation. In the case of software engineering, source code occupies roughly the same position as a schematic, with all the "production" completely automated and highly reproducible. Yes, the toolchain can make decisions about the emitted machine code, but we expect the output to be stable, in all consequential ways, for a given input and constant optimization settings. (Even in manufacturing, there is allowance for variation due to process, and untold money has been spent variously trying to exorcise or neutralize it. We have it easy.) Importantly, while no single person can know everything about the operation of modern toolchains, we know that there exist people with the education and the inclination to understand anything about them. Compilers and linkers and analyzers are not mysterious black boxes that defy investigation. | | |
| ▲ | win311fwg 2 days ago | parent [-] | | > In the case of software engineering, source code occupies roughly the same position as a schematic That is a reasonable take, but software engineers don't work at such a low level. They start the agent and their job is to make sure that the agent doesn't go off the rails. It is like driving a train. Hence why we call them engineers. |
|
|
|
