Looks like my day reviewing Jira tickets and checking the PRs
That’s how we do it too.
I have a extension in VS code that connects to Jira so when I open a new task it creates an appropriately named branch and adds the ticket name and number to the release and commit etc automatically.
That sounds clever - wish I could do that with Trello… 
We do buddy coding where I work to ensure the code to be deployed has been peer checked ahead of going live
The “by monkeys” construct is great. It had me reading the Tone of Voice article again and chuckling
@Sachaz @Ordog I am a fellow user of Jira, so I am interested in your respective approaches for purely interest’s sake
When we first moved to Jira we still were configuring code in our old big bang CM system, still there behind the scenes, so it was more about coordination
Later I was able to shift us across to Bitbucket for day to day work and for a month or two we did the reviews inline on the Bitbucket PRs, which was much better than what we had, but not the most satisfactory experience
Later still (though only a month or two that time) we moved to performing reviews in Crucible before raising the PR in Bitbucket, which is really a final check now before merging into the main branch
(This is still all linked together by Jira which can see the reviews and PRs in the other tools within our Atlassian toolset)
Are your PRs in Bitbucket? Do you do the reviews in the PRs through choice or lack of choice? Anything you do “out of the ordinary”?
My personal favourite Jira feature thus is probably Releases. Yours?
As a Product Manager I don’t actually review code but before approving any deployments I make sure each JIRA ticket has details of the PR. Ideally we would be in a position to do rigorous unit testing and when a PR is approved, automatic deployment to production but we are heavily reliant on a mixture of automated regression and manually testing.
Good PRs also help identify the root cause of potential live service issues.
Another use within the Payments team that wasn’t mentioned here.
When we write code to follow a specification, we always quote the specification itself. For example
// 📄According to the Mastercard Customer Interface Specification, chapter 5 as of 1st of October
// (...) DE-108.1 is not mandatory for Money Send transactions (...)
The above is made-up, but it’s something I would comment with. Makes it much easier for an engineer to understand why that code is there, and that it wasn’t a Monzo decision, but a spec implementation.