Live data from Hacker News

Push and Pull

kellanem.com

11–15 of 15 posts

Re: Push and Pull

#11

I don’t really understand the pull. It sounds like push is the shoulds and pull is the musts. As far as I understand it, push is the ‘do X’, pull is the ‘hold accountable when they don’t do X, or praise when they do’. But these seem as two sides of the same coin, not as orthogonal concepts.

They’re not orthogonal and I don’t think they’re claimed to be. The biggest differences I see are about time and generality.

Push is a about something general and in the future. “Every week, put in a status update.” and “As PRs come in, review them as soon as you can.”

Pull is concrete and about something in the past. “I saw in your status update yesterday you’re blocked by the auth bug.” and “Let’s start the meeting by checking our PR queue.”

Phrasing it like that, it makes it obvious why pull is underserved. People in general, especially software engineers, love talking about the general future. In almost any software process, there’s a huge advantage in giving more attention to the concrete past then it gets right now.

The team that I’m on starts every weekly team meeting on Friday morning with “positive shoutouts”, where we just say good things other people did that week. Concrete, past, positive. Great way to start a meeting. (It is also a “low politics” team, so I have yet to see much gamesmanship.)

Re: Push and Pull

#12
post #2

> You should review PRs, you should review them in a timely fashion. You should, you should, you should. That’s all Push. Any wonder that so many teams struggling with PR dwell time? The problem with this is nobody is performance managed on PR reviews. Features are often what get put on performance reviews, so it becomes beneficial to the PR author to go work on another feature than review someone else’s PR. Reviewin…

My company tracks PR reviews. They aren't tracked in source code (and to my knowledge source isn't used as one of the metrics).

Re: Push and Pull

#15
post #2

> You should review PRs, you should review them in a timely fashion. You should, you should, you should. That’s all Push. Any wonder that so many teams struggling with PR dwell time? The problem with this is nobody is performance managed on PR reviews. Features are often what get put on performance reviews, so it becomes beneficial to the PR author to go work on another feature than review someone else’s PR. Reviewin…

don’t companies like amazon track the number of PR comments as a metric?
Post reply on HN