Social Coding — better. faster. stronger.
By Sasha Yee (Back end developer)
Social coding is an approach to development that places an emphasis on formal and informal collaboration.
How it began
When I was paired up with Wayne to build How Fit Feels (an experiment being run by Fitness First which seeks to find out if fitness really is more than skin deep) - we had to decide on a library to use to build it.
He was keen on using React.
Based on the complexity of the brief we felt like it was a good project to try the new technology.
It’s a tool quite fresh to the dev team at MF and we were not sure how to utilise it to its full ability, or even if we would be able to deliver on time with the learning curve attached.
This is where social coding comes into full effect.
Introducing our friend, git
What is git?
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
That’s the official definition, basically it’s a tool used as a means to keep track of changes to a development project. This can be as simple as fixing a typo to adding or improving a feature of the software. Along with the changes that have been made to the project you get:
- A record of who did the changes,
- the time of when the changes were made
- and the best part — a message that helps to explain what the changes did to the project and why
Git tools are great as it’s possible for multiple users to all work on the same project at the same time.
To avoid stepping on each other’s toes it’s possible to each work on different copies, called branches, which can eventually be brought back into the main version of the project.
To bring the changes that Wayne and I created back into the main version of the project we used a process called a pull request.
It results in the team checking the work they are producing before it comes back into the main part of the project.
Pull requests allowed us to see each other’s work as it progressed and let us make comments and request changes to the code before it gets merged back into the main project.
This meant challenging each other’s work and prevent bad work from being brought into the project.
Since we were reading each other’s code before it was being merged back into the main section of the project we are able to see how the different each others working style was and how they solved problems.
Subsequently, more richer content was being produced in the comments attached to the the code. More questions were being asked and more clarification was being sought on decisions that previously would have gone un-checked.
Increased communication always results in better work.
The comments introduced an ongoing conversation- something that would usually be reserved for check-ins and project retros.
This sped up on both sharing knowledge of new learnings and also shortcomings that could be tackled earlier to avoid roadblocks.
We also had to consider how each member of the team thought something should be built, also the justification of said opinion.
Our understandings were also to be tested. We had to ensure that the team was testing our understanding as we went along and not get stuck going down a particular route without realising we were headed that way.
Bringing the client into the fold
With this process in place we had a higher reliance on each other we needed to introduce a structure to review the pull requests.
This resulted in more communication with the client on our working methods, so that changes they requested were going through a system, rather than being bashed out as soon as they were being requested.
Social coding is for me
The added reliance on each other lead to some initial loss of speed during development, however as we it became part of our process it gained momentum over time.
We were able to learn together faster and receive help when needed. We learnt a new technology and ensured that blocks along the way were simple hurdles, not a car crash.
Enjoyed this article? Here is another