As CTO for GoFundraise, it is my duty to ensure the software codebase is maintainable and extensible for years to come. All new developers must have a guide on how the team must operate.
A key piece of the cog is the peer coding. I am sharing the process for peer coding we have employed with great success at GoFundraise.
We are a small team of less than 10 Engineers (remote) who work well together and are highly cohesive in what we do.
This guide can help startups and large organisations with dedicated teams of similar size.
Aim
The expectation is that peer coding will not only help with improve the knowledge share between Engineers, but it will also play a vital role in speeding up the delivery of the tasks.
Why?
Currently with the existing process, it was noted that there is reliance on one or more Engineers at any given stage of a task. Whether this is from the beginning of doing the work or up to the end where it is ready to be rolled into production. If one person is working on it, they end up being blocked by others if and when they rely on them to move the ticket along. As a result, having multiple people work on a ticket will ensure all steps go through from start to finish without other items taking priority.
When?
Proposal is to peer code when the ticket is 5 story points or more. 5 Story points is assumed to be a 1.5 days task. This should ensure we peer code on something that is not too small which can be easily handled by 1 person.
How to Peer code
Start with an introduction of the ticket together and work out all the parts of the ticket that will be touched. Discuss and identify the parts of the ticket
Use Jira to add all the information discussed so nothing is lost
Work out what are the parts of the ticket that need to be handled. This will allow you to better delegate the work items between you and your partner E.g.
Testing and environment setup / configurations
-- Front end changes
-- Backend changes
-- AWS infrastructure changes
-- Database changes
-- Documentation changes
Before starting to write code, identify if it can be broken in a way so that it can be written by both devs.
Is there an interface that can be agreed on so that one person can wire up the interface and one person can do the actual implementation?
Is one person able to write appropriate unit tests as to make them fail that way the other can write the code to pass it?
Working together means to be in regular contact during the development. Either time box couple of hours at a time where you can work together over a teams call or do regular check-ins with each other until the task is done
Focus is on the task you are working on and nothing else. Do not get side tracked by taking another task. If you are unable to focus on the task, you will need to reach out to the scrum master and work on what is getting in your way
The job on that task is finished when you complete it end to end which includes, coding, code review, testing, verification from business and ready for merge / rolled into prod
Make sure to add the time worked on the ticket in tempo
Top comments (0)