About Zach

Zach is currently looking for his next challenge!
Reach out if you think he'll be a good fit for your organization.

Zach is a software developer who has worked on a range of projects, with expertise in Ruby/Rails and MySQL performance. He also tinkers with other languages in his free time (currently Go, Haskell, Scala, Clojure, and Rust).

He knows how to laugh at himself and loves to ship software. He is a father of two wonderful kids and a husband to a fantastic wife.

email ϟ github ϟ twitter ϟ linkedin

Notable Projects

Picture of Zach

Your Identity ≠ Your Code

This was originally posted on March 16, 2012 when I worked with CollectiveIdea

This morning I started my day seeing this in my twitter feed:

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.