You Are Not Your Code

??? words · ??? min read

This is a work in progress from The Pipeline. It will likely change before it is published to the main listing of articles. It is currently at the "drafted" stage.

You are not your operating system.
You are not your programming language.
You are not your text editor.
You are not your code.
You are a person.

Things can be criticised without criticising people.
Criticism of your thing is not criticism of you.


Criticism always hurts, at least a little bit. It doesn’t matter whether it’s constructive, factual, unbiased, or impersonal. It affects us because we are humans—motley organic systems made of meat and bone. Although we are capable of logic, we are not logical beings — especially those who claim to be otherwise.

And yet, criticism is necessary for a healthy society. As science advances our understanding of the universe, old inaccurate beliefs are replaced with more-accurate ones. As our moral circle expands, things like racism and animal cruelty must be challenged. In our industry, criticism of current technology leads to better technology. Criticism is the mechanism of advancement.

So if criticism is hurtful but necessary, who is to blame when things go wrong? Should the critic be totally free to cause unlimited pain to whomever they want to? Should we be afforded total psychological safety, where even the most minor criticism deserves to be punished? The ideal lies somewhere in between. Critics have the imperative to minimise harm, and recipients have the imperative to receive reasonable criticism without retaliation.

In this article, I would like to persuade you to adopt my own personal middle ground when it comes to technology. The critic should be responsible for not causing unecessary harm. Likewise the recipient is responsible for accepting a certain amount of criticism, even tjough it hurts, for the good of society.

Criticism should be falsifiable. Even if it can’t be backed up with data, specific claims are better than vague claims. Claiming that something “sucks” is almost useless to the recipient. Useless criticism causes harm without any benefits, and as such should be avoided.

Bad: Ruby is shit.

Better: Ruby is prone to more bugs than statically-typed languages.

Criticism should be based on evidence. Ideally evidence would be hard data, but since hard data is sadly lacking in our industry, personal experience is some of the best evidence available to use. By itself, raw data should always be allowed, regardless of whose feelings will be hurt. Arguments against the validity of data are acceptable, but it is not acceptable to argue that data is morally wrong. Personal experience is a valid kind of data, despite it being less reliable. You can argue that a person’s lived experience does not line up with the grand scheme of things, but you can not argue that it is not real. If you do not have hard data or personal experience, that is an indication that your opinion is unnecessary.

Criticism should not be aimed at people. Criticism of a technology should be limited to that technology, not its users or creators. Ad hominem attacks are the last resort of someone desperate to win without actually having a legitimate argument. This is an attempt to minimise the harm caused by criticism. There are times when personal criticism is valid, but not when it comes to evaluating technology.

Bad: The only people who like Ruby are hipsters who don’t know any real languages.

Better: In my experience, Ruby is often a poor choice compared to other languages.

Recipients should separate themselves from their tools/products. Criticism of your work or tools is not a criticism of you as a person. If the criticism is responsible, and does not contain personal attacks, then the recipient must also be responsible, and allow the criticism to be expressed. You do not have to agree with the criticism, but you do not have the right to retaliate against the critic. Too often I see perfectly responsible criticism of a technology being responded to by angry fanboys throwing personal insults, which is not acceptable.

You are not your operating system.
You are not your programming language.
You are not your text editor.
You are not your code.
You are a person.

Things can be criticised without criticising people.
Criticism of your thing is not criticism of you.

This applies to publications like blog posts, presentations/talks, and written comments online. It applies to direct feedback such as code reviews, github issues, and emails. It does not really apply to friends shooting the shit in private.

When it comes to unreasonable criticism, like personal attacks, and thoughtless vague opinions aired in public, I think it is reasonable to enact corrective measures. Although I’m unsure about the best approach to keep people in line. My hope is that this article is persuasive enough to “move the needle” of civility in our industry, at least a little bit.


Criticism hurts because we are human, but it is necessary. As such, critics bear responsibility for minimising harm done to recipients. Likewise, recipients bear the burden of accepting reasonable criticism without retaliation.

So when you’re giving feedback to someone, or saying something is a public forum, please be disciplined about how you present your criticism. And when you receive reasonable criticism, please be disciplined in your response, even though it may have hurt you.

Got questions? Comments? Milk?

Shoot an email to [email protected] or hit me up on Twitter (@tom_dalling).

← Previously: How To Create An Anti-corruption Layer

Next up: How To Implement Simple Authentication Without Devise →

Join The Pigeonhole

Don't miss the next post! Subscribe to Ruby Pigeon mailing list and get the next post sent straight to your inbox.