Our world is in a state of emergency. Today’s uncertainty and ambiguity means we can’t assume everybody can be back in the office shortly.
And truthfully, this is an opportunity. In the office, informal technical communications covered for many weaknesses. Technical skills that were good enough in the office won’t work well in remote work, where informal communication is limited. Excellent technical skills, however, allow developers to communicate informally through the code.
Beneficial? Yes, but not strictly necessary. At least when we were in the office. Now it is very necessary.
Easy Problems are Now Hard
Many problems that developers recognized and solved everyday were natural to do in the face to face environment. However, now we are working with the coronavirus lockdown, thus remotely. Now those easily solved problems have become challenging in the remote environment. Here are just a few examples.
In the office, design collaborations come together organically, normally in front of a whiteboard. Additionally, the discussion by two people gets overheard by other developers. Consensus develops for the design techniques and approaches for that code.
Remotely, your team needs to find a way to accomplish with intention something that was organically natural to them before.
In the office, code reviews, stand-ups, and conversation drive the discoveries of the most common bug mistakes.
Remotely, your team needs this conversation thread to be intentionally developed in stand-ups. While it is possible to mention in Slack a common bug, that is also an intentional decision and action. This has a much different way of thinking than an organic conversation.
In the office, individual epiphanies often drive domain insights, sparking more epiphanies. Also, domain insights frequently happen from conversations with stakeholders outside the development team, such as the customer, managers, customer support, and sales.
Remotely, your team needs a way to have the space necessary to have the epiphanies. The remote setting increases pressure and expectation to simply produce. Coffee conversation or the whiteboard wandering at the office naturally occurred, but at home it’s now a point of “waste”. This leaves little space to even have the insights, much less share them. The results are different parts of the code being written in different ways.
Additionally, the team and the business need to establish new norms for between-team communication. Normally solved by hallways and lunches before, now everybody is in their own silo.
Slow Down to Go Faster
The key takeaway from these once-easy problems now becoming hard is the lack of organic time and space that is naturally present in the office. Remember that 2.5 hour of office time equates to 1 hour of remote time. Many of us breathe a sigh of relief to lose the interruptions and get focus time. However, developers rely on those natural collaborations to ensure quality production. The great trap for them is staying so busy cranking out code individually that they don’t even see the round wheel.
So what can developers do to get that time and space to solve those problems?
Learn, Solve, and Code Simultaneously
There are lots of ways to slow down, but only some will help you go faster. One of those ways is to create coding habits that give developers a structure for every tiny decision they are making. If they use the habits that Deep Roots offers, they will additionally learn how to code better with each of those decisions.
Below are examples of how tiny habit shifts can make those now-difficult problems easy again.
Simply tagging commits according to the level of risk communicates design intent with the team and simplifies those commits. This reduces the number of code reviews required to keep the design on the same page. Below is an example of the final shift in Deep Roots’ Refactoring Safely habit that gives a key for reliable tagging.
Tagging also slows a developer down to think about what exactly is in the commit. Now the developer is thinking about the risk within a small commit. This provides the opportunity to notice a team level systemic problem that impacts design, and gives an interrupt where it is natural to get others involved.
Practicing the safeguarding techniques (as described by Llewellyn Falco and Jay Bazuzi and that we offer in habit form) help find common risks that cause the team to write bugs. Once the team finds what safeguarding calls hazards, then the they can learn how to safely eliminate those hazards in the code. Deep Roots offers habits that solve common hazards, with some examples including Fix God Classes, Advanced Testing, and Prevent Non-Local Interaction Bugs.
This is not solved in the codebase or coding technique, which is the focus of Deep Roots. However, while the process side of the business is working to pivot, we can offer developers the opportunity to improve their craft and solve the design and bug syncing issues.
While Deep Roots stays focused on technical excellence, not process, we offer very viable technical solutions to two of the problems that developers are used to solving face to face but are now quite difficult. This provides time and space for the process side of the business to solve the communication challenges.