emotional technology

the algorithmic oath

doctors take the hippocratic oath, an ethical code which transcends their obligations to their employers. lawyers are also bound by professional ethics which govern their activities and allow them to say ‘no’ to their employers without fear of reprisal. as the world becomes more consumed by software, developers need something similar. parents encourage their children to be lawyers and doctors because these are respected professions. the ability to say ‘no’ to anyone gets people a lot of respect – so let’s developers start doing that more.

in order to avoid the pitfall of making this thing a “who cares” snoozefest, i’ve written it with carefully coded language so that it applies both to the process of development and the process of being a person in general. in order to increase parallelism (widespread participation), i will unpack the ‘secret codes’ so that people can understand what they are, and marvel at the general applicability of learning to program. because programming is inherently a social activity, all of these pledges relate to getting along better – both with our fellow developers, and people in general.

0 – all statements have side effects. i am responsible for all side effects of the statements i make – both intentional and accidental.

if you make a change in a software system, you need to understand all of the parts it will affect. “i didn’t realize this would happen” doesn’t fix a problem.

if you say anything in public, you need to understand all of the parties it will affect. “i didn’t mean to offend you” doesn’t fix the offense.

1 – shared mutable state leads to corruption and deadlock. i will not modify another’s private state without explicit permission.

if you modify data that another thread is using, you can mess up that thread’s behavior and destroy the correctness of the program. only access shared mutable state in a way that does not break the correctness of the program.

each of us operates on our own internal model of the world. if you mess with someone’s thoughts without their permission or awareness, you are a manipulative asshole. get with the program.

2 – faulty implementations still need to work. i will be liberal in the behavior i accept, and conservative in the behavior i exhibit.

this is known as the robustness principle in electrical engineering. the more liberal you are in the behavior you accept, the less likely you are to be broken by someone else’s mistakes.

this is known as being “open minded” or “tolerant” in modern culture. there’s a reason software engineers are quick to rencounce employers that are not gay friendly. when you are dealing with a domain that has solid answers, and the truth is not open to decision by powerful people, the fact that we have differences that don’t affect our ability to find the truth becomes wildly apparent. perhaps it’s your implementation that’s broken.

3 – external data sources are not always trustworthy. i will sanitize all inputs and never execute anything i have not preprocessed.

never take raw input from a user (especially over the network) and do anything with it before you check it for errors. if your integrity is compromised, that can spill over to the systems around you, breaking a lot of things and ruining a lot of people’s day.

don’t believe everything you read or hear – or think. question everything – especially authority. don’t do anything you are told without first running it by your own ethical and moral standards.

4 – bandwidth is limited. i will output only what is necessary, observing packet loss and responding appropriately.

as traffic goes up, so does congestion. sending more across the wire than you need will prevent other systems from communicating when they need to. in an environment that is very starved for bandwidth, you holding off a few messages to send them at once can really calm things down.

in an already noisy environment, anything you say can easily add to that noise. people have limited ability to process input or ideas; in any group situation, be careful that you don’t speak over other people, dominate the discussion, or introduce too many topics for people to follow.

5 – no one codes alone. i will solicit feedback often, and adjust accordingly.

any thoughts? if you like it, repost this or link to it to help get more eyes on it. if you hate it, tell me why!