I'm training to run my first half-marathon. I enjoy long runs and use this time to unwind and let my mind wander -- a state that is the exact opposite of the software development and project management role I play during most of my waking hours. During my last long run a question came to mind: Can you train to become a better software developer as you train to be a marathoner?
I think you can, and every software developer should consciously strive to do so. But, to a group of people that already work incredibly hard and may or not be athletically inclined, "endurance training" can sound a little scary.
Like all good professional endeavors, endurance training for developers needs to be a process, not an event. In order to train for a marathon you have to basically train your body to run longer distances over a period of training sessions. In every session, you push your body a little bit harder, fuel your body correctly, and every so often let your body recover, then go at it again. (Marathon runners: I know this is an oversimplification of the process, but bear with me: this is a software development blog, not a runner’s blog).
I believe that if software developers apply this strategy to their craft, they will become better developers -- without fail. These developers will probably create more code, but more importantly, they will develop cleaner, more efficient code with less bugs.
So, here’s a training plan:
Institute time trials. The idea is to develop better software in less time (better code is not necessarily more code). Although sprints are a common part of the development process, there are times when the team or parts of it are not running at full speed. You need to push yourself harder in each sprint and measure your success.
For example: maybe the goal is that during a given sprint, you will produce 25 percent fewer bugs. For the next sprint, maybe that number jumps to 30 percent. As you push yourself harder, you raise your performance bar and you become a better software developer. In runner’s terms, that’s beating your own personal best.
Feed your brain. If you are going to push yourself harder, you need to make sure your muscles -- in this case your mental muscles -- have the needed fuel for optimum performance. In the development environment, this means making sure you have brain fuel.
Well-stocked kitchens might be commonplace in tech companies, but fuel is more than espresso shots, Clif Bars, Twizzlers, and Red Bull. It's also access to ongoing learning through formal and informal training, online case studies and blog posts about challenging projects, and other resources that can help the development team continue learning and growing.
Informal cross training by the development team is probably one of the best forms of brain fuel available. Has a team member learned something new during the last sprint? They should share the insights with colleagues, which helps to elevate everyone’s performance.
Allow for rest. Finally, after hard training, you need to allow for adequate recovery. There's a whole body of science behind letting one's brain "check out" in order to foster creativity and problem-solving breakthroughs. "Checking out" can be something as simple as going on a walk, filling out your time sheets, or playing with some Legos in the office -- not to mention the obvious: getting a good night’s sleep. The important thing is to let your mind rest and concentrate on something different for a while.
Every athlete knows that even the best training plans can be derailed. Injuries happen, the weather can be uncooperative, "real" life gets in the way. So it is with developer training: new last minute projects come online, team members get shuffled around, and deadlines are unmovable.
But athletes also know that once you are "in shape," it’s easier to stay there. Similarly, developer teams that cultivate healthy training habits will find it easier to stick to those habits when the going gets tough. It’s always harder to sprint uphill, especially when you haven’t trained for it.
This article is published as part of the IDG Contributor Network. Want to Join?