To make robots, you need teams of both hardware engineers and programmers. The same goes for many hardware-software systems: drones, automated doorbells, electronic medical devices, and so on.
The two teams need to communicate with each other. It's a meeting of different cultures.
A friend once told me a story. A long time ago, in the early 1980s, many companies were trying to build personal computers. This one company's hardware engineers thought they would play a practical joke on the software people.
Once in a while, early in the morning, they would pass by the programmers' workstations and swap the wires that connected the cathode-ray tube (CRT) displays (remember those bulbous things?) to the computers. This caused the workstations to show an upside-down image.
But somehow, this trick didn't seem to faze the programmers. Why?
The programmers modified their "driver" software, the low-level code that talked to the displays, to add a zero-or-one flag. When they saw their display was upside down, they would press a key to change this flag from zero to one or vice versa, which would flip the image back. And they would carry on working.
This incident illustrates the two cultures.
Hardware is difficult to modify, and it tends to do just one thing, so its requirements are typically strict and unchanging. The hardware people run plenty of tests to make sure their system works correctly before they release it. So, when the hardware engineers played their trick, they thought they had rendered the display hardware unusable.
But software is easy to modify. Its requirements change all the time, right up to the last second. In fact, as modern phone users know only too well, software continues to change even after it is released, in a never-ending stream of updates.
This difference in the nature of what they work with, makes programmers different from hardware engineers.
In 1985, Danish computer scientist Peter Naur wrote that the activity of programming is not really about writing programs, but about building a "theory," a model, of the world that the program is supposed to manipulate.
Complex software tends to be built in layers, each layer depending on the ones below it. The lowest level talks directly to the hardware. (See article about Linux, Super-spreader). This modularity isolates a programmer modifying one layer from the lower layers.
Each layer also seems to obey Naur's observation. In a modular program, whatever behavior the lower layers show, the programmer will regard them as unchangeable and try to work with them as they are.
At a software organization like in the PC-making company, at any given time, programmer teams have a huge backlog of changes to be made. In the scheme of things, the flipping CRT image was not considered a major issue. In the programmers' minds, it was simple enough to theorize that the hardware had some mysterious fault that caused it to occasionally flip the image upside down. The programmers didn't even report it as a bug. They just worked around it.