Introduction
In Part 1 of this series, we talked about how we need to take into account personal and human aspects of our all-remote life that are not about just business or our careers. We also pointed out that being a software developer is a privilege, and that we have the opportunity to contribute to society while sitting at home and applying our knowledge and creativity. Challenging times are often the right moment to re-examine what we take for granted. We believe there is room for improvement in our software development processes, and now is a good time to start. In this article, we will begin to look at what drives dev team performance, and how our culture has been resistant to adopting a more collaborative approach for historical and competitive reasons. We will describe ways in which we, at CodeStream, have learned to tackle these issues and the impact we are seeing as a result of our approach.
We don’t collaborate enough
Over the past two years, we have talked to about 2,000 software development teams in an effort to understand how their toolset, their workflow, and the opportunities for performance improvement. If you are like over 80% of the teams we talked to, this is what your toolset and workflow look like:
The team plans the sprint on a Monday and developers mostly stay focused on your assignments until the end of the sprint, usually a week, with relatively little collaboration until the code is done.
You ask questions ad-hoc, sometimes to the developer sitting next to you, sometimes on Slack or Microsoft Teams. Mostly, though, you just try to figure it out on your own. There are no incentives to collaborate, other than at code review time.
You use GitHub, GitLab or Bitbucket for version control and code reviews.
You assign work through Jira, Trello, Asana, or something like it. Most often, all assignments start in your task management service. You complete your assignments largely without collaborating with anyone on your team.
Overall, you have little visibility of what your teammates are working on at any given moment.
If this seems right, it all makes sense because we are so used to the process. What parts of this can be improved upon in an all-remote mindset and context? To start with, how often do you check with your team or your reviewer on whether the feature you are starting on is on the right path? How often do you suggest a change to a teammate to improve code quality? If the answer is rarely, or even just once or twice a day, you are not optimizing your process for collaboration purposes. In particular, if you are used to resolving issues by just tapping someone on the shoulder or asking out loud in a room with your teammates, a new approach is required. Let’s tackle each of the bullets above through a collaborative lens.
There is no shame in asking
Most developers take pride in solving problems on their own. Perhaps it’s a badge of honor, or given the fact that we live in a competitive environment, it feels like asking will reveal some weakness on your part. As a team, at CodeStream we have created incentives to ask more questions more often, and we reward this type of exchange in public, reporting participation on our weekly all-hands. A customer of ours is planning on tieing part of the developers’ bonuses to the collaborative contributions made, whether asking a question or providing an answer. You should consider how your organization can promote more openness in code discussion.
Still, in a remote setting, the tools commonly used today for code discussion are particularly sub-optimal. Using something like Slack or MS Teams results in ephemeral exchanges that do not add to the collective knowledge and require significant effort to provide the context that was stripped away by copying a code block and pasting it into a chat stream. Further, since the question itself is likely to quickly scroll off the screen never to be seen again, these solutions don’t offer the persistence and accessibility needed in an asynchronous remote world.
We built CodeStream to solve this by attaching questions and replies to the code block(s) they refer to and then sharing this in Slack, MS Teams or email to leverage your existing communication tools. CodeStream is the in-editor bridge that makes these discussions more frequent and more useful to the whole team.
The pull request is great. For code reviews, we can do better.
Virtually every modern development team we have talked to since 2019 performs code reviews using the built-in tools of GitHub, GitLab, and BitBucket. Large organizations like Google and Microsoft have developed their own tools to conduct code reviews that are not PR based. At Google, they have standardized on a uniform toolset with a strong focus on speeding up reviews by making them as small as possible. Google reports that its average code review is just 24 lines of code and gets turned around and into production in 4 hours or less.
We believe they have the right philosophy and the right results. There are many benefits to small and fast reviews. Productivity increases, frustration is reduced, small mistakes don’t turn into large messes, and perhaps most importantly it allows larger teams of developers to weave changes together with minimum conflict. What does it take to make this happen in your organization? Pull requests don’t make it easy to review code. To start with, reviewing code in a browser instead of the IDE introduces the same type of context problem we discussed above with Slack, an unnecessary context switch. In addition, much frustration and effort can be eliminated by asking for reviews early and often, even on uncommitted code.
At CodeStream, we have built a solution that makes this super easy. We just package every change made by a developer in their editor, organize it and size it, and let the developer decide which parts to submit for review. The reviewer can then see all the changes in context, in their editor, attach comments as necessary, and approve or reject the work on a file by file basis. Our team is now conducting 10+ reviews per day per developer, and our velocity has increased by over 20% since we started this process.
Transparency and visibility
Working remote brings new challenges in the area of visibility. Not only can we not see each other in the office anymore, but it’s harder to work towards alignment without the right tools. In order to get the right visibility, we must start with a philosophy of transparency. In an all-remote world, we must choose to let everyone see what we are doing because without it there is too much friction and we lose traction. GitLab has famously included Transparency in their Six Values. How do you implement transparency in your development process to get everyone on the same page? We will tackle that in part 3 of this series.
Top comments (0)