How to Lose the Snooze of Working
- By Stephen Swoyer
- May 1, 2005
If you’ve ever thought about trading in your programmer’s hat for a job of a different kind—any kind—this story’s for you. The truth is, lots of coders suffer from low morale in their workaday jobs, and while there aren’t any one-size-fits-all solutions to their problems, there are a few tricks they can employ to help snatch contentment from the jaws of frustration and tedium.
Take John Carter, a programmer with a global provider of communications solutions, based in New Zealand. Unhappily, Carter reports, he’s tasked with trouble-shooting troublesome applications, which has him yearning for greener pastures, far from programming. “I specialize in using agile methods to carve [problem applications] into manageable chunks,” he says. “That’s my personal niche. However, I dream of opening a bakery so I would at least be doing things that people need and want instead of just need.”
It’s not that Carter and many of his peers hate programming, of course. Just that they often aren’t enthusiastic about—and in some cases actually loathe—the kinds of coding they most often find themselves doing.
In such cases, says Michael Feathers, a programming consultant with Object Mentor and author of Working Effectively With Legacy Code, it often helps to get back to the basics. “You have to love programming to start, but beyond that, you have to go and basically figure out do you love programming in itself aside from the context in which you’re doing it?” Feathers says. “Sometimes, teams will get very bogged down in the sense that no matter what they do, the code is still going to be lousy over time. Sure, they’re going to be able to improve pieces of it, but there’s this belief that the whole thing is not going to get better over the course of their tenure with this application.” |
It’s a realistic comportment to a difficult situation, Feathers agrees, but even so, it may not be the best approach to take. In this respect, he counsels, downtrodden code jockeys might want to take a tongue-in-cheek cue from the Monty Python troupe: Always look on the bright side—even when it’s the most thankless software project. “Even if you can’t make the whole thing better, can you make parts better and basically use it as a proving ground for your own growth?” Feathers asks. “Can you share with your friends different things you’ve learned about the application, and maybe learn from different things they’ve done?”
In his work with Object Mentor, Feathers often gives pep talks to programmers who are burned out on their work. “There’s often a sense of, ‘We feel overwhelmed, it isn’t going to get any better,’” he says. “One of the best ways to deal with this is to focus back in on what did you find interesting about programming when you first learned how?”
If nothing else, Feathers says, programming misery loves company. “So much of it is just really how well do you get along with your coworkers,” he observes. “I’ve seen teams that work in absolutely horrible codebases, but they still have fun at work. So it isn’t necessarily the codebase that’s at fault, so to speak, there’s what you bring to work as far as your expectations, too.”
For Carter, morale-building came by way of embracing agile programming methods, which he’s been able to employ in tandem with many of his colleagues, to help tame his company’s errant applications. The result, he says, is a highly interactive environment in which there’s a sense of accomplishment when troublesome applications are brought to heel. In this respect, he stresses, there’s strength—and camaraderie—in numbers. “I make mistakes. I sometimes code things the wrong way. The goalposts shift faster than I can recode. Therefore, I use peer review, unit tests and refactoring. I try to keep the goals small enough that I score before they run away again,” Carter concludes.
About the Author
Stephen Swoyer is a contributing editor for Enterprise Systems. He can be reached at [email protected].