|
|
|
|
|
|
by smnrchrds
1912 days ago
|
|
|
We don't expect the people who build our bridges or design our cars to be physicists. Physicists (and other scientists) expand science. Engineers use established science-based methods to design stuff. Technicians (also called technologists in Canada) carry out more established and routine aspects of design such as creating CAD models. Each group has their role. For some reason, in the computer world, scientist, engineer, and technician have been merged into a single role. Full-stack, if you will. But as the success of the separation of roles in other domains shows, it does not have to be like this. |
|
|
I mean in software the theory is so close to the practice that there's little purpose to create a role of software technician for the software engineer.
You could say developer or programmer means technician, but it's not really the case in most companies, because developers do engineering work, too.
A lot of projects don't even have a proper spec, because the program can serve as a de facto spec. In a company where you need a working program, why would you cause translation errors to slow you down if you don't need to?
Separating spec and implementation is possible, but it's an inefficiency that needs a good rationale in a profit driven business. Which is why you see proper specs with later implementation only there where these costs are deemed appropriate. Like safety critical systems in aerospace and automotive.
It does not have to be like this, but it's an efficiency optimization that's just not possible in other engineering domains.
In classical engineering the closest we've come to this is rapid prototyping with CAD tools that allow simulation. Because it's much more efficient when the engineer can do the implementation and find design errors before they're mass produced.