My first impression after reading the two books is that software development is not just about coding but more similar to IT project management. One has to have a broad range of generalized knowledge and some deep understanding of a few fields in order to manage software development successfully.
McConnel mentioned that specific languages and programming environments can be completely absent during software engineering because "the body of knowledge emphasizes software engineering principles rather than technology knowledge" (p.46). I don't quite agree with him. Although I agree that principles can serve as guidance for practice and a good design may be programmed into many languages, principles may only cover the reality partially and thus rarely reduce the weight of of real juicy technology knowledge in software engineering. As pointed out in the book, software engineering involves more than ten major fields (requirements, design, implementation, QA/QC, deployment, release, etc), I don't see any field that does not require specific technology involvement. See below for involvment example:
Requirement: contains non-functional requirements which needs specific technology knowledge.
Design: you gotta consider language choice based on project requirement and select one with strength
Implementation:developers implement the design in specific language
QA/QC and deployment: you test an application/software in that languange and install the corresponding package
Release: mention known limitations that may come from a specific language.
-------
The other thing I am a bit confused about is that McConnel mentioned that the pattern of programmers working overtime and lack of work-life balance "is avoidable by moving from an engineering approach to software development". I doubt it because I believe the core characteristic of programming (long time involvement required to accomplish a coding task) plays a significant role in determining the characteristics of programmers' working style.
Comments
Just speaking from experience, requirement does not need to have specific technology involvement. Usually you would want to gather the business requirement, getting the business objectives from the stakeholder, then you look at the avaiablable technology see which one is most suitable to meet the objectives. If the business objectives require to utilize the existing infrastructure or minimize the change, then perhaps the existing in-house technology would be leveraged within the requirement.
As for design, I think it does not necessarily the best/most suitable language get chosen for the specific task, you gotta look at other spectrum as well, such as available resources.
QA/QC, you test the feature/function points. For web app, it is highly possible to test it without knowing the underlying language used for implementation.
That's just my two cents.