Refactoring your job

Finding the Upside of the Downturn
By Craig Riecke

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.



Refactoring your job