It's interesting how you'll often, in culture and media, see computers described as cold and inhuman. Like, I get it, of course. But in a way, there's also something very human about working with them, because every part of the stack was designed, meticulously and painstakingly (or maybe haphazardly) by other humans. The analog EE might worry mainly about the laws of physics, sure, and as you said, the CS theorist might fiddle with pure mathematics. But it seems the majority of working software engineers, and even a good chunk of electronics designers, will spend their time dealing mainly with things designed by other people.
I get the impression it's not the same as like you said, the biologist that deals with the squishy, incomprehensible products of evolution, or the chemist and physicist that have to try to understand stuff like quantum mechanics. Those are the "cold" fields to me; ours is positively warm and cozy.
Of course at a high enough level, software development relies on judgments as well, and what architecture will be most maintainable or future-proof, when to go with which principle (DRY, YAGNI, KISS etc.), what approach to use etc. will be similarly squishy in a way.
Then at university I learned it all from the ground up, clearing many misconceptions. But my misconceptions also were helpful. When we learned about OpenMP, I remembered I had thought that "for" loops would run in parallel. And indeed it turns out it was possible to run them in parallel. Or I had misconceptions about pass-by-value and pass-by-reference but at least had a prepared mental framework for this when we formally learned about it.
Biologists arrived at the scene similarly, without manuals or foundational courses handed over by God. So it had to start with this "competent ignorance" at first. You don't quite know what you're doing but it works. And then you figure out the building blocks.
If you go deep enough into electronics, you'll run into physics again. The engineers working at the chip fabs (and chip design) work very hard to shield us mortals from the messy details - the idealized transistors and gates we work with in the digital world are a useful abstraction. (I hope never to need to learn about quantum tunneling!)
In the same way, if you go deep enough into software design (whether "user-facing" or for other developers, you'll run into the messy vagaries of humans and our wetbrains.
Whether you're dealing with the subcultural expectations of your audience for a drop-down vs radio-button, or writing a tutorial on how to use your library, or thinking about what features your fancy new programming language needs, we rely on the abstractions and rules-of-thumb that we've learned. But those rules come from deep places, using results from neurology, sociology, psychology, etc!
Everything is deep, in every direction and all the way down. :)
Often resulting in building things for 'customers' (internal or external or even ones self) which result in a complaint that you built the thing they asked for, not the thing they need.
There is occasional grateful acknowledgement that the only reason they now know what they need is because they got what they asked for, but usually its somehow your fault you got it wrong...
"Computer Science" as a term has always felt like a misnomer to me. Its a mash-up of building on whats already known (or assumed) and also exploration by trying things out. It lacks the rigor of the 'hard' sciences - hardly anyone writes mathematical proofs proving their computing is correct let alone optimal.
But I agree with you in general. Because you're continually 'building'/creating stuff with a reasonably quick feedback loop, rather than measuring/proving whether your idea is valid or not which can take up to or more than a whole career does make computing seem warm/cozy.