sTool Request

Every developer is familiar with Pull Request, however recently I came across another useful practice – “sTool Request”. sTool request is a simple and powerful practice yet some, especially junior developers, hesitate to use it; at least I noticed the behaviour in my team and so it is a good time to talk about it.

Unless your team is practicing pair programming, everyone tends to work alone and often the only time you get to see work of another developer is at Pull Request time. While it is generally a good thing, there are few drawbacks:

• Effort has been expanded – sunk cost bias has already kicked in
• Work is completed – physically & physiologically – let’s move on to the next thing
• Code has settled – mistakes are more expensive to fix
• In case a bug is discovered at a later point, it is harder to figure from the original developer – rarely anyone remembers details of decision making and code several weeks back.

sTool Request can help remedy those issues to some degree, at the very least it is cheaper to brainstorm/discuss questions, issues and ideas prior to producing code, and/or at any point during the work. So here goes my proposal to a team:

“Got a question or a doubt? Perhaps you want to bounce ideas around? Ask a team member to grab a stool/chair, sit down and help you out. Use the momentum to have a rich conversation and/or debate. Don’t wait for PR (Pull Request), refactor card, or a bug report. We are all on the same team, working together to deliver team’s goal, improve quality and learn new things.”

I would love for people to pair program, but in the absence of the practice, it is useful to invoke “sTool Request”, summon a developer and work things out. There are so many times I though to myself: “if only a developer have asked prior, he wouldn’t have made those mistakes and also learned a ton from the experience”. It is harder to learn retrospectively, it is better to learn in the moment.