Weaving the Software Tapestry
Recently I’ve been reflecting on the amount of time I spend reading code. Far more than I write in fact. In addition to the constant stream of pull requests filling my inbox, I’ve also been reading the code of our reusable UI components, including a recent rewrite. Here I contemplate the ratio of reading to writing, and whether we’re encouraging the correct ratio between developers.
Writing versus Refactoring
As I discussed recently in Caught in a Trap, we have previously suffered from writing a few bloated controls. Some of them are very feature heavy, so with the ongoing rewrite we are only including the features that we actually need. It sounds obvious, but we only want to include the features that are actually common within the common components.
Adding a new feature over the past week without over-complicating the control has been challenging. It has required compromising between refactoring and fully rewriting. Refactoring should be small incremental moves and optimisations, which was what the initial design intended. After a few days, I received a large pull request with a ton of new classes created. This is a prior trap discussed in my previous post, as this is contrary to Trunk-based Development practices. Large reviews are more synonymous with rewriting, which we wanted to avoid.
Coding is both a logical exercise and a creative process. Developers seem to exhibit a preference for spinning their own yarn of code rather than mending the existing jumper. Here we did need a new jumper to allow for building of the requested screens for the next few sprints. Letting go and accepting the delay has been a good management lesson for perfectionist me.
The importance of upfront design is also apparent here. Any knitter will tell you they need to know the pattern in advance to make sure the jumper doesn’t end up as just a scarf. Building software is no exception. Therefore, we have introduced a regular design session following retrospective feedback to get developers thinking about code rather than diving straight into writing.
Read Code First
Our recent rewriting exploits got me thinking about how often we should spend reading versus writing code. A precise ratio is not difficult to find, and I had definitely came across it before in my spare time reading. In Uncle Bob’s book Clean Code, he advises that the ratio of reading to writing code is 10:1. If I reflect on the time my team spend, they are not reading enough code. We may love weaving a coding tale, but reading more code will make us better developers.
It does make sense to read more than write. To prevent code duplication, we need to know what is already there. To design the optimal way to change existing code, we need to understand what already exists. Familiarity is instilled when you work on the same code base everyday. Without the fear of switching to a new code base and its differing standards, it is easy to get complacent if no-one is around to enforce standards.
As the lead, I occasionally need to crack the whip to instil good practices. Your experiences teach you the right way to approach every aspect of life, including building software. My experiences will help the next generation of developers avoid my development regrets, meaning they can focus on making different mistakes and therefore better software.
Read More Than Just Code
Developers should definitely read more code. However, reading only code is not going to make you a better software engineer. Over the course of my career, I’ve had roles revolving around writing of code and requirements, in differing quotas.
The more that you read, the more things you will know. The more that you learn, the more places you’ll go.
Dr. Seuss, I Can Read With My Eyes Shut!
Despite my inconsistent exposure to code, I’ve never stopped learning. There is an expansive world of books, articles, opinions and other resources out there to discover and digest. Agile mandates continuous improvement of process. To exercise agility, developers must continue to learn to continuously improve their code and architecture skills. Only then will we be able to better refactor and stitch in our new features.
Thanks for reading! Claps are always appreciated.