| So finally it appears that the realisation is setting in that "engineering" does not equal "coding". It seems it has been trendy to want to call coding as engineering, when that is like saying because I play with model rocketry on the weekends, I am a rocket scienetist. Engineering is about assembling and/or integrating the efforts and products of many groups or individuals into an overall end product of some kind, usually to a known quality to a fixed budget and schedule (or at least that is the expectation at commencement). In order to be resonsible for the outcomes of very complex efforts it is extremely difficult to "span too many levels", even if you have the ability and time. Thus, on large engineering projects responsibilities are compartmentalised into modules and layers, just like software is. You don't mix the very high and very low levels of software in the one module or layer, you abstract as you go up, maintaining a more or less similar amount of immediately need to know complexity for each sub-system with defined interfaces. This is how complex systems that could not possibly be fully known by any one person, simiply because of the cognitive load alone, are constructed. Engineering teams work in a similar way, so if you are near the upper levels an defining broad brush and system wide concepts, you are not usually also down in the weeds writing device drivers, so to speak. The higher up you go in the levels, the more there is management of of the efforts of others. So that means expectations and interfaces, leading to more and more logistical and people management, and less actual nuts and bolts. The person that designed the Golden Gate bridge probably never used a spanner in their life. (I could be wrong, I just make a throw away anology for the point of it) |