There are many people who would likely say I don’t handle some social sitations with the utmost grace, and they wouldn’t be wrong. I’m human and my emotions can get the better of me more often than I would like. Nevetheless there are interpersonal values I hold dear as I work with other people in the day-to-day.

During the time I worked with Jason Kerney and Willem Larsen, we sunk a fair amount of effort into discovering better ways to work together. Over time we ran many experiments and had varied results.

Side note – if you never have failed experiments, were they experiments? Perhaps this is another post.

Anyway, we had experiments that succeeded and experiments that failed. For software developers successes can feel hollow when they are not part of a visible feature, and failures can feel like a blow to the ego.

What kept our team afloat through the roller coaster ride were the values we held. Since we held our values more closely than any one success or failure, the successes felt less thankless and the failures felt more educational. Ultimately, we made the entire process about people, and this is what shaped the values which I still consider core to healthy interactions with my coworkers.

The values we landed on before we all went our separate ways (work-wise – we still talk) are as follows:

  • People over code
  • Tensions over problems over solutions
  • Acceptance before alternatives
  • Leadership through expertise
  • Guide, don’t dictate

I shared a photo of the note cards I keep on Twitter and people felt a little baffled by the meaning of items on the list. This post is my way of expanding the pithy aphorisms and making them digestible by people who are outside of our immediate circle.

People Over Code

In any work I do with another developer, I always prefer to consider the person I am working with over the code we are writing. I am more willing to throw away code I have written than throw away the relationship I am building with my coworker. Their trust is worth more to me than any disputed chunk of code.

Tensions Over Problems Over Solutions

This one may seem a little more cryptic on the outset, but it actually follows pretty directly from the first value. When discussing an issue, prefer to discuss the feeling you have (tension) regarding the issue at hand. If you aren’t able to provide insight into the feeling, then an example of the problem you’re encountering may be appropriate. If the previous options are not satisfactory, then, and only then, offer a solution.

Tension Example

An example of surfacing a tension might look like the following:

“I understand, mechanically, what this code is doing, but I really don’t know why. How does this relate to the bigger task we are working on?”

There is no specific problem here. There is no statement that there is a specific “problem” with the code, there is just a feeling that some understanding is missing.

Problem Example

If surfacing a tension isn’t enough, sometimes a problem will help solidify the idea.

“As we look at this method, we have to scroll past the edge of the screen to see everything and I lose track of the task context. Is there something we could do to make this better?”

This is more specific about a particular problem. Though this could be great if the concrete example is the only issue you have, but if it is merely an example, people might try to solve this problem without thinking about the bigger picture tension you have.

Solution Example

Sometimes people need a nudge to get their problem solving brains in gear. This is where solutions come in. It’s important to note, solutions are a last resort, not a first go-to.

“This method is really long, I’d like to break it into smaller methods. What do you think?”

You’ll note, this still leaves room for others to provide thier thoughts, but it offers a solution which people might be able to follow if nothing better comes along.

Acceptance Before Alternatives

Acceptance before alternatives comes directly from the improv idea of “yes, and.” The aim with acceptance before alternatives is you listen and accept that the person you are talking with is bringing something to the table. Once they have said their piece, start by accepting it.

“I see what you’re saying. That method is really long, and it’s hard to see on one screen.”

Then, if you disagree with the proposed idea, you can provide an alternative.

“I understand you might want to put in folding regions* for the code there, would you be open to extracting methods instead?”

By offering an alternative this way, people are more likely to feel heard and understood. The discussion becomes less about ego and more about the advantages and disadvantages of a given approach.

  • Folding regions are a way to tell some editors that a chunk of code goes together and can be folded to allow other code to fit on the screen.

Leadership through expertise

This value is a bit more fiddly than the previous. Though the words mean, by dictionary definition, what you might assume, together it’s important to understand that this is not meant as a club.

Leadership through expertise comes from the notion of a civil anarchist state. If we assume there is a power dynamic between people on a team, but there is no structured governing body, the team is guided exclusively through a shared desire to produce a software solution.

This means the person with the most expertise in a particular area can provide leadership through service to the rest of the team. No one person will be an expert in everything and each person is likely to have more expertise in a topic than anyone else.

If we view “leadership through expertise” through this lens, then leadership is a servant position and expertise is the means of service to the team. Rather than being an appeal to authority, it is a way to facilitate guidance.

Guide, Don’t Dictate

Guide, don’t dictate is the last value and it largely provides the way in which people can work together. As the “expert” title moves from person to person in the group, the way to smooth the handoff is through guidance first. If the expert is leading and leading is serving, then guidance is the tool they use to serve the team as others work toward completion of a task.

Conclusion

Each of these values, ultimately, is centered around the idea that I work with people and people are what drives the work. All the values do, for me, is provide me with a path toward better, healthier interaction with my coworkers. Hopefully you find these values useful and, perhaps, create some of your own.