That's interesting! I've always seen engineering largely as "science applied to the context of business/public good", that was the definition that was embedded

That's interesting! I've always seen engineering largely as "science applied to the context of business/public good", that was the definition that was embedded in much of my education as an engineer as well (in part represented by the ethics / general business / project management et al. courses that were complementary to the ones focused on technology). In that lens, software/computer engineering always seemed like "computer science, but with more formal emphasis on feasibility (cost/time/effort/resources) and ethics. This also keeps front and center the idea that technology doesn't exist in a vacuum (i.e. code that implements feature isn't produced in isolation from the people who will use, sell and/or distribute it and should take that into consideration to be a true fit). While I agree that focus can, in certain cases, make things happen faster, I also think that disconnect from how things are used and how they are used can easily lead folks to build the wrong thing quickly and have to circle back, whereas a more holistic vision of the product can help steer development in the right direction earlier. That's not to say that the "non-technical" (here, specifically "concerns that aren't directly related to the technology and implementation) should have a disproportionate weight, but I find that having it occupy some space can benefit the end result, because adding dimensions to engineering work beyond the pure technical stuff can add interesting perspective. In a way, it's not that different from the non-engineering electives that act as complementary coursework in most curricula that I've seen or heard of. Digging into a few key points that caught my eye in the above: > It seems to me it's undermining the amount of effort it takes to learn and practice engineering because it is evidently not enough value by itself. I would love to know more about this: why is framing engineering work in terms of business value undermining the effort needed to get there? In the end, the business still needs technical experts (of all kinds, because other departments can be pretty technical in their own way), but the business also exists to do business and tends to frame everything it does in terms of "how does this help us win in the marketplace?" > I think worrying about what the customer wants or coordinating and scheduling projects is not strictly engineering. To my earlier bit about engineering having (IMO) a broader scope than the pure technical execution, I think that it's not necessarily about worrying about it, but rather taking it into consideration. Caring about business impact is less "how can I build this so the user will love it and renew" (that would be the main focus of other roles) and more "knowing how this is used by people, how can I make it better fit?" Similarly, I would argue that coordinating and scheduling projects is squarely within engineering concerns (back to the thoughts about engineering being "science-applied-to-business") -- as an engineer matures, it's likely that they'll take a greater hand in driving projects (not as management but as seasoned technical voices, because technically-focused paths should and are a thing) to completion. It's all part of having a growing sphere of influence (i.e. at first, hyperfocus on your individual piece, but as time grows, more and more awareness of how the team's pieces fit with other teams'). At least, that's my anecdotal datapoint of how I work at $JOB and how a well-rounded org could operate.