If you’ve worked on a large development team, chances are you’ve been in my situation: I’m near the end of my project’s release cycle, the code streams are locked down, and there’s very little new development to do. The bugs are getting more obscure, further from my code, and more difficult to reproduce. It’s tough to sit down in the morning and find something that I can knock out on my own. So how does one stay motivated and productive during times like these? Here are a few things I do to stay busy.
Volunteer to Work on Those Critical Defects
I know, I know. The last thing you want to do is get stuck on a high-visibility, high-stress bug that you can’t reproduce and isn’t even in a part of the application that you know very well. The trick is to make sure you are paired with someone who does know a thing or two about the area of functionality and pull in experts as you learn more about the problem. At a minimum, you’ll build some deeper relationships with people on your team as you go through the fire together. You’re likely to learn a great deal about areas of the application you aren’t familiar with and about tools you don’t normally use.
Working on a high priority bug is also a great networking opportunity — you’re likely to meet new people in the organization, and chances are they will be the more talented developers on their respective teams. Finally, there’s always the outside chance that you’ll end up a hero: unfamiliarity with a codebase can sometimes be exactly what’s needed to spot a tough issue. Even if you don’t find the bug, you’ll establish a reputation as someone who is willing to be there when times get tough.
Resolving high-priority defects is by far the most important thing you should be doing, and it can be a lot of fun if you focus on what you’re learning through the process and on getting to know your team a little better. But when everyone is blocked on the defect or you’ve run out of bugs to look at…
Explore Components You’ve Never Had Time to Look Into
In any large project, there are probably parts of the code you know well and other parts of the code that you’re completely unfamiliar with. The more of the code you know, the more valuable you are to the team and the larger role you can play going forward. If you do have downtime, take advantage and explore those foreign bits of the application. Sure, just reading code can get dull — try making modifications to the component’s functionality or following the execution in the debugger.
Knowing other teams’ components can help you with your own design and debugging and give you things to talk about when you run into the respective owners in the hall. Folks tend to be impressed when you know the details of how their component is implemented.
Write the Tools You Should Have Written Months Ago
Being a good software craftsperson, I’m sure you’ve been writing tools and automating common tasks all along. If you have time on your hands though, why not go back and take another look? Have you missed any tools that would increase your productivity? Are there improvements to your current tools that would make them easier to use or install? Do they need documentation? Perhaps it’s time to pitch them to other teams in the organization? It can sometimes be tough to find time to write the tools you wish you had, so take advantage of the slow days at the end of the cycle to catch up if you’ve missed anything.
Go Back and Read Your Own Code
This may sound like a strange one, but really, give it a shot. It’s fairly common for me to get so familiar with my own code that I start to overlook things. I find it helpful to back up, clear the mind a bit, and read every class or script my team owns from top to bottom. And yes, all the tests too. Chances are you’ll find areas that can be improved. When things are slow, it’s a great time to have those big-picture design talks with your team members, come up with ambitious new ways to simplify your code, and go crazy with spikes to see how those ideas might pan out.
Make the Most of Your Time
Again, the top priority is to knock out those really annoying, stressful defects that are holding up the release. Your manager will thank you, you’ll build better relationships with your team, and you’ll learn a lot in the process. Once those are taken care of, I know it can be tempting to want to just relax a bit after the long grind of a release cycle, but it’s really rare to have time for all those lower-priority tasks, and there’s a lot to be gained by taking advantage.
Published bimonthly and distributed to more than 550,000 of the top IT managers, database administrators, and developers.
Contains technology strategy articles, sample code, tips, Oracle and partner news, how to articles for developers and DBAs, and more.