Four Quick Ways That You Can Find Time To Code

In Patrick Kua’s book Talking with Tech Leads, the commonly agreed upon statistic is that 30% of your time should be dedicated to writing code. In previous posts, we discussed how you are on a different cadence than your developers, as you really aren’t a developer anymore. So, how can you find time to code?

Originally Posted on TeachingTechLeads.com

It’s not easy, I won’t lie. I haven’t mastered it, so this is one of those posts that is a constant reminder to work to better myself. These are the four methods I’ve found that allow me to get my hands back into the codebase without taking away from the team.

Building the Scaffolding

This is the easiest method. And the least fun.

At the beginning of any project, there’s going to be a moment when you will want to set up the project structure. Whether that is doing everything by hand or running over to Spring Initializr and clicking a few checkboxes, it’s getting you close to the metal.

You get to inject your personal standards for folder structure and naming convention, as well as setup your maven/gradle module management.

Not a lot of code, but required work by someone. Might as well be you.

Prove Out that Concept

Who doesn’t love a good Proof of Concept?

It’s your time to spend a morning figuring out what a migration path from your RESTful API to a GraphQL API would look like. Or maybe you’re trying to benchmark just how long it will take to fill up all the local storage available given your slimmed down JSON response objects.

These are all questions that will lead the next phase of the solution design. Get a head start on proving out if your idea will work on the small scale before trying it in production.

Besides, allowing yourself a free 4 hour window to figure out just how something works is basically a paid therapy session. Savor it.

Refactoring

Technical debt accrues. It happens.

You happen to have an hour free between meetings? Why not look at extracting some common functionality into a strategy. Maybe take those two latest merge requests and see if there’s a way that you can define a default interface instead of two overly similar implementations.

I like to grab a team member and spitball ideas with, at least every week or so, and see if we can come up with a way to improve our codebase. We know that our behaviors are completely covered with both unit and acceptance tests, so there’s no harm in us refactoring existing implementations.

Keep in mind, refactoring cannot happen without that instilled confidence.

I’m currently in the middle of a personal goal to update our acceptance test suite from using the selenium remote control to the newer web driver implementation. It’s taken me close to 3 months to complete in piecemeal, but we’re getting there.

Pair Programming

Now this one is the controversial one. Not the idea of pair programming, but on whether or not you should be programming in this situation.

I’ll be honest, this is a major struggle for me with junior devs. When I am approached for help, I have to curb myself to not jump into the driver seat. I want to code, I know the answer and can do it faster than them…

But that doesn’t benefit either of us. I already knew how to do it. And they likely already knew that I know how to do it. They still don’t know how to do it themselves.

Treat pair programming sessions as a way to code through someone else. Develop your soft skills enough so that you can talk your pair through the exercise without ever touching the keyboard.

In Conclusion

You may get a chance to take on a story yourself, but depending on the team size, it might not be likely. You’re better off scratching that coding itch by following one of the four strategies listed above. And by finding an interesting side project for the weekends.

If you’re going to fill your 30% quota, which I personally can’t say I do, you’ll need to put out the effort.

You’ll notice that each of these tips lends itself to freeing up the team.

• You’re building ahead of them so that they can hit the ground running.
• You’re proving that the implementation will work in a small scale.
• You’re improving code quality without affecting overall behaviour of the system.
• You’re literally improving the developer who is pairing with you.

Your job is to enable the team, always remember that.