WWPD (What Would Paul (Graham) Do)

For those who don't know, Paul Graham has accomplished quite a lot in my industry, including cofounding Viaweb (now Yahoo Stores), and contributing to Lisp projects. More importantly to me, he offers tremendous insight into development through his website and blog.

I had yet another wonderful moment here at work last week. Late Thursday, as my team was trying to wrap up the unanalyzed, under-resourced project that affected all of our clients' ability to bill, another issue came up.

The way client issues are handled by this company are thus. A client calls, says they have an immense problem (which may or may not be the case), that it's a problem we've created (which may or may not be the case), and our senior management makes it the highest priority. Immediately all hands are on deck scrambling to figure out what the issue actually is, and all other work suffers.

This happened last Thursday. As it turns out, we fixed a problem with patient statements a few months ago. The previous development team did not tie patient statements to the account ledger, but instead used the source tables which tend not to know about adjustments, write-offs, etc... the usual information found in an account ledger. We completely rewrote them and they now work beautifully.

This particular client didn't use best practices for charge writeoffs and apparently didn't read the release notes nor bother to watch the training video we provided on the subjects. For a couple of months it seems they were sending patient statements to patients whose debt had already been written off. This apparently inundated the practice's call center with questions from these patients.

The MO here is usually that development, business analysis, training, and client services was wrong because the client said so.

After a few hours of analysis we determined what the problem was (our legacy versions' business analyst is unbelievably good at what she does) and reported it back up the chain and to the client. You can still hear the crickets chirping.

Meanwhile, the secret code was uttered from senior management to the product manageer. "Tell Jeff 'Nobody goes home until the EMC work is done.'" That was the project that was behind and pushed aside by this new important issue. And that is the code that senior management used four days in a row while they were at a conference and couldn't bear to tell clients we had a process for analyzing issues and would look into their particular "pink font" issue. That is the code that makes me want to quit my job and flip burgers for a living.

My response this time was "feel free to tell them I'll go home when it gets late, and if the work isn't done, I'll consider myself fired and never come back." In a fraction of a second I remembered a company policy regarding timely notice and lack of payout of accrued vacation pay. So I ammended the statement to "Wait.. you guys owe me an assload of vacation since I can never take one, so I'll come back with my letter of resignation."

Three people have stopped by my desk since to make sure I still worked here. I don't know if I really intended to quit on the spot, but the moral of the story is a developer/team lead/manager can only take so much of fireman mode. That mode causes the real work to suffer, and on the back end of that suffering are more fires to put out because the work was tied to a deadline and hurried or interrupted so often that the abstract vision was difficult to maintain.

The conclusion I came to over the weekend was that this incident only accelerates my desire to find work with some other company that mistreats its developers... only closer to home. And for better money. And maybe with a candy machine in the break room.