Continuous code review with GitHub and Slack
Taking ownership, respectively responsibility has been a major requirements in startup jobs for a long time; in particular, code ownership. Cunningham & Cunningham on c2.com, one of the earliest Wikis, quotes the following sentence with regards to code ownership:
Each code module in the system is owned by a single developer. Except in exceptional and explicit circumstances, code may be modified only by its owner.
Establishing formalism about who is allowed to modify code does not necessarily help with code quality. Much more important is how comfortable you feel with the changes made by your colleagues on the code of the company or software project you are working on.
After all they will impact you nonetheless. It is an easy path to simply not care. It takes effort to look at code you haven’t written. Code reviews are supposed to introduce a more formal approach to make this part of the process:
Egotism and urgency make it hard for a person to see their own errors, so it pays to get someone else to look at what you are doing. However, most people will hide their mistakes from their manager or anyone else higher in the organization.
Small startups live in a fast-paced world always short on development time. At Mixlr I found it really useful to sit together with one of your colleagues and go through the changes of a pull request before merging it. A second pair of eyes is great but there is always room for improvement. GitHub makes it really easy to comment on the diff of a pull request.
Sometimes changes, pull requests or comments go unseen. Slack is not only a great tool for direct communication for me its main purpose is utilizing it as a dashboard with all of its integrations. The GitHub app for Slack will post commits, pull requests, and activity on GitHub Issues to a channel in Slack.
The idea is to introduce an automatism into your daily workflow. If a commit is made or pull request is opened:
- Be curious about the change
- Try to understand the code
- Join the discussion
- Ask questions
It is important to internalize that this idea even applies if you are completely unrelated to that part of the project or don’t event write code in the language used. Many would be afraid they would unintentionally annoy their co-workers but if you think about it we all like learning and teaching each other about software craftsmanship. This is the type of curiosity which not only gives more freedom to a less formalized review process but also a healthy working culture.
Clearly, for this to work one needs to motivate themselves daily to inhibit such a culture. The tools can only help to accelerate the present potential not create it in the first place.