Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Electrical Engineer who can write messy but functional code in C and Python, but mainly deals with analog circuits at work.

Software has a magical property that other engineering disciplines do not: The engineering environment is ideal and fundamentally perfect. It's like building electronic circuits but only in the simulator that uses all idealized parts. And you get the extremely rapid prototyping and scaling that comes with that. (A "single line of code" equivalent error in a production analog circuit can take months to fix and years to distribute)

In a way it feels "unfair" because the fuckery of mother nature and immovable boundaries of physics is largely (and normally completely) cut out of the equation. Imagine having to write code where every variable is a fuzzy range as opposed to a fixed value, it would put a huge clamp on designs.

However,

The intellectual savings from not having to deal with non-linearities and errant physical effects, is largely just shifted into increased overall complexity that all exists in a different realm. So maximum logical thinking and intellect is still demanded.

I think the divide really comes from the difference in space in which the "engineering" is happening. Conventional engineers are dealing directly with nature trying it's best to constantly break your design. And I think there is a degree of comradery that comes with that. Software guys, free form those chains and working in a parallel universe of perfect logic, instead are pushed to the absolute limits of complexity.



> Software has a magical property that other engineering disciplines do not: The engineering environment is ideal and fundamentally perfect. It's like building electronic circuits but only in the simulator that uses all idealized parts.

I get where you are coming from, but man it is very apparent that you haven't had to write device drivers. Hardware is BUGGY and the OS is full of workarounds to make things work well enough most of the time.

EDIT: And now that I think about it, the same is true of any piece of software that interacts with other software components. Your own code ends up full of workarounds to address problems in your external dependencies.

> Software guys, free form those chains and working in a parallel universe of perfect logic, instead are pushed to the absolute limits of complexity

That resonates. You could say that in other branches of engineering complexity is a consequence of natural entropy, whereas in software complexity is largely self-inflicted. Did I get it right?


I'd say with classic engineering, mother nature wrote the OS, so across all the disciplines there is a common shared experience of dealing with Reality OS. Which is eminently present in every step of work.

In SWE, we figured out how to build a VM in Reality OS that runs our own custom environment. All the headache and complexity is there, but it is of a different lineage.


I think computer scientists work in a “parallel universe of perfect logic” but sadly I strongly disagree that the vast majority of software engineers get that privilege.

IMO, contemporary SWE involves a lot of black box treatment, learning complex systems on the fly, and untested large code bases. All of that leads to similar dynamics as more direct physical dynamics in other engineering disciplines do: unexplained behavior, doing things by spec, debugging by process of elimination, etc.

And that’s before mentioning the direct problem of device and network issues; I understand this to be a certainty for those doing things on a global scale.


While it might seem that software runs in an idealized domain free of conventional physics, that's only because operating systems and processors try to provide a "padded cell" in which software can live. But it's a leaky abstraction; for instance, the time it takes to read one byte of memory can vary depending on whether the processor has it on the L1 cache, or has to read it from the DRAM, and even there, it might depend on whether the memory row is open or not, it might get delayed by the DRAM refresh cycle, and so on, and we're not even talking about the case where it's been paged out and the operating system has to read the memory page from the disk. There's a lot of "non-linearities and errant physical effects" there, and as a sibling comment mentioned, the speed of light is still very relevant.

And that's before considering mindfuckery like Spectre and its friends, in which you can, through a careful observation of some timings, watch the effect of an operation which didn't happen, won't happen, can't happen, and sometimes from code which doesn't even exist.


Yeah, either way we're pushed to the limits of thinking. If we weren't then that means we could make greater things, ergo, we're pushed to our limits.


I find this to be true until you deal with parallel programming and distributed programming where the physical world can impose itself :)


Good distillation of the difference between working with atoms vs. bits.


One of the things I think hardware should adopt from software is modular debuggability of system components. I'm a software guy building a display board with a battery management system. I'm building the bms as a pluggable component on the display to make my development easier and the end unit more iterable.


I guess you’ve never dealt with networked or distributed systems? They have unexpected failures all the time.

Moreover your software has to interact with that of everyone else ever. Imagine if every circuit you make has to connect to every previous circuit.


Every wall powered device on the North American grid is connected to the same circuit. And even within circuit design, it's all designed piecemeal with inputs and outputs.


The user is the equivalent force of Mother Nature in software engineering. You just can’t predict what they will try next!


With distributed systems, mother nature comes back to bite you though


That is, until you hit the limits of performance and latency. Speed of light is a b*tch regardless of what kind of engineer you are.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: