I’ve had a couple of interesting conversations recently where people have expressed frustration that non-technical people involved in product development were either “not communicating” or “not thinking around the problem enough”. In a couple of these conversations, I’ve had to articulate quite clearly that I think this is a fairly wrong-headed approach to this problem, because what it’s really doing is highlighting the different ways that technical and non-technical members of a technology department access information regarding how software works.

As a developer, always remember this:

If you are *ever* confused about what some of the software you work on does, you have a simple, irrevocable crutch. You can read the code. You can read the commit log. Nobody else gets to.

It’s worth remembering that before you jump to the conclusion that somebody just hasn’t been paying attention, remember that it’s likely that the information you have available to you, just isn’t available to them.

Think about the myriad of ways that you screw up communicating information to your peers on a day to day basis. Now imagine, that instead of being able to “just check” something, you have to take it on faith that something you have been told is accurate. It’s frequently not the fault of the people that don’t have access to the information you have available to you.

And you know what the one sure fire way to correct this behaviour is? Don’t get mad, don’t get frustrated, tell them. Help them understand, and if they’re amiable to the idea, show them the code too.