Great developers design.

I’ve been thinking about how great developers do design. Not necessarily all aspects of it, but at the very least the meta-process that is design. Mike Monteiro, in his book Design is a Job, says that “a designer solves problems within a set of constraints.” From what I’ve figured out from talking to various designers recently, this seems to be a good definition of design to me. I think it’s necessary to take the same approach to write the best code you can to solve a certian problem. Or, even better, to figure out that you shouldn’t even write any code to solve it.

First, some definitions are in order. We’ll call design solving an ambiguous problem given a set of constraints. Programming, just for the scope of this writing, will be limited to solely the act of implementing an algorithm. I know that’s much more restrictive than what programmers actually do (which, I think, is to my point), but having a clear distinction will be useful for communicating about this. Also, one other caveat: I’m going to speak in terms of my impressions of programming culture sometimes. I know that’s not very objective, but I think in this case it’s useful, so I’m going to do it anyway.

I deeply believe the idea of programmer as implementer is bad for the world.

Most programmers have stories about bosses or clients (they’re effectively the same thing, really) who asked for implementations that seemed, to the programmer, stupid, if not utterly absurd. I don’t want to dwell on that, but rather use it as a point of departure. Let’s consider why we find ourselves in this situation. Why are clients (dropping distinction between bosses and clients for now) asking for things we consider stupid?

There are at least two potential causes for this. First, the clients might actually be asking for something stupid. This isn’t a very useful assumption to make, and it’s way too self serving. At the very least, it’s unprofessional to jump to that conclusion without significant consideration of alternatives first. It seems more likely to me is that there is a difference between the client and the programmer’s understanding of the goals and constraints of the project.

Some programmers, I know, are balking at this. I don’t know of anything polite to say to this, so I’m just going to say it rudely, because I think it deserves saying. Here goes:

You suck at empathy, and it makes you act like a bit of an asshole.

Kind of ironic to say something like that in a dickish way, isn’t it? I think (for some of us) it’s long overdue. The rest of you, I’m sure, will forgive (or at least indulge) me. See, there’s the bootstrapping problem with lacking empathy: if you’re far enough in the hole, then you won’t care enough about the impact on others to question your behavior when it’s mentioned in more nuanced ways. Hence calling (some of) you assholes.

Phew. That was an undesirable detour… Back to miscommunication about goals and constraints! Programmers are in a bit of an awkward situation here, because we are by far most intimately familiar with the constraints. So much that we become a bit myopic, I think. We (I do mean myself, too) develop a sort of tunnel vision that, when we’re not careful, makes us act like assholes (again, me too). The client says “The quux needs to gaarple like this.”, and we respond (or think) “That’s {impossible,stupid,crazy}.”[1] Remember that empathy thing? Yeah.

Instead, that conversation should go something like

Client: “The quux needs to gaarple like this.”

Programmer: “I don’t see why. Could you explain the need for that?”

Client: “Well, it has to gaarple just like that so that the user knows what just happened.”[2]

Programmer: “Oh, so we need to make sure the user has visibility into this aspect of the system!”

Client: “Yeah, that’s absolutely critical.”

Programmer: “Okay, well what about…” (here you describe an alternative that doesn’t have the downsides you perceive, and explain why they are downsides.)

Of course, most of us aren’t quite naive enough to not have some inkling of this already. Which is a really, really good thing. On the other hand, I think the value of this process increases non-linearly with respect to how many times you ask why, which is why I’m calling attention to this. Without deeply understanding the goals of the project you’re working on, you can’t come up with an ideal solution.

There’s one final step to this ethical argument. It’s a bit of a logical leap, but I get a pass on that because I’m calling it out, right? Right.[3] Here goes: you are responsible for the results of your work. Put more explicitly: every single bit of suck you put out into the world is on your hands. You remember those awful BSODs, and countless other awful experiences you had at the hands of other people’s negligence? Yeah. Don’t propagate that.

Be the change you want to see in the world. I know it’s cliché, but do it. Seriously, do it. Every broken window you put into the world tells everyone else it’s okay to produce shit. And it’s not okay to produce shit[4]. It’s all of our responsibility to tell everyone that it’s not okay to produce suck.

So, can you be a good programmer (by the absurdly restrictive definition I proposed) without doing design? Yes. Of course you can. On the other hand, most of us don’t want to constrain ourselves to that definition. I think that obliges us to reach outside your comfort zone, and deeply understand the goals and constraints of the problem we’re working on, and work for ideal solutions to them. I think this is our responsibility as humans contributing to the way the world will work in the future, not just as programmers.

Maybe that makes me a bit crazy. If so, I don’t care. It’s my central to my morality, and I’m going to live by it.


  1. I suspect we’re more likely to say, rather than think this, or have a more extreme opinion, whether it is expressed rather than just thought, as employees, or novices. With experience and freedom a bit more understanding of nuance seems to develop.  ↩

  2. The reason doesn’t matter much for this explanation (and often enough, even for your work).  ↩

  3. LOL.  ↩

  4. Except in certain well defined contexts, many of which involve porcelain.  ↩