From the outside the term "software engineer" seems fairly descriptive, no? It describes someone who _engineers_ software... So what does that mean? - software engeineer vs salesman - The point i see in my mind but was having trouble articulating is that in many careers / professions your title is reasonably descriptive of your capabilities, but this is not true for "software engineer" outside the broadest sense of "can work with code" - I'm a software engineer, but can I build an operating system? Do I know how to build a base firmware layer to interface between some hardware and other software? Could I build an ACID-compliant database from scratch? - Given that the answers to these questions will vary wildly by individual "software engineer" what does the term actually mean? - Actually, since in the industry we know generally that it almost always means "someone who can code" but doesn't necessarily mean "someone who can build an OS" a better question might be: What is it _supposed_ to mean? Why do we use one term to describe people who can engineer a system from scratch and people who can slap together a bunch of disparate tools lego-style? - Part of the point here is the abstraction tradeoff - Generally, I think it's a good tradeoff. We get _WAY_ more productivity out of abstraction - Still, it does seem to create the possibility of technological decline. If everyone forgets how to build an OS then what? - Of course part of the benefit of technology is that we can now store way more information way more cheaply and redundantly, but that doesn't mean that we do store it. - Abstraction often _removes_ capabilities, most notably compatibility! Wow, what a point: [https://youtu.be/pW-SOdj4Kkk?t=2352](https://youtu.be/pW-SOdj4Kkk?t=2352) - This whole lack of compat and lack of interop business is part of what got me worrying in the first place.