Comment by ipdashc | Hacker News Reader

Comment by ipdashc | Hacker News Reader

Parent Full thread

Agreed on the whole inferiority complex thing. Though in addition, honestly, this is why I've always liked computing and electronics - exactly as you said, everything is intelligible in principle, everything is intentionally designed and runs on simple rules, it's just a matter of how much you dig into it.

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.

I think this contributes to collaboration problems across these types of experts. Experts of the squishy have to think in a holistic way that seems jumbled, irrational and arbitrary to the more structured, reductionist, modular, step-by-step input/output thinking of computer experts. In a squishy field you have to be constantly vigilant about unknown factors and have to integrate intuitions into your work. This can make the experience of collaborating on e.g. medicine+machine learning projects very frustrating for both sides. In my experience, biologists/medical people can't think in a layers-of-abstraction manner and kind of talk about every level at the same time. Even when they model something mathematically, they blend their sentences about the concrete use case with the abstract reasoning that is really independent of it and is just math.

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.

The idea that biologists have difficulty with abstractions probably reflects the “solidity” of modern molecular biology. Biologists were doing genetics, working out the rules of heredity, mapping genes onto chromosomes, understanding meiotic cross-over, for decades before the physical nature of the gene was understood. Likewise immunology is full of terms and factors that today have a biochemical explanation, but again, for years only existed as abstractions. Biology is much easier to understand today, now that we have molecules for almost everything. But biologists did decades of very insightful and productive work that was completely based on abstractions.

It's a bit like dropping a kid into programming without foundational courses on anything. They'll learn from the "outside inward". As I did, before doing a CS degree. 12 year old me knew Excel, so I understood function calls with parentheses are a thing, but didn't have any idea what programming really means, but built HTML+JavaScript pages through trial and error. I didn't know what compilation is, didn't understand that lines in the code are executed sequentially or in parallel. I could configure port redirects in the router to set up multiplayer games without understanding what "protocol" or "port" meant.

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.

This comment and the one above hold more than a handful of nuggets of gold, mark my words!

>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.

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.

There's some interesting parallels here.

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. :)

Reply on news.ycombinator.com