A Dummy's Guide to Leading Teams

Pull Requests 🔗

PR’s are a valuable part of code quality assurance, a good way to train junior members of the team and give other team members insight into parts of the codebase they aren’t working on. But as with everything, it aint worth doing unless you’re doing it right. The aim of the game is to keep code as clean as possible, and we can do this by taking as much mental load from developers so they can focus on developing.

One of the things that the Jira Bug Fixers and Platform 6 team found really difficult was flaky builds. We would put up a pr in an area we weren’t usually familiar with and would almost always find multiple builds failing. This made it very difficult to have confidence in our code or trust the pipelines that were there to help show us when our code had caused regressions. This meant basically re-running builds until they 🪄 magically passed sometimes… not good.

Fast forward a few months and we’re starting to work on the Atlassian Frontend repo where they keep components for reuse in their products. We put up a pr and are greeted by an array of automations set up to speed the process up and make sure reviews were thorough. The git history was used to find who had written code in the same area and automatically add them as a reviewer. They had apps that would check your code for security concerns or code smells, and used Landkid to avoid merge issues by creating a merge queue and rebasing your branch on master automatically.

Not all was smooth sailing in the land of Atlassian Frontend pr automation: every time it detected changes across multiple files, all of your reviews would be reset. This happened a lotttt and meant it was very common to have to badger people for re-reviews. A good idea in theory, but because the threshold was too small on how many changes needed a re-review, I feel like you could’ve been tempted to avoid answering NIT comments just so you didn’t have to badger people again.

PR Templates 📑

In our AI project we used PR templates, and it was a pretty big win — so something I wanted to take over to our academy project. When you go to put up a pr, there’s a template there for you to just fill out. This makes sure pr’s have enough detail in their description and that they’ve thought about everything they need beforehand, for example testing and security. One more thing for developers to not have to think about.

Don’t leave designers out 😢

Something that was slowing us down was having to set up meetings with the designers once or twice a week to run the product for them and let them check over our changes. The real issue was that designers were being left out of a crucial part of the review process and couldn’t easily, incrementally critique our front-end changes.

The idea was to run preview deploys in our GitHub prs and add the designers to them. That meant we didn’t have to run the product on each branch every time, and they could ask for adjustments at the pr stage instead of a new ticket being created for lots of little design changes. The only trouble is that deploying a preview on every pr can cost a lotta dolla — so in the AI project we only ran the deploy-preview workflow when we added a label, which worked really well.

Stop sending me messages, GitHub 🚫

A lot of teams have GitHub set up to automatically post a PR link whenever the PR is opened, and again when it’s merged. Call me a bad person, but I rarely saw that message and immediately went to review. Instead of context-switching and breaking focus on my own ticket, I’d set aside time in the day to review prs. Those massive messages were also clogging up the channel, which meant I was missing important messages!

How did we try to fix it? We used Slack Reminders to have Slackbot send us a message twice a day — once before standup (9am) and once at the end of the day (4pm) — with a link to our prs. These times were chosen so we could start and end the day reviewing, without jumping back and forth, and so the author could do a QA demo in standup. Stroll send these to a separate channel, which is a good idea to avoid cluttering the main team channel.

CI/CD 🚨

There’s a lot of argument about what should go in your CI, how it should be ordered, and what is actually of value. Here’s what we used, which ran every time someone pushed code.

Tests ✅

Hopefully not much explanation needed: every time a dev pushed code it ran our entire test suite to make sure the changes hadn’t caused errors somewhere unexpected.

Linting 🧹

We used ESLint to keep good code patterns.

Prettier 💅

We used Prettier to make sure our code stayed consistent across the team.

Lighthouse CI 💡

We used Lighthouse CI to review our pages and bring back a report with scores and recommendations for performance, accessibility, SEO, best practices and PWA. A really helpful tool that picks up on little things you forget about — although while a page was only half-built the scores were terrible, so we turned off the score assertions that would fail the build. Lighthouse took ~7 minutes across our 4 pages, so to save on GitHub build minutes we only ran it when we attached a label, after all comments were resolved. Apparently there’s a much easier way to do this with a Lighthouse CI GitHub App… oops.

Restrictions 🚦

We used two merge restrictions: prs could only be merged when 2 or more people had approved, and when all builds had passed. This made sure code was thoroughly checked and that everyone got to see more of the codebase. On a team of 4 this slowed things slightly, but with set review times things still merged within a day — a worthwhile trade for the learning. We discussed CodeCov but decided against gating on it, as we didn’t want to write low-value tests just to move a metric. We also considered Snyk, but the free tier only gave 100 tests a month.

Teamwork = Dreamwork 🍻

The requirements for pair programming are minimal: two developers and a shared editor. From the “Ping Pong Pattern” to much looser forms, they all share two things: turn-taking and open communication. Pairing is a great way to learn or be onboarded — developers share domain knowledge and best practices, and fewer bugs reach production because errors are caught as they’re typed.

A few things to bear in mind: it’s easier to burn out when pairing, so set timers and take breaks. It’s not something you can force. It’s highly social, so watch for pairs that clash. And it’s easy for a senior to take over and leave the junior doing nothing — which defeats the point. Pairs need patience with each other.

Ways of working doc 📄

A set of guidelines outlining the processes, practices and principles the team follows. It serves as a reference for how work is organised, executed and delivered — typically covering the development process, roles and responsibilities, communication, tools and environments, coding standards, testing and QA, CI/CD, collaboration, retrospectives, security and compliance, and onboarding.

Leave-me-alone time 🏝

I’d seen this on one of those “day in the life of an SE” videos and really liked it. As a team we mapped out two 2hr+ blocks of “dev time” where we don’t schedule meetings or anything that would make devs context switch. It let everyone spend that time uninterrupted and be much more productive.

Don’t-leave-me-alone time 🥹

Working as a team is key to a team being happy and successful, so one office day a week was a good chance to get together in person. There was no pressure to come in — we didn’t want anyone to feel guilty if they couldn’t make it.

Standup is for more than just tickets 🤝

Standup is a good opportunity for the team to get to know each other — a team that can talk about their lives and have a laugh in standup is a team that works well together. Don’t take it too seriously: get someone to tell a joke every morning (thanks Hannah McKee!), and don’t cut standup off 10 minutes early to kill the conversations that actually make your team more collaborative.