I think the problem is that Computer Engineering is still not an engrained concept in universities. Sure, there are courses where some concepts are taught, but it's difficult if not impossible to tailor your degree towards being a real engineer.
When you work, you work on building things that don't have a specific end goal, without a specific deadline, where the success criteria are also not purely academic. To the extent your problem is technical, you may be exploring the cave for a heck of a long time with no light.
You end up fighting with organizational issues as well.
With a bridge, the model tells you about the forces in the structure, the component tolerances, and the likely behaviour under various stressful and extreme conditions.
Same with EE. Commercial board design uses schematic simulation, automated layout, and loading/transient emulation. You can't do modern commercial PC motherboard design without modelling software. (Well - you can. But it'll take far longer and be far less reliable.)
Software dev is more a case of nailing things together until they probably mostly sort-of work.
There's some guild lore - which changes fairly regularly - but no formal modelling. Realistically it's somewhat informed guesswork based on the current lore, mostly tested by trial and error.
I think part of the problem is that most of our "raw materials" like nginx and postgres are so robust that you can build really quite large projects without having to do any modeling or other big planning. Things that have millions of users can still be more-or-less slapped together from default parts.
Building a bridge is something where external participants cannot really tell you much about what it should look like. They know you can't just double the number of lanes or add a train track as you're doing it.
With a software project, people can ask for all sorts of stuff, and because it's soft, some engineer will say "ok let me see if I can look at that for you".
Not only that, if you write your software so that it's rigid, that's bad code! You need it to be flexible so that you can cater for future concerns.
Softness also means you have to keep up with trends. You can write your next website with a newer, fancier js framework, and people can make these new frameworks are just sitting at home at their desk. They aren't mixing new concretes.
While there are some parts of new software that are more similar than not, and these are more 'engineering like'. The majority is not.
Evidenced by; if you did a 'diff' between plans of a bridge you would get a limited number of differences. When you do a diff between an os, browser, slack, the code that runs this site you get a lot more differences. You need to consider each and every detail. This is not 'big-picture'. Big pictures do not construct things.
Sure, there are lots of similar projects and maybe you can apply a more traditional engineering approach to those.
It is interesting to note, LLMS are bringing the similarities out. You can ask for something and it can code up something from something it has seen that is similar. But, as anyone who has used them, will know, it's only partially correct in its interpretation of that simimilarity.