From (aptly named) The Philosophical Programmer: Reflections on the Moth in the Machine by Daniel Kohanski:

Aesthetics, let us admit, mean nothing to a computer. And elegance in programming is by no means a guarantor of efficiency. It must be constantly borne in mind, however, that programs are not written solely to be understood by computers, but by people as well. While the computer may well be able to execute a poorly designed program and produce the correct answer, it is often difficult to determine from an examination of the program that it is the correct answer. Badly designed programs are notoriously error-prone, are likely to be slower, and are often referred to by derisive nicknames such as "spaghetti code" – for the logic paths resemble nothing so much as a bowl of spaghetti and are even harder to untangle. The very programmer who wrote such a piece of code might find it hard to trace its logic a week or a month later on. Moreover, even if the program does the proper job today, tomorrow may bring a new set of requirements. Programs constantly evolve, or to be more precise, the uses of a program evolve, and it is the programmer who performs the evolution. The requirements of modern programming assignments are such that they place an almost inhuman – and certainly inhumane – burden of perfection on fallible human beings, who will find an all-but impossible job that much harder if the program's design is not perceptible to them. Attention to aesthetics improves human perception.

This is something that many of us who take the craft of programming seriously already know and believe. I can certainly agree with the statement above, and have written (and cleaned up) my fair share of spaghetti code. However, further in the book Daniel tackles the Ethics of programming.

The tendency of the computer to isolate programmers and operators from the people impacted by their actions fosters a new degree of alienation, which increases the problems created by its magnification of our imprecise thoughts. We are accustomed to making ethical decisions about how we use our tools according to the immediate and visible consequences of those decisions. But when we are separated from the people affected by our actions, this distance – this alienation – often provides us with an excuse to overlook the connection. This temptation long predates the computer, of course. A building contractor using inferior materials in the expectation of being long gone from the scene when the walls collapse is but one infamous example. The facility with which the computer alienates perpetrator from victim, however, adds a new dimension to an ancient concern. We no longer see a real person, only numbers and names on a computer screen. People who would never have the temerity to rob passers-by on the street have no compunctions about using a computer to steal their credit reputations instead – and do far more damage in the process. Negligence in keeping a database up-to-date or carelessness in data entry can have disastrous consequences for the person whose record has been mishandled. It has happened that a person is arrested again and again on the basis of the same mistaken information because the original error in the database was never corrected or the dismissal of the case was never entered. Such a cavalier attitude is credible because the database operator never deals with anything but streams of data that all seem the same, so the operator does not connect them wit the real people they represented.

The phenomenon of alienation works on the programmer even more than on operators or users. Instead of seeing the program as a real instrument affecting the lives of real people, programmers sometimes see it as a game, a challenge to their ingenuity. The alienating quality of the computer permits us to overlook the human consequences of a programming decision or error. An assignment to link scattered databases in different computers, for example, becomes nothing more than a problem to be solved; the programmer does not notice the resulting diminution of privacy and the increased opportunities for mischief that can result.

That packs a punch. It puts security, and our responsibility of our users' trust and information in a whole new light.

I have long taught that the further a team is removed from the consequences of their actions, the more the quality of their product will suffer. This adds a whole new dimension to that idea, the alienation of programmer from user is far more egregious.

Finally:

Many of our ideas of ethical behavior derive from our ancestral patterns of living in villages and small agrarian communities where everyone knew everyone else, and trust (or the lack thereof) was a product of close and continuing personal interaction. The city has always posed a problem for ethicists because, while it creates a concentration of people and thus facilitates the exchange and development of ideas, goods, and capital, it also provides anonymity for the thief and the guttersnipe. It makes an easy hiding place where the evil, the incompetent, and the merely careless can escape facing responsibility for their actions. The computer, particularly in its manifestation on the Internet, has often been likened to a global village. But a more accurate analogy would be a global city, presenting all the problems as well the potentials that a human city holds.

What will you change this week, not to be just a better programmer, but a more ethical one?

Join the discussion in the Programming Philosophy Facebook group.