Posted on by

I am my code, redux

I’ve written before that I am my code. Today I felt the urge to reiterate this message on Twitter. I thought I’d collect the series here for posterity, in slightly modified order.

To reiterate what I said in that last tweet: I am not saying that we should never criticize. But I believe that the notion “you are not your code” is a moral dodge; a way to lump venting and verbal cruelties under the umbrella of “criticism of code”. The acknowledgment that I am my code is the acknowledgement that you are your code. Which gives me reason to think twice about how I address perceived shortcomings in your code.

UPDATE: Some notable responses:

From Martin Feckie: Am I my code? Martin has some great concrete advice here for giving feedback from a place of compassion.

5 comments

  1. Practices like collective code ownership, pair programming, peer reviews, etc. tie into the notion that you are not your code. Yes, if you’re a team of one, and you’re writing code because you think it’s beautiful and you want to share it with the world and have them agree how beautiful it is, then you can self-identify with your code. You’re an artist. But if you’re one of the millions of developers who has to work with other developers on a team every day, you should not be overly attached to your code. In fact, looking at the application you’re collaborating on, it’s a good thing if you can’t even necessarily tell which bits are yours and which are Bob’s or Sue’s. Because you worked on it together, and you improved on one another’s code as you went, and the result is better for it. And that would have been impossible if you chafed every time a teammate suggested a change in your code.

    1. As a longtime supporter of agile methods, I’m wholeheartedly behind shared code ownership. Nothing I’ve said should be seen as incompatible with that.

      The problem with a statement like “you are your code” is that 90% of the time it comes either right before, or right after, someone has said something hurtful. And they want to make the recipient feel responsible for feeling the hurt, not themselves. Of course, then everyone says oh I never meant it hurtfully, but that’s the thing. Intent has no bearing on feelings. And when we tell ourselves we are critiquing the code, not the person, we give ourselves license to use phrasing and tone we would never use when addressing a person.

      I agree that it is good for me to establish emotional distance from my code. I say that it is good; I can’t guarantee that I will always succeed, and no one else has any business assuming I’ve succeeded. This is one of those values that it’s good to model, but as soon as you start telling other people to do it, there’s a good chance you’re probably trying to give yourself a pass for playing fast and loose with their feelings.

      As programmers, we like to think of things as being 100% on or 100% off. If we all agree that equanimity and emotional distance from code are a “good thing”, then we can just treat everyone like a zen master and if they haven’t fully detached themselves it’s their own damn fault. But detachment from creations is not a human’s natural starting state, and to expect everyone to instantly accomplish it—and blame them when they haven’t—is irrational.

      1. Fair points, but in the context in which I tell developers “You are not your code” (btw I think you dropped the “not” in your comment above), it’s not just before/after I tear their code apart. It’s in a setting like this one, or on twitter, or during a presentation. It’s a reminder for them of what the ideal is. Because having your ego tied up too much in the code you write gets in the way of the agile methods I just described, and as someone who feels these methods add value, I seek to eliminate barriers to their adoption.

        So, I agree, one should not use the phrase as a means of excusing harsh or hurtful comments about others’ creations. But trying to convince people to hold onto the idea that “I am my code / you are your code” isn’t helping, either, IMO. Recognize that it is perfectly natural for all of us to have some of our self-worth attached to our creations. But strive for the ideal of everybody trying to improve what we are producing, and that constructive criticism is most helpful when it is respectfully delivered and accepted without defensiveness.

      2. “I agree that it is good for me to establish emotional distance from my code. I say that it is good; I can’t guarantee that I will always succeed, and no one else has any business assuming I’ve succeeded.” <= This. So much.

        Very well said. Thanks for this clarification.

Comments are closed.