Glenn Gillen

Making things is fun. There’s a special sense of accomplishment that comes from creating something from a series of parts that previously seemed to be nothing. There’s a joy that comes when that something is deemed useful or enjoyable by another person. And a gut-wrenching feeling of depression when others write off your work as useless because it doesn’t solve their problem.

Hell is other people’s code

We’ve probably all experienced it at least once. A chunk gnarly piece of code you’ve inherited from developers that have long since left the project, that makes no sense, and possibly doesn’t even do what is required. What on earth were they thinking? How could any person the calls themselves a professional write such atrocities for a living?

I’ve heard people get “care mad” about this before. Blindly raging at a name in a commit history, only because they care so much. And it’s right to care. To take pride in what you do. To appreciate the craft.

It’s compromises all the way down

I write most of my code in ruby these days because I value the expressiveness and the readability, and I’m willing to compromise runtime performance to get it. I want to live within walking distance of where I work, I had to compromise on my initial budget for rent to make that happen. Everything we do is a compromise of some sort, especially so in software. We’re always having to make a decision between optimizing for performance, quality, speed of delivery, readability, or one of any number of other factors. Often we don’t stop long enough to explicitly acknowledge the compromises we’re making. Intuition and experience can guide us on auto-pilot, especially when a specific priority is clearly in focus (a.k.a a deadline).

The right solution for the problem

Empathy is a tricky emotion to master, it rarely comes easy to me and I have to make a concerted effort to exercise it whenever I can. Dealing with someone else’s code is always an interesting scenario. Lacking any context the right assumption is always that they wrote the perfect implementation, given the constraints and priorities at the time. Maybe there’s a more efficient way, but performance wasn’t a priority and a deadline was. And maybe they didn’t have time to learn a better way, whatever worked was sufficient. I don’t have to agree with their priorities, that isn’t want empathy is about. But I need to be able to understand them.

And so when I hear engineers claiming they’re “care mad” about how bad someone else’s code is, what I’m really hearing is that they can’t understand another person’s needs. Which is a shame because empathy is a core engineering value. Without it you’re destined to write software that doesn’t solve people’s problems.