Your identity ≠ Your code
This morning I started my day seeing this in my twitter feed:
Your identity ≠ Your job
— Kyle Steed (@kylesteed) March 16, 2012
I’ve been thinking about this idea a lot lately. And I think it’s a trap that developers (myself included) easily fall into. To make this idea a little more specific to developers: Your identity ≠ Your code.
As developers, we like to solve problems and get a kick out of that feeling that seemingly comes out of nowhere: “Yes! I solved it. I am all that is awesome!” (maybe I’m the only one who says that out loud). But at the same time we attach ourselves tightly to our code and will equate criticisms of our code as criticisms of us as a person. And lets be honest, while we all want to improve, it is difficult not to equate “this could be better” with “you should have been smarter”.
I don’t think it is entirely due to criticism either. There are developers that I look up to, and I still get geeked out when I’m lucky enough to talk with them. For most of my geek-heroes, I also see prominent projects that they are part of, and it is difficult to separate “they are awesome because they wrote x”. I know when I first began, I cared a lot more about how people would perceive the code I wrote rather than how well it solved the problem at hand. It is more important to view your web heros as people who ship working software. If you think they are the authority on how software should be written, you’re in for an awakening.
This idea also affects open source. It is rare to see a young developer submit bug fixes to existing projects. Most developers have the talent to fix outstanding issues, but don’t due to the fear of rejection and criticism. And again it isn’t the specific criticisms of the code they write, which in all likelihood would only accelerate their learning, it’s hearing those criticisms and taking it personal.
It is hard not to take these criticisms personal, especially when you read someone else’s code and say “What the hell was this fella thinking? That moron.” Believe it or not, I’ve caught myself saying that only to run a `git blame` and discover I was the “moron” who wrote the code. Early in my career, after uttering something similar, I was told by another developer “Criticize the code, not the developer.” And that has stuck, though at times I have to remind myself.
We will look at a piece of code and think “This is God-awful. This dev is terrible”. And it’s important to remember there is a lot more context around why code is written a certain way. The original developer’s experience does have an effect, but think back to the hacks you have written and why they were necessary. Even if it can be written better, you’re not doing anyone favors by slamming the dev.
But then we wonder why we get defensive when we hear people sharing ideas about the code we write. “Yeah, they’re saying it politely, but I know what they’re really thinking.”
Cut the ego. Stop equating bad code with bad developers. Stop equating code criticisms as a knock against you as a person. We could use more people submitting ideas and less animosity around existing code.
Comments
Great post Zach. I’m glad to see you taking this to heart and explaining it in a way that relates to you. I think that’s when we move from knowledge to wisdom.
I wish you’d tell my boss this. I get one line design requirements and he moans when he doesn’t match the imaginary picture in his head.
This is also the reason I don’t put into more open source projects.
Everybody else is a brainwashed fool. My code is awesome.
Good article.
I used to be under that limiting beliefs until I realized that what I really enjoy is writing software, whatever anyone could think. Paradoxically, the more that you get rid of that belief at identity level and put it lower to a abilities level, the better your code is.
Thanks for writing, I am going to share it with some friends.
I think i have to print this post and put it on the wall.
Very nice post Zach!
The ease of playing armchair quarterback is tempting. And while criticizing code helps us learn from it, explore others way to do, and ultimately helps us improve and help others improve – we should never attack the person behind the code.
But… I don’t think it’s bad to have the thought “OMG, what were they thinking!”. We’re going to have strong reactions to things that vary wildly from our own expectations, and that’s okay (and natural), as long as we don’t let our thoughts become subversive and transform into attacks on the person. When I find bad code I wrote, I often think, “OMG, what was I thinking!” but it’s more out of surprise than it is that I’m a subpar person.
My rule of thumb in how I approach people in any situation: afford others the same leeway I afford myself.
Your post makes me feel a lot better about myself. I have been currently chastising myself over every line of code I write in my final year project at uni. It is a mess horrible mess, and horrible to look at. It is functional though that is all that matters to me right now and I am running of time.
I do worry what others may think if they were to ever look at the code. What if I showed it to a potential employer? I guess I would feel more attached because of the amount of effort and time put into it. The last thing you want is a bashing for trying. It is something I will try and overcome though and hopefully after reading this I can try and feel the same attitude away from myself. I would hate to propagate the worries I hate.
Thanks for the post!
@Paul Rose: My personal opinion is: shipping something ugly always beats not shipping something pretty. And of course ugly code that works > pretty code that doesn’t.
Good luck. And if you do end up using that code in an interview, talk about the context and issues you had to resolve outside just writing elegant code. You may be surprised to find that conversation impresses them more.
One who looks at the code one wrote six months ago and believes it to be good has either reached some level of enlightenment, or, more likely, is a deluded fool.
Indeed, for enlightenment I yearn.
Great post. Something we all need to take to heart.
At some point I developed the attitude that any code I wrote more than a week ago is generally shit. It might seem pessimistic, but it’s actually been really helpful. I’m not overly attached and I’m not offended when people criticize it. Not to say that attitude doesn’t have its down-sides, but that’s my shrink’s problem (my daddy didn’t love me).
“Criticize the code, not the developer” this reminds me of the very first chapter of How to Win Friends and Influence People - “Criticism is futile because it puts a person on the defensive and usually makes him strive to justify himself. Criticism is dangerous because it wounds a person’s precious pride, hurts his sense of importance, and arouses resentment.” Criticizing someone will get you no where except on the path to being resented.
This is a great insight. I constantly struggle to separate myself from my code. I spend a lot of time pondering the “right” way to solve a problem, and when I implement it, I start to feel that criticism of the code is criticism of the way I think. Early on I was very sensitive of my code. My boss at the time would frequently tell me that I was overly sensitive. This did not help me at all. I have learned to try to take a kind of “out of body” approach when analyzing my code or getting client feedback. This helps me to remain somewhat impartial and create a better product. When clients say “you should have done this differently” I try to redirect by using less personal language: “so you want the program to do this differently.”
Thanks for this post. I’m a very bad programmer, and I really do openly admit it. I have a terrible time showing any code or project I write to anyone else due to fear of being criticized heavily. I’m open to suggestions and improvements, but I take it very personally. Thanks again, I was going to give up coding for awhile, but I’ll keep trying. I appreciate the encouragement!
On the flip side of this issue is the unfortunately vast amount of “terrible” code that I see every day as a contractor, wherein the cost of ownership is several orders of magnitude greater than it could have been had the code displayed even an ounce of - I don’t know what you call it - care, professionalism, the idea that someone might have to modify it later - I’ll call it coding etiquette.
Like actually using comments to tell the guy after you (and yourself) what the hell you were thinking and doing, and having some semblance of a division of responsibility. And yet, in every case, the development staff are described as “Senior level Professionals” and the code has been reviewed at every modification - yet somehow there is no path open except ever increasing complexity.
Basically, whenever I find myself having to do inordinate amounts of “follow on garbage” code because the code that exists is already garbage and to risky to clean up, it makes me feel stupid spending so much time on something that is guaranteed to be crap when I’m done.
So, somehow, there is a huge disconnect between what a code review is for and what it actually accomplishes - and it might be because during a review, we don’t want to hurt anyone’s feelings, so we jeopardize our projects instead.