"Software engineering" is the political ideology that the study of management practices can enable you to deliver a successful software project without learning how to program. It is very popular in fields where a software project can be considered successful without ever delivering usable software, such as cost-plus defense contracting, management consulting, and enterprise software.
If you want to know how to build computer programs, then learn the type system of your chosen language, and learn how to reason about the behavior of sequences, loops, and conditionals—even if you do it informally or with small-step operational semantics instead of Hoare logic, and even if your language doesn't have type inference. Don't listen to the comforting lies of "Software Engineering" promising easy shortcuts. There is no royal road to Geometry, and there is no royal road to Google. Git gud.
But it is also true that there is a great deal that you could learn about computer science that you do not need to write working software, fast. Sequential search is often fast enough. Simple hash tables are usually better than fancy balanced trees. You will probably never use a computer that uses one's complement or the network stack the OSI model describes. If you have an array to sort, you should probably use a sorting function from the system library and definitely not implement bubble sort from scratch. Or even Quicksort. You can program in Erlang or Java for decades without having to understand how the garbage collector works.
> "Software engineering" is the political ideology that the study of management practices can enable you to deliver a successful software project without learning how to program.
Software engineering is not an ideology, but the application of engineering practices to building computer programs, the same way civil engineering is the application of engineering practices to building bridges.
Your statement is odd: software engineering curricula do include theoretical and computational courses, but ultimately those are a limited part and not the focus of the curriculum.
In the same way CS curricula do include few engineering and application-focused exams, but again, they are not the focus.
It's absolutely fine for the two curricula to be different and they are indeed different in most of Europe.
E.g. at the university of Pisa the CS curriculum (obviously speaking about masters, arguing about bachelors is partially irrelevant, you just can't get in enough depth of any topic) has exams like parallel computing, category theory, models of computation, compilers and interpreters.
But the software engineering curriculum has: mobile and physical systems, machine learning, distributed computing, business process modeling, IT risk assessment, IT infrastructures, peer to peer systems, etc.
Of course many exams are shared (albeit they have slightly different focuses) such as: randomized algorithms, competitive programming, advanced programming and you can likely choose one of the other courses as your optionals.
But the focus is ultimately different. One focuses on the theory behind computation, one focuses on the practical aspect.
Or look at who's actually executing successfully on the practical aspect of building software. It isn't people who got a master's degree in IT risk assessment and business process modeling.
If you want to know how to build computer programs, then learn the type system of your chosen language, and learn how to reason about the behavior of sequences, loops, and conditionals—even if you do it informally or with small-step operational semantics instead of Hoare logic, and even if your language doesn't have type inference. Don't listen to the comforting lies of "Software Engineering" promising easy shortcuts. There is no royal road to Geometry, and there is no royal road to Google. Git gud.
But it is also true that there is a great deal that you could learn about computer science that you do not need to write working software, fast. Sequential search is often fast enough. Simple hash tables are usually better than fancy balanced trees. You will probably never use a computer that uses one's complement or the network stack the OSI model describes. If you have an array to sort, you should probably use a sorting function from the system library and definitely not implement bubble sort from scratch. Or even Quicksort. You can program in Erlang or Java for decades without having to understand how the garbage collector works.
There are some good posts on the blog that do a good job of explaining: https://prog21.dadgum.com/177.html https://prog21.dadgum.com/87.html