Take Shame in your Work, Not Pride

5 minute read

I used to take pride in my work, especially building software, but I’m learning that’s actually a problem. Building something great can actually get in the way of doing something great. Before I explain, here’s a couple examples.

You Heard of the $400 Squeezing Machine, Right?

If not, this is the summary: a Silicon Valley startup spent over $120 million to make a super high-tech, WiFi-enabled device that… squeezed pre-packaged containers of juice into a cup. The Juicero machine itself was a masterpiece of engineering, but it was totally useless. You could squeeze the packages of juice by hand perfectly fine.

My RideBoard App

While I was at university, I got a job at its Office of Information Technology as a student programmer. Our manager asked us students to make some small apps for the website, and mine was called “RideBoard”, basically the exact same idea as RideShare just a couple years before it was popularized.

I spent months working out the trigonometry, coding it, unit testing it, having it reviewed by coworkers and making sure it met all their requirements, deploying it to staging… only to learn that whoever chose what was “ok” on the school website and what wasn’t was unwilling to actually make it live. Me and my manager never actually inquired if this was something the university was willing to host (I didn’t even know who made that determination), and it became increasingly clear they weren’t. It really shouldn’t have been started in the first place.

The Results of Taking Pride in Your Work

I think it should be clear that in my two examples that people were taking pride in their work, but it was still a disaster. In fact, taking pride in their work was a hindrance, not a benefit.

The Juicero team was so focused on making the best machine to do the task that they forgot to ask “do people need a machine to do this in the first place?” Me and my manager spent so long making software that jumped through all the technical hoops, we forgot to ask if the school administrators would let the app be put on their school website.

In practice, “take pride in your work” is equivalent to “myopically focus on one thing to the detriment of everything else.”

Why Are We Told “Take Pride in Your Work” Anyway?

Before I continue, let me acknowledge that there are situations where “taking pride in your work” has a place.

Taking pride in your work makes sense when your choice is between working on one task or doing nothing at all. Like a teenager doing homework: if they weren’t doing their homework they’d probably be watching TV. It makes sense to encourage them to do the best job they can.

But when you have many tasks that need to be completed, all of which have some value, taking pride in your work on one task means ignoring the others. Like a college student who has math homework and physics homework due: “taking pride in your math homework” could mean not getting your physics homework done. So “take pride in your work” isn’t universally good advice.

Code is not poetry

The WordPress software project has a motto: “code is poetry,” meaning software can have something artistic and beautiful about it, in which we can take pride.

But one of its influential contributors, Boone Gorges, remarked that attitude can be damaging both to the software and the humans making it because it overvalues the code while devaluing its effect.

software developers invested in an image of themselves as artists are more likely to shun collaboration, iteration, and criticism, an attitude that’s especially harmful in free software communities.

Boone Gorges, The Pernicious Myth of the Code Poet

All Code is Technical Debt

As developers, it’s tempting to think we’re creating value by writing code. Actually, our work is just begetting more work.

The more code you have, the more work it takes to maintain, and the more complex it becomes to understand and modify. More code is actually a burden, not a blessing. Some call poorly written or old code “technical debt.” But all code requires updating, or it becomes outdated, ugly, and old. So really, all code is technical debt.

The only sure-fire way of avoiding technical debt is to not write code in the first place. The only way to mitigate it is to write as little code as possible.

As developers our first instinct is to solve a problem by coding, but that’s not always the best strategy. Often times, we need to push aside that knee-jerk reaction. Throwing more code on the fire sometimes only fuels it further.

Your Work Will Be Thrown Away

In order to accurately value code, you need to come to terms with this fact: it’s going to die.

Someday, someone will need to throw your hard work out the door. Either because of its success (expanded requirements, next version) or failure (so it will he shut down and forgotten), or they’re just a different developer, and new developers usually throw out all the work of previous developers (source: Dilbert). Regardless: accept your work will eventually need to go away. Prepare for that.

Explain your code, but let it die.

Actually, the best code plans on its demise. It documents its quirks. It is modular so that it can be repurposed… but it’s not perfect.

The Impossibility of Keeping Up with “Modern Best Practices”

When developers have little influence on anything other than how software is made, they can sometimes “take pride” in having it meet what their peers proudly call “modern best practices” and using the coolest new technology. This can be the impetus for complete rebuilding of software projects, taking years, with no visible improvements to actual users. It’s also often a waste of time, and never-ending, impossible task.

Staying at the bleeding edge of technology takes so long that by the time you’ve finished conforming to the latest trends, those “modern best practices” have changed and those cool new technologies are now old.

Pride in the work is important for quality and morale, but we need to direct it at the right target. If we aim for an ideal perfect design, we’ll never get there.

Ryan Singer, Shape Up

Take Pride in the Result

We want to take pride in something, everybody wants to excel at something. But just “the work” shouldn’t be it. People only advocate for that when they’re totally removed from the end result and have no clue if their work actually achieves its purpose. It’s far better to take pride in the end result.

When people are intimately aware of the end result, and have a say in what work is done, they do much better, much more appropriate work. Will their software be used to land a shuttle on Mars? Test it to death. Will it be used to squeeze a juice packet? Get it built ASAP and see if it actually sells.

It’s best if the developer is involved in and sees the final product. If they’re locked inside their code cell, little wonder they’ll start obsessing over it to the detriment of everything else.

The time spent “taking pride” in one detail could have been spent doing something else. There should be a justification for why focusing on that particular task was the right choice. And if there isn’t, it’s only a distraction and a waste of time.

Don’t take pride in your work, take shame in it.