You Are Not Your Code

You are not your code. You are not your ideas. You are not your products. You are not your job. You are not your employer. If I had to give one piece advice to any random person in tech, I would say, “you are not your code.” This is not a unique piece of advice. A quick search for “You Are Not Your Code” on Google returns more than 150,000 results. However, it is the piece of advice that took me a long time to understand and has had a large impact on my overall contentment and my job satisfaction.

You != Your Code

The TL;DR of this post is “you can write bad code and still be an awesome person.” At the simplest level, that is what I mean by “You Are Not Your Code.” It sounds obvious, but it took me years to understand, believe, and act on this advice. For many of us, especially those with a few years of experience, coding is an act of creation akin to art. We think about all the different ways to solve a problem. We choose an approach, implement it carefully, and test it. We make decisions about which use cases are important and which edge cases do not need to be handled gracefully. And we take pride in our insights and our solutions. We feel like we are good people because we solved a hard problem or shaved a second off average response time.

Then someone reviews the code and suggests a different design pattern. Or someone else needs to rewrite part of your code because business requirements changed. Or a tester gets their hands on it and floods your inbox with bug reports. You probably feel bad. You may get angry or argue. You may go off and sulk or try to wrestle control back from whoever added their $0.02 to your masterpiece. If you are like I was about two years into my career, you may know your code is only adequate. You may have asked for feedback, but still have defensive reactions when someone tries to help. When they criticize your code, it feels like they are criticizing you.

Separating yourself from your creation is hard. If it feels unnatural or uncomfortable drawing that line, then you are in good company. If this was easy, there wouldn’t be over 100,000 results on Google, and it would not show up on Hacker News on a regular basis. Separating our accomplishments and creations from ourselves is a common struggle. This quote, from the movie Fight Club, speaks to the same point.

You are not your job, you’re not how much money you have in the bank. You are not the car you drive. You’re not the contents of your wallet.

The people who taught me best

I was told, “you are not your code” countless times at Seattle.rb early in my career. I watched others have their pull requests rejected, get angry, and be told the same thing. Just being told this advice was not enough for me to understand it. It took an unusually brutal code review for me to finally “get it.” I have told this story so many times at this point that it has become more fable than memory but the core of the story is true.

I had written the basics of a new feature. It was a few hundred lines, and we had discussed the business requirements as a group before I started. The feature was not complicated but did require room for future expansion. I finished, submitted a pull request, and went to lunch while I waited for a code review. When I returned from lunch, the code review had landed. Two teammates had ripped my pull request to shreds. Most of the feedback was directed at my design, and it was clear that only a dozen or so lines of the original PR were salvageable. I fought back against their suggestions. I argued about composition vs. inheritance. I vented about the injustice of this code review to friends. As I was sitting there typing yet another counter argument into GitHub one of my reviewers leaned over and said: “Hey, want to get a beer?” Later the other reviewer asked me for design advice on their current work in progress.

Those positive, friendly interactions broke my brain a little. How could I have been so wrong on the feature I coded and yet still be someone they wanted to hang out with and ask for advice? If my code was crap then I was crap, right? Those co-workers showed me through their actions that I was a valuable part of the team even if my code was wrong sometimes. While we worked together, they continued to give me advice, ask for my advice, and occasionally eviscerate my pull requests that needed it. I learned some new things from their feedback, and they learned some things from me. Everyone was a valuable member of the team no matter how bad their last pull request was.

The other folks who thought me this lesson are my friends at Seattle.rb. Through our study groups, I get to see first hand how many different solutions there can be to a single problem. Some solutions are faster. Some are easier to read than others. Some only make sense if you have a strong math background or understand the fundamentals of interpreters. Seattle.rb is a place to experiment with potentially bad ideas to see if they pan out. By consistently spending time in this environment I started to internalize that we all mess up or don’t understand something occasionally. We have all had success and failures, good ideas and bad ideas, and that none of that has anything to do with who we are as people. It is far better to take feedback and move on with life.

The advantages to not being your code

I am still not 100% on “you are not your code” but once I started the painful process of untwisting my self-concept from my output many things improved. The biggest improvement was that I was able to incorporate feedback faster. I was able to learn from feedback before, but it tended to be an all or nothing situation. I would make all of the changes suggested or none of them. Separating my self-concept from my code made me more open to sweeping changes and novel approaches, and it also made me more confident in rejecting feedback that didn’t work for me.

Remembering that self and output are separate also enabled me to truly participate in group ownership of code and projects for the first time. Before, when I was faced with a group project, I would think of it as an amalgamation of individual efforts. I had “my part, “ and if changes needed to be made to that part, I would be the one making them. Once I gave up on the idea “my features, “ and my territorial behavior, life got much better. I could actually collaborate. Our code got cleaner since everyone was empowered to fix issues they noticed. I could go on vacation and know that if something bad happened the team would deal with it. Being part of a team that is working together can lead to marvelous results.

I have also found that teams that focus on “you are not your code” tend to be psychologically safer environments. If you are not your code, there is no space for personal attacks. People feel free to propose the kind of outlandish ideas that lead to significant innovations. Work life balance is better because people have value beyond the amount of code they can crank out. If my value is independent of the quality of my output on any one day (or in general) then having my PR rejected isn’t a personal slight and I can move on quickly. Everything seems less urgent and more playful in an environment where software is something I do, not something that I am.

How to not be your code and to help others

Hopefully I have convinced you that life is better when you can separate your creations and your self. Putting this into practice takes time. It probably took me at least five years to stop being protective and defensive of my code. Giving up the idea that my projects and ideas were me took even longer. One thing that helped was avoiding personal attacks and name calling in code reviews and during casual conversation. There are people in my tech community and at work whose actions bother me, but I strive not to generalize that to judgments about their character. Being specific about feedback is one simple way to do get in this habit. “This is dumb” is a lot less specific than “This is a great idea, but it is faster if implemented without nested loops.” The second piece of feedback is actionable and much harder to read as a personal attack.

Another thing that has helped is doing projects and exercises where the point at the end is to delete or destroy the results. Code Retreat has a rule that after each 45-minute session you must delete the code. Doing tiny programming exercises that are just for learning helps too. I also have done some activities in my personal life, like knitting, where once I’m “done” I rip it all out. Embracing impermanence makes it easier to detach from your creations.

The last recommendation I have is to be human and encourage others to be human as well. I struggle with this. When I’m in my coding zone I forget to ask what my co-workers got up to on the weekend or what is going on in my nerd friends’ lives. Even simple things like the food channel in the Seattle.rb slack and talking to my co-workers about their pets, children, and hobbies help me remember that we are all so much more than the code we write and the ideas we have.