Ones and zeroes in the clean environment of a computer chip can be controlled absolutely. When you write a reasonably self-contained program, everything that goes right and everything that goes wrong is entirely your fault. It is not a metaphor; programming simply is small-scale godhood.
Ones and zeroes can't be controlled absolutely all the time.
"...Sun's UltraSPARC II workstations were crashing at an alarming rate. The inability to initially locate the
source of the problem created significant customer dissatisfaction issues for Sun. The root cause of the problem was finally traced to IBM supplied SRAMs that were experiencing high upset rates due to charged particles causing soft errors in the memory system. Ultimately, not only did Sun switch memory vendors, they also designed new error checking and correcting logic and implemented it across the entire cache architecture."
It's omnipotence without omniscience, though. Any reasonably complex program will grow beyond the programmer's ability to keep it all in his head at once.
Ah, but if you run it slowly enough (step through it, for instance), you get the same thing in effect; anything you want to know you can find out before anything changes.
You can easily lose the big picture by stepping through each line of code, especially if your program is heavily iterative or even mildly threaded. You can miss the forest for the trees or the trees for the forest; the middle ground is elusive at best.
And this is why it's best to have both design and engineering skills when bootstrapping a startup. You don't have to treat yourself like a tiny god.
But seriously, I'd like to see more being done to help people cultivate both. It's massively valuable to be able to both care about users and code the thing. What Steve Jobs does on a larger scale by being a dictatorial designer can easily be replicated at the individual stage when you are both designer and implementer.
"Technical people are motivated by interesting work. They will put up with abominable working conditions if they get to work on something that interests them. I've managed people who had to be sent home at night. But technical people without interesting work are very difficult to manage. Their active minds tend to get them into trouble. A happy team is a group that is busy and too intrigued with their project to get mired down with internal politics"
I liked the post quite a bit. He not only describes a psychological type that is indeed common among programmers, he also gives reasons for why they are that way and advice about how to interact with them effectively. Plus it was short.
