Re: How do you avoid "Code Burnout"?

[chunlou]

At a personal level, if time permits, I probably would just work on the code continuously until it's done, once and for all--to me, one long torture is better than a poke in the arm repeatedly day after day.

At a managerial level, a project manager (or someone in that role) should recognize if a programmer is of "maintenance" type or not, and assign tasks accordingly.

A "maintenance" type is someone who has greater mental endurance and tolerate towards repetitive tasks and reading someone else's code. He might also be someone who works better on existing work than doing something from the scratch himself.

A flap side of the "maintenance" type is someone who prefers creating new things from the start.

A possible task assignment arrangement could therefore be, assigning "maintenance" work to new hires as they're probably not ready to do their own project from the scratch yet, and at the same time they could learn something from existing codes. Gradually, you could see who are better off staying at "maintenance," and who doing something else.

[chromatic]

I can see the appeal of that idea, but I respectfully disagree. My reasoning is three-fold:

• The most reliable way to get better programmers in general is a program of mentoring and apprenticeship.
• The most effective way to build maintainable, useful software that meets the customer's actual needs requires frequent, small deliveries. The software is always being both maintained and enhanced.
• One of the biggest problems in software quality today is that people won't read code.

If you have repetitive work, automate it. If you want to know if software works, test it from the start. If you don't know exactly what the customer wants, ask him. If you want to train a new programmer, pair him up with experienced programmers.

[chunlou]

You're right.

In practice (which happens often to any area) nothing stops a mentor from giving "boring" work to his apprentices, so that he could be spared to do something more exciting.

It's not ideology, it's just psychology. And the issue isn't how right you're, but whether you get your executives' buy-in and support.

(An anecdote: some people think "small, frequent deliveries" means they don't need to write as accurate a spec and development magically becomes easier--hence, e.g., testing isn't as much needed.)

[Anonymous Monk]

I probably would just work on the code continuously until it's done

Doesn't work. I've tried it. You usually pass out and forget everything around 72 hours.

A flap side of the "maintenance" type is someone who prefers creating new things from the start.

These ""maintenance"" types are a myth. Nobody could be so twisted that they'd prefer to maintain existing code than create something new.

[svsingh]

They're not myths! They're new hires! Seriously, a lot of companies/groups use this philosophy. Cut your teeth on bug fixes and general maintenance, and then once you're familiar with things, you can create new code.

[Anonymous Monk]

That's the difference. I'm sure these new hires would rather create new projects then maintain old ones, it's just that the people hiring them won't let them.