1. For the enjoyment / learning of it. Golfing, for example, or obfus.
2. To get a job done.

Remember - there are programs written over 30 years ago and untouched since that are critical to keeping capitalism running. Don't believe me? Go ask a mainframe programmer for the US Treasury Department how bonds are issued and the sales kept track of. If you don't believe me that the failure of the US Government to issue bonds in a timely fashion would crash the world economy ... *shrugs* I just wish I had your ... optimism.

That said - if you could engineer in significant new functionality, that is now a case for a rewrite. I did this with PDF::Template. (Yeah, that module I keep promising to release the new version of. Documentation ... my new son. Man, priorities suck.) But, I also made sure that old templates didn't break (much).

Another thought - can you source filter anything and rebuild? If you are making a name change to accomodate new thinking, but the calling signature can remain similar (or transforms in a consistent fashion), you could use regexes and source filters to help ... ?

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

For the compatibility problem, there is a pattern called the "facade pattern" - other known names are "compatibility library", "ugly wrapper code" or "legacy support". You write your new library, using the new coding style, and supply a compatibility wrapper around it, that allows the rest of the projects to use the library until they adapt (to) the new API.

If you are not in the mood for programming, it is the wrong time for creative programming. If you really have to program/sit in front of a computer, do "stupid"/monotonous things like fixing documentation, writing stub end user documentation or stuff like that. But much better IMO is taking a break, and starting something recreative that takes your mind off these things and forces you to concentrate on other things - learning to juggle helped me for example, cycling or running might for you.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]

There were unmistakeable non-code challenges. A combination of distributed team and personality issues, financial pressures of the "dot-bomb" and our largest benefactor losing millions in the week of September 11, finally pushed us under.

But the real burnout came from the team/technology challenges. I implemented several tightly-integrated concepts which made perfect sense to me, and was understood by my business partner, but which few of the rest of the team even tried to grok. It was opaque to them, no matter how I pitched the concept, the structure, the roadmap, code reviews, or offered examples. Nobody wanted to build on what I started, but kept trying to rebuild or reimplement things they were already familiar with instead. Nothing synergized. We were all stuck on our own concepts, myself included.

Every time I look at the code, I wistfully imagine the rest of the structure that was supposed to use it. It's exactly like looking at the unfinished arcology project called Arcosanti. I fantasize about somehow getting over the next hurdle of implementation privately, of a phoenix rebirth in code. Or hire a skunkworks crew of interns or offshore coders to haul the heavy parts. Then I look at my current lifestyle, a "day job" and a family, and realize it's just never going to happen. My years of invention just lie virtually dormant on a hard drive, in a dusty directory I visit a few times a month.

So in reply, I don't want to start from scratch, I want to use what I've built. I empathize with that sense of depression. Not sure what to say about how to get out of it, other than any other get-out-of-depression advice. Some comedian said in a mock mystic's voice, "I sit, and I think about myself, and I get depressed." I have found that's really the crux: if you stop sitting, or if you stop thinking about yourself, you can pull out of most average funks.

Taking a walk outdoors and exploring the problem-space may help you find different insights. Scribble diagrams on a pad of paper. Avoid the keyboard until you really have something you want to implement. Refactoring is useful, but only if you have a new user waiting impatiently to use and abuse the new interface.

--
[ e d @ h a l l e y . c c ]

Another thing to think about here is that you feelings about your previously written code are filtered by present knowledge---i.e. as you get better your older code gets uglier. Try and balance your urge to fix all of the old stuff with the notion that un-broken code shouldn't be mucked with unless there is a really really good reason (someone pointing a gun to your head and that sort of thing).

A last thing to look at is to keep a proper mix of both existing projects and new projects going. 'Newness' often holds off burnout all by itself.

--hsm

I could just use a diversion and play chess or something, but I know in the back of my mind, I have to get back to that code sometime, so.. why not now?

For what it's worth, I had a burnout problem last year. I put in way too much time at work and it caught up with me. I took some time off and pretty much avoided touching computers. After the "so why not now" period, I actually started to enjoy being disconnected from my work. Then I started to miss working on the computer. Once I got to the point where I missed working, I knew I was ready to step back in. I just had to shake off the more recent bad associations with working and remember why I started working with computers in the first place. That re-energized me. The total process took about two weeks to get over a six month build-up/burnout.

I'll admit that I was lucky to have a manager who saw the problem and gave me some flexibility in ducking out of work for a few weeks and others may not be so fortunate. My only real advice is if you can put off that feeling of "why not now" and wait until you're exicted to get back to that code, then do it. It's hard to feel excited about something when you have to do it more than you want to.

On this note, I've got kind of a sub-topic to discuss... The software company I work for just landed a contract with a bank that is, I believe, the biggest in the world. There were some things promised that have some of us developers scrambling to impliment.(Yes, the sales rep sold a couple features that are vapor-ware. Tsk tsk.) Needless to say, this represents a sizeable chunk of money, so we're doing it.

Last week my boss came in and announced that if we couldn't keep to our schedule, that some vacations may have to be cancelled. Ick

I swear, I'm getting close to the burnout mentioned above. I'm not like many of the other programmers where I work who leave for the day and are done. I work at home because I enjoy my work. This is great, but when I start to burn out, my yearly 2-week vacation is what revitalizes me. I return to work full of energy, and chomping at the bit.

My question is, how to best go about showing my boss that, in the long run, the vacations will keep us closer to being on schedule than foregoing them, and forcing us all to work long hours, eventually hating the project to the point that we desire to do the bare minimum to get it done. How do you tell management this? They're not programmers, so, I need to word this in a way they'll understand. Any help here would be appreciated.

Nuke
nuke@nuke3d.com
www.nuke3d.com

Sounds like you are starting in on a Death March. If you are a technical lead (or are willing to stick your neck out) Rapid Development has a number of potentially useful suggestions for how to handle projects like yours. (Its suggestions are less useful if you can't get them into the hands of someone who is part of the decision making process though.)

tilly's suggestion of Rapid Development is a great one. What you described is pretty similar to the case study. I'd also add, that if you can't sell those ideas upstream, try to protect yourself by insisting on clear requirements from your manager and have them push that message upstream. It's bad enough when you have to work in that kind of environment. Doing it while shooting for a moving target is a huge morale killer.

Personally, I think there's a pretty close relationship between burnout and morale/depression. When I can see the finish line, I have boundless amounts of energy. It's when I seem to take a step back for every one forward that I notice the fatigue of burnout. Once that starts, it's pretty hard to produce at my best. The longer I feel I'm running in place (or going backwards), the more burnt out I get.

You may not be able to communicate that all the way up your management chain, but if you can get through to your manager, then it may help control the parts of the project that directly affect you.

If this sort of thing becomes a habit in your company and you find you're getting burnt out freqently, then you have to look out for yourself and consider walking away. I did that in January. (The factors that caused the burnout in my other post just got worse in the ten months since my two week break.) The time off was great and I finally opened that copy of Teach Yourself Perl in 21 Days that was on my bookshelf for two years. Within four months, I was at a new job and that's going pretty well.

I'm personally very lucky this way. My employer's web site isn't that integrated, which means we can rewrite everything whenever we have the time to do so. This is good, since most of the code here is cobbled together by people who aspire to be the next Matt Wright (use strict? modules? huh?). These days, when my boss points to an old CGI that needs fixing up, she usually tells me its OK to rewrite it, because she knows I'm going to ask anyway :)

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

Next time when you write the code, think about where your peace of mind lies. It could be in solving problem, functionality, program structure, interface, code readability, comments, features etc.. Not all of them can be handled/achieved simultaneously. So you have to choose your level and achieve it step by step. You can make some sort of notes about it. At the end you would analyze this and rectify the process. Start integrating this in your projects and it will become a normal thing as you practice.

Besides learning syntactical sugar components, I feel we need to have some work done in the area of 'How to' write a program.

artist

Just hanging around here inspires me to write all kinds of code/snippets that i would never think of otherwise. Going with Corion's advice about the Facade Pattern (brian d foy wrote an excellent Perl Review article on that pattern by the way - you should read it), here is my quick-n-dirty mini-tutorial:

Brushing up and writing about the Facade Pattern has nothing to do with my current projects, but i somehow feel more refreshed for doing something new and "not my job" ... oh, and beating the crap outta my drums doesn't hurt either ;)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

What do other monks do, when they just can't look at the code anymore, without wanting to throw it all away and take up a career in woodworking?

Actually, I do woodworking. And cooking, too. It helps a lot - I wrote the main algorithm of a module in a piece of paper, when I was cooking, looking at the beach :)

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.

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.)

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.

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.

On a related note, I'm hitting "help doc burnout" right now. Having had great fun programming our admin system, now comes the real drag of documenting *everything* (got to make sure this can stand on its own if I'm not around :).

To alleviate the boredom, I found the following helped:

• kolf - or whatever spaces you out
• walks / some other activity away from the screen
• Make bread - When I worked from home, I found making bread very theraputic - not only do you get to punch a lump of goo for ten minutes, but you also *have* to take several breaks from your PC to knead/prove/bake it. And the smell when done. Hmmmmm
• code treats - anything that really interests you? Voice XML? XUL? Something that lights the intellectual fire. I use it along the lines of, "I'll work solidly on this crap for 2hrs, then stop and play with XX for a while.
• Sleep - probably goes with the depression as well (at least it does with me). But, sleep when you're fried. Sleep is your friend :)

.02

cLive ;-)

I take two approaches to viewing this issue in my own life. First, I feel your pain. I can look at most of the programs around my place of employment and feel the desire to "...throw them all away...". However, the decision-makers here will almost always use and win with the "don't fix it if it ain't broke" argument. Given that reality (coupled with a monthly mortgage payment :-), I often remember this bit from the "Tao of Programming":

7.1 A novice asked the master: ``In the east there is a great tree-structure that men call `Corporate Headquarters'. It is bloated out of shape with vice presidents and accountants. It Issues a multitude of memos, each saying: `Go Hence!' or `Go Hither!' and nobody knows what is meant. Every year new names are put onto the branches, but all to no avail. How can such an unnatural entity exist?''

The master replied: ``You perceive this immense structure and are disturbed that it has no rational purpose. Can you not take amusement from its endless gyrations? Do you not enjoy the untroubled ease of programming beneath its sheltering branches? Why are you bothered by its uselessness?''

The other thing I do is try to find joy in smaller, more personal things, things that could benefit my employer, but will benefit me in the long run. I often find that paradigm shifts I sometimes experience when learning new programming languages and design techniques are invigorating. For example, try reading (and really pondering) some of Paul Graham's writing. Just the other day, I ran across Naked Objects, and the idea there of flipping a typical application inside out (from a verb->noun perspective to a noun->verb one) was exciting. Learning new programming languages (Smalltalk!) has had the same effect.

...every application I have ever worked on is a glorified munger...

I just want to throw all the code away and start from scratch.

Do it. Problem solved. Really, I'm not joking.

Which problem does that solve, the problem of having working code that does something useful? As far as problems go, I'd love to be cursed with that one more often.

Which problem does that solve, the problem of having working code that does something useful?

Blockquoth the root post:

The problem is that I just want to throw them all away, start from scratch (on paper), and rewrite them.

So, that problem.

Rewrite the code, develop a nice, shiny, new interface for it. Clean up the internals, hell, maybe even write it in a more maintainable language (like ASM </troll> ;-P).

Really, you'll feel much better :).

ßÖ§?

Then, try to relax and smell the roses ;-)

--
Regards,
Helgi Briem
helgi DOT briem AT decode DOT is

Time to take up the next step in your life/carreer/whatever.

Take up technical/business analysis.
After a few years, you'll start coding again... just for fun!

;-)

Cheers,
MichaelD