small medium large xlarge

Refactoring Your Job

Finding the Upside of the Downturn

by Craig Riecke

Generic image illustrating the article
  You say your department was downsized from 100 programmers to 60? That doesn’t have to be a disaster; it can be an opportunity, if you make it one.  

Is it me, or has this economic downturn been... uhhhh, somewhat less than fun? I mean really. The chances are very good you’re a programmer working in a smaller department than you were 5 years ago. You’re in maintenance mode. The tasks you perform are more break-fix, less cutting-edge, less intellectual challenging. Your budget is smaller, so training and conferences are less accessible.

“At least you have a job,” someone says. That might make you feel good for a while, but you’re not the kind of person who thrives on standing still. In the 2010 TechRepublic IT Skills and Salary Report, 80% of participants cited “Opportunity to Increase Skills” as a major job satisfaction contributor. And you feel that might be slipping away.

It feels like someone is pushing the brakes on your car. You feel you’re no longer in control. Your morale plunges, and it gets harder to go to work every day.

So how do you get through this?

Turn Things Around

I hate self-help books. I especially hate ones that minimize one’s pain and suffering—the ones that offer pithy sayings like “Look at this as an opportunity. Be positive. Let go of your anger and frustration.” Blah blah blah. It’s as if now, on top of feeling crummy, you’re now a failure for not making yourself feel un-crummy. Gee thanks.

Here’s the thing: you’re an IT person, and you like to be somewhat in your control of your destiny. When something is boring, you write a batch job to do it for you. When you encounter complexity, you draw diagrams and write comments to help you understand it. In short, you act, you don’t just close your eyes and try to picture things differently. That’s why vague self-help books don’t work on you.

I look at it this way—I love to refactor code. Refactoring’s a necessity when the surrounding code changes, you have new programmers working on it with different points of view, you change the environment underneath it, etc. Good code is in a constant state of flux, but you always get the sense that your code progresses, because you’re a better programmer today than you were yesterday.

So it is with your work life. When the environment around you changes, you can refactor it to make it more harmonious. Programming is not a cookie-cutter job. It allows you a great deal of flexibility because... well, if you could write down the exact steps needed to do it, you would’ve automated it by now! You have some power to shape your career, make it fit the environment, yet reflect the intellectual athlete you are.

Slash and Burn

First let’s be realistic. If you have 40% fewer programmers around you, you should have 40% less code to maintain. And the chances are very good that 40% of your code can be cut. Much of it is dead, unreachable code. Some of it lies in redundant or seldom-used features.

You might counter, “Well, if I don’t touch that 40% extra code, what does it matter?” It matters.

  • That 40% extra creates noise, masks true problems, and invites you down dead-end paths.

  • When you Global Search, you’re searching 40% more code.

  • When you run your test suite, you’re testing 40% more code, which takes 40% longer.

When a company downsizes, it often stops doing whole classes of activities. Perhaps it stops selling a particular product line, it simplifies a 5-tier pricing structure down to 1, and so on. That’s the perfect opportunity for slashing out this code. If you ever take these duties back in, you can always fall back on the code in your Source Control system.

OK, but here’s the problem. Slashing code takes time, which you have less of. I use these ideas to help:

  • Since no one gives you explicit time to cut code, factor it into the velocity of a project. If you spend 10% of your day cutting code that’s tangentially connected to your project, the project goes a little slower, but not prohibitively so.

  • Take the opportunity to heavily instrument code. In my case, I created a special logging level called DEPRECATE, then threw logging in suspect procedures.

Cutting dead code is not only practically good, it gives you a psychological boost. It’s like the TV show Hoarders, where at the end, everyone’s overjoyed in their new, cleaned up house. You can be like that!

Get Really, Really Good at Prioritizing

Oiling the Squeaky Wheels in your company is easy when you have enough resources. So one luxury of having too few resources is that you now have a fail-safe excuse not to do useless projects. When you’ve stopped doing the obviously bad projects, and you start having to cut worthwhile endeavors, prioritizing becomes a deeper, more interesting task. All of those things you should have been doing all along—watching people work, understanding the business, and talking to people who are not always the most vocal, but maybe the most perceptive—are the things that will save your bacon now.

Not to get all Utilitarian on you, but there’s a moral calculus at work here. (John Stuart Mill is a good read while your test suite is running!) Seek out pain points—the things in your company that are the biggest hindrance to the greatest number of people. Then formulate projects that’ll solve them.

Why do this? First, it keeps IT visible, making it a problem solver rather than a cost center. People who don’t normally think of IT will now become your champions. Second, it’ll give you a boost of confidence. Every IT person remembers the first few programs they wrote, and how elated people were to use them. Getting back that feeling will remind you why you got into IT in the first place.

If you’re not solely in charge of prioritization, you must get better at convincing others to adopt yours. Terrence Ryan’s Driving Technical Change (Pragmatic Bookshelf, 2010) has some really good advice on this.

Misery Loves Company

There’s another reason to choose pain-point alleviators. Psychologically it may help to hang around people who are as miserable, or more so, than you. Suffering is bad but suffering alone is even worse, and by talking to others, you relieve a lot of the pressure and isolation.

However, and this is very important, once you find suffering you must find glimmers of hope. Seek out people who believe things can get better, and are willing to work a little harder and think a little deeper to get it. These are people who you can form a symbiotic relationship with, where each of you feeds off the positivity of the other.

Don’t let negative people drag you down further. You are not their psychologist or their spiritual advisor. Talking helps, but talking is only the first step. At your core you are an IT person, and your toolbox is IT. If they believe only a bigger paycheck or more hired help will solve their problems, then it’s best to minimize contact with them. (OK, maybe you can give them a bigger paycheck with a little well-placed COBOL, but let’s stick to legal tactics).

The Next Big Thing

In any other business, you might think, “Now I can slow down and concentrate on doing my job instead of finding the next big technological change.” But that’s not the IT Way. People get into IT because they love doing the next big thing. And let’s face it. Compare 2008 to 2010 and you see just as many technological advances—from consumer electronics to architecture to programming languages. It isn’t slowing down.

When you had more programmers, you could factor learning the next programming environment into your project plans. Now you have no time, and projects tend to be more maintenance-oriented than new code. So how do you keep up?

First, you can take advantage of what I call Cooperative Computing. Modern systems are less monolithic, more best-of-breed. The idea is to build projects in the new style, then connect them with common, well-debugged mechanisms like Service Oriented Architecture. You can also look for non-traditional ways to glue new architecture to old, like JRuby melds Ruby to Java. Instead of building a new building, think of buildings that learn and gain additions while keeping their character. Stewart Brand’s How Buildings Learn (Penguin, 1995) is a great inspirational book on this subject.

Second, if you have to build in the old paradigm, always keep the new paradigm in mind. If you must write in JSP knowing you will move to Rails later, use JSP conventions that will make the shift easier. Use more data-driven code generation. Then you can simply write new generators when you have time to move to Rails. Or you can even use a product like ANTLR to write transformation grammars. But the more regular you build your code now, the easier the shift will become.

Third, keep reading and researching! It’ll help you even if you can’t put it into practice right away. One of the best recent books I’ve read is Seven Languages in Seven Weeks (Pragmatic Bookshelf, 2010) by Bruce Tate. I may not have time to adopt any of the languages there, but it got my mind to thinking in new ways, which eventually changed the way I write Java. The Sapir-Whorf hypotheses says that different languages inspire different ways of perceiving and thinking about the world. That’s certainly true for computer languages.

Get Plucky

Let’s say your department was downsized from 100 programmers to 60. It looks like, by all accounts, you are at a relative disadvantage now. But here’s the thing. At one point (unless your company formed from a miraculous, virgin birth) your company had less than 60 programmers. These programmers were doing amazing work.

It helps to adopt that mindset. Forget about what life was like with 100 programmers. Instead, remember (or imagine) what it was like to work with those 60 programmers, working your way up, dreaming big. You can’t always act accordingly, but it helps to break your thinking out of depressing boxes.

Let’s say, for example, you have a web application and the navigation is clunky and inelegant. This is the way it’s been from Way Before The Jurassic Period, and there’s no way you’re ever going to change. Because you don’t have 100 programmers anymore, right?

But let’s say you had nothing. A blank HTML page. Tabula Rasa. How would you design navigation? Would you use tabs, or a search box, or drop-down menus? And how would you design this navigation so you could easily change it later? Would you use centralized templates? So now you have a better navigation system, and a way to refactor your current navigation system to something easily changeable. Two short hops. Hmm. That sounds almost doable.

We like to think we’re objective, logical, and focused. But IT is as much a craft as a science, and requires a bit of passion. Do whatever you can to rekindle it.

Hang in There

Sure, it’s hard to stay mentally afloat during hard times. But if you do, the rewards are significant. In a rebounding economy such as ours, employment is always the last to rebound fully, and when it does happen, you have two options:

  • You can leave for greener pastures, having kept your previous business going. That always looks good on a résumé.

  • -OR- You can reap the rewards of having stayed. More new hires will look to you for guidance, and you’ll have a cleaner, easier environment to train in. And management will hopefully remember your commitment, and reward it.

It’s remarkable that people adapt to adverse conditions. They rethink their values, and re-prioritize their work. This is the natural order of things. So using bleeding edge technology may be cool. But re-connecting with people, alleviating their suffering, and making your surroundings cleaner, more elegant, and streamlined is just as cool. It’s all IT, it’s all good!

Craig Riecke is a Dojo committer and a writer and editor for the Book of Dojo, Dojo’s online documentation. Holding a BA in English and an MS in Computer Science from the University of Nebraska, he is currently Chief Software Architect for CXtec in Syracuse, NY. While programming he listens to old, scratchy blues music on his iPod. His motto is “I’d rather drink muddy water and sleep in a hollow log than write a redundant line of code.”

Send the authors your feedback or discuss the article in the magazine forum.