“But do you still code?” is a commonly asked question when I tell people I’m a ‘hands-on CTO’.
“Yes. Not every day, but most days.”
“Real code? Like production code, not just R&D?”
“Yes, production code.”
This is extremely important to me. In amongst all the other responsibilities I have as CTO I feel that being able to get hands-on with the code keeps me grounded in the reality of delivering our technology, it helps me relate closely with our developers, and it keeps me sane. Well, sane-ish.
Then someone asked me a question no one else has asked before:
“How do you do that?”
As their company grew they had less and less time to code and, when they tried, it just didn’t work. The codebase was so unfamiliar that they struggled to get started and if they got started they never had time to finish. Within just a few months they felt they no longer had the ‘right’ to change a system they had single-handedly built the earliest versions of.
It turned out the answer was simple: an XP process, specifically, TDD and Pairing, and a bit of commitment.
Last week we needed to make a very quick change to an important data processor. The change was subtle but complex so rather than asking the dev team to read the spec from the data consumer, or get a lecture on it from me, I paired in with one of the devs to write the tests and then the new functionality. Pairing on the tests was actually pretty quick which meant that if I had got dragged away to deal with something, someone else could have taken over on the functionality update. But, as it was, a couple of fun hours later we had all the changes deployed for final testing and then into production by the end of the day.
Recently I ran a new static code analysis tool that highlighted a specific set of code quality issues. I wanted to understand the cost and the benefit of addressing the highlighted issues before raising them with the dev team so I spent a few one hour sessions refactoring code to address one or two examples of each issue. TDD is more than just having tests but not for the first time I was thankful for the comprehensive and trustworthy test suite to prove I’d not screwed things up. Making these changes was valuable for me to evaluate the validity of the issues and served as a good set of exemplars for a team-wide initiative to address all the issues and add the tool to the build process.
TDD and Pairing are easy, they’re just how I work. Commitment is much harder but just a few hours a week is all I need to retain a very real connection with our technology and our development practice.
How could I not do that?
Paul Dyson's Blog 