Tristan's Blog

I attended DjangoCon EU in Dublin, Ireland last week. I got to see a few of my colleagues, and an ex-colleague, and travel throughout the British Isles. It was an excellent work + leisure trip. I came away from the conference with several takeaways. One minor lesson: don't judge a talk by its title! Looking ahead at the schedule, my group shared the sentiment that the talks seemed uninteresting. Still, we showed up and were very pleasantly surprised by the quality and depth of the presentations. Personally, I found a mix of both technical and non-technical wisdom.

Non-technical wisdom

One such non-technical takeaway was in the very first talk about code review in the Django project. The presenter described a common open source maintainer experience: a new contributor makes a pull request for a feature they want, and invests little-to-none in documentation and maintenance of that feature.

I have found this to be a pattern in software engineering culture. It's easier for engineers to write code than it is to communicate, let alone build consensus or change processes involving people. Engineers feel safe in the realm of impersonal code and machines, in metrics and passing unit tests. Interpersonal relations have no such safety guarantees: there's no compiler check that promises a coworker will do exactly as you instructed without blowing up.

But that's a topic for another day.

Attention footprint

As I interpreted the speaker, my attention footprint is the demand that I place on other's attention.

A classic example is asking to ask. A coworker messages me saying, "Hey, can I ask you a question about so and so?" and after I reply "Go ahead" they write the actual question. Typically there are several minutes of delay between message and reply, leading to rapid context switches, or just sitting idly while "X is typing...". Asking to ask puts a higher demand on my attention as opposed to writing out the desired question.

In the talk, the speaker was focused on how we can reduce our demands on others' attention. As the talk was oriented around code review, there were several suggestions:

Writing good pull request descriptions: the aim is to provide the necessary context to review the code. When I receive a review request for a pull request with a blank description, vague title and several dozen files of code changed, I have to go digging for the relevant context, try to divine the intention and reasoning of the changes. On the other hand, when I receive a request to review changes that are thoroughly documented, I'm able to context switch in easily and spend significantly less time reviewing.

I typically perform a self-review on pull requests. I'll call out specific sections of code that are sensitive and should be reviewed more closely. I'll also describe my thought process behind decisions (in instances where a code comment would be inappropriate, e.g. choosing a third party library or refactoring a function). This precipitates questions that I expect a reviewer to ask, based on my own experience reviewing code.

When I balance what I give of my attention to what I am demanding, it leads to better outcomes for me. When my pull requests are easy to review, they are reviewed more quickly. When I ask good questions, I get good answers more quickly.

Generalizing

I believe this lesson is applicable beyond code review. In my interpersonal relationships, am I listening as much as I am speaking? Am I communicating clearly, or am I expecting others to read my mind? Striking a balance, and paying attention to my attention, pays rewards in better, easier relationships.