Depression and the Software Developer: The Last Straw

Photo © 2007 Jason Eppink CC BY-NC-SA 2.0

Here’s a story I’ve been keeping on the back burner for almost a year now. I haven’t published it until now, because it still hit too close to home. But this week, I’ve scheduled an interview with Sharon Cathcart, author of In the Eye of the Beholder, which I am currently reading, and a memoir Les Pensées Dangereuses. And parts of her story reminded me of certain elements of my story.

This is the story of the software-development project that plunged me into a deep depression (a continuation from part 3 of “Depression and the Software Developer”).

[Note: You can read the story from the beginning in order to catch up.]

It was only a couple months long, but it was the straw that broke this developer’s back. It was the project that made me realize how much I enjoyed making a difference, as I did in my first job after college. It made me realize how important it was to make a difference, rather than just being a cog in a useless, corporate, perpetual-motion machine. Most development managers simply don’t know how to let their developers make a difference, possibly because they’ve never known themselves what it feels like. And to this day, the memory of this painful project keeps me from taking the software-development industry seriously.

The project itself wasn’t that bad. I joined it as a consulting developer, along with a couple other consulting developers. The client had been desperate for short-term help, and I took on the project as a favor for a friend, who was already hip-deep in it. They were also on a limited budget, and so I offered a reduced rate, again as a favor to my friend. That was Idiotic Decision #1.

They gave me a “specification” for a feature they needed me to work on. For the purposes of this story, let’s call it the NOKWID feature (because No One Knows What It Does). NOKWID was a key part of the project, and they needed to show progress on it–and quickly–in order to justify the project’s funding. Unfortunately, the spec turned out to be nothing more than a rough collection of thoughts that one of the developers had thrown together, probably from notes he had made at meetings. I pointed out the numerous nebulous features called for in the spec, and I replied that I couldn’t possibly deliver NOKWID until these had been fleshed out.

Now, the project was being led by a software-developer-turned-manager type, who seemed way too busy to manage a software project. Let’s call him “Pointy-Hair 1.” And I was to be working with one of the staff developers, also with a pointy-haired background, a manager-turned-software-developer type, who we’ll call “Pointy-Hair A.” (You thought I was going to call him Pointy-Hair 2, right? No way! I don’t want Pointy-Hair A to think he’s any less pointy-haired than Pointy-Hair 1.)

I’d love to tell you all the crazy things I experienced in the span of a few months at the hands of this pair. But I fear I might become psychotic if I tried. So I’ll limit myself just to a single anecdote.

NOKWID depended on Feature X, which like everything else, was undeveloped and no one knew how it was supposed to work. Because of this, there was absolutely no way I could deliver code that worked with Feature X, and I told them as much.

In response to this, Pointy-Hair A told me that Feature X was something for “down the road.” We didn’t actually need to support it at this time. Whew! I breathed a sigh of relief and removed Feature X from the spec.

The next day, Pointy-Hair A added a paragraph to the spec talking about how NOKWID was to interact with Feature X.

This was repeated in different variations and with different specifics. It seemed that the longer I sought to understand and to document what NOKWID really was, the further I got from the truth. I had only a vague idea what I was supposed to be delivering, and Pointy-Hair 1 kept asking me when it would be “done.”

I complained that I couldn’t possibly deliver finished code–or even estimate how much time it would take–until I knew what the requirements were for NOKWID. And I told them that they needed to document the decisions and assumptions they were working off of, and to let me in on that part of the conversation. Each time I said so, they gave me the soothe-’em-down treatment, as though I were a hemorrhoid and not a key member of the project team.

“Don’t worry about that.” (Which I should have.)

“That will be ready long before you need it.” (Which it wasn’t.)

“Just ask for what you need, and we’ll get it to you.” (Which they didn’t, and I didn’t know what I needed, anyhow, because I didn’t know what I was supposed to be delivering!)

“Don’t let that hold you up.” (Which it ought to have, or at least ought to have made me take a beat.)

At about this point, I was thinking I was obviously not charging them enough, because they clearly weren’t listening to me. After all, I had successfully completed projects using this project model before; they had not. I was also one of the most senior people working on the project, in terms of years of experience, and had twice as much experience as even the most senior staff developer. But as is well known among consultants: knowledge, experience, and wisdom do not earn you respect; money does. If they had been paying me hundreds of dollars an hour for my advice, then they would have found some rationale for why my advice was actually worth that much. However, I had given them a discount, for the sake of my friend, who was now neck-deep.

Even under these demeaning and impossible circumstances, I decided to push on as best I could. That was Idiotic Decision #2.

(Continued: click here for the conclusion of “Depression and the Software Developer”.)