(^58) 97 Things Every Programmer Should Know
Don’t Rely on
“Magic Happens
Here”
Alan Griffiths
OOKiFOU Y L AT ANY ACTiViTY, process, or discipline from far enough away,
it looks simple. Managers with no experience of development think what pro-
grammers do is simple, and programmers with no experience of management
think the same of what managers do.
Programming is something some people do—some of the time. And the hard
part—the thinking—is the least visible and least appreciated by the uninitiated.
There have been many attempts to remove the need for this skilled think-
ing over the decades. One of the earliest and most memorable is the effort
by Grace Hopper to make programming languages less cryptic—which some
accounts predicted would remove the need for specialist programmers. The
result (COBOL) has contributed to the income of many specialist programmers
over subsequent decades.
The persistent vision that software development can be simplified by removing
programming is, to the programmer who understands what is involved, obvi-
ously naïve. But the mental process that leads to this mistake is part of human
nature, and programmers are just as prone to making it as everyone else.
On any project, there are likely many things that an individual programmer
doesn’t get actively involved in: eliciting requirements from users, getting bud-
gets approved, setting up the build server, deploying the application to QA
and production environments, migrating the business from the old processes
or programs, etc.