Weaving The Software Tapestry

Read More Code to Write Less

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.

 

Yarn

Developers need to learn when to refactor and mend existing code rather than always create new classes and methods

 

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.

 

![The Matrix](https://images.unsplash.com/photo-1526374965328-7f61d4dc18c5?ixlib=rb-1.2.1 "Only by reading more code will developers be able to learn to write and understand code better")

*[Only by reading more code will developers be able to learn to write and understand code better]([ 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!

 

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.

%d bloggers like this: