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

Here’s the last part of this series of posts, “Depression and the Software Developer.” This last story I started on Monday, part 4 of “Depression and the Software Developer”.

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

No client or employer will ever admit to you that he doesn’t want to deal with reality. What he really wants is for you to just deliver what he needs, with zero effort on his part, in zero time, for zero dollars. If he gives you any more than that, it is only in grudging acceptance of the fact that you are not the omnipotent God. But a surprising number of project managers still act as though developers are superhuman, even if they accept that we are not divine. And a surprising number of developers are willing to accept that they are superhuman, even if they can’t deliver the actual goods.

And that was the case with this project. So I had no idea what made up the NOKWID feature that I was supposed to be developing (called NOKWID, because No One Knew What It Did), and Pointy-Hair 1 (the developer-turned-manager) and Pointy-Hair A (the manager-turned-developer) both seemed to be going out of their way to keep me in the dark.

If I were a voice talent, it would be like giving me a stack of ill-digested notes scribbled on sticky pads and saying, “Okay. Here’s the voice-over script. We need this by Thursday. When can you have it recorded?”

Needless to say, it stressed me out.

But I made the best of the situation I knew how. I took ownership of the spec and tried implementing NOKWID the best I could. But Pointy-Hair 1 still wanted to know when it would be “done,” and every time I took a step on the road to “done,” Pointy-Hair A pulled back the curtain to reveal a whole new maze of twisty passages, all alike, that I would need to navigate. I started to feel that they were working together to make my life miserable. At the very least, they both seemed to know what the actual requirements were, even though no one was telling me.

In a last-ditch effort, I rewrote the entire spec, soup-to-nuts. I spelled out exactly what needed to be delivered for NOKWID to be “done,” and also gave options–features that could be rescheduled until later or re-prioritized as needed. I knew from experience that the truth this would reveal would look very bad indeed, but at least it would define a realistic goal that we could work toward.

That may have been Idiotic Decision #3… I don’t know. I do know it caused me to invest myself personally in the project, the end result of which was a months-long depression, from which I still have not fully recovered.

I was not the only consulting developer experiencing these same problems with the project. If I were, I might have suspected that there was something wrong with me or with what I was doing. Since that time, I’ve reviewed the ensuing events dozens of times, asking myself if I could have done anything differently to avoid the imminent meltdown that–even then I knew–was headed my way. Even with the 20/20 of hindsight, I cannot see how I could have made the experience a successful one, because what was missing was communication. Simple, basic communication. As a developer, you absolutely need clear guidance on your client’s requirements. All I could have done was to fail faster, to require clear guidance up-front, which no doubt would have ended my relationship with them sooner rather than later. So then I would not have gotten paid for all the hours I ended up wasting for them, but the experience also would have probably left me with fewer psychological issues.

Pointy-Hair 1 by this time was very fond of mentioning to all of us how far behind schedule we were–as though that could make up for us not knowing what the hell we were supposed to be doing. Eventually, he told me that he needed an estimate for how long it would take for NOKWID to be “done,” and he said that if I could not provide him with an estimate, then one would “be provided” for me. I knew this was bullshit, because he would have gotten a more accurate estimate by rolling a pair of dice three times and averaging the results. But I also knew I was also on the verge of actually having enough information to actually estimate how much work there actually was left to do. So instead of telling him to be realistic, I told Pointy-Hair 1 I’d get him an estimate within the next day. That was Idiotic Decision #4.

The truth was indeed not happy. To finish NOKWID, as I understood what was required, would take much more work than either Pointy-Hair 1 or Pointy-Hair A had ever thought. But I was confident in my estimate, having successfully estimated numerous projects before. I provided options that could get NOKWID delivered sooner, if they wanted to pick individual features to be excluded or put off until later. Instead, Pointy-Hair 1 and Pointy-Hair A got on a conference call with me and told me the two of them together would simply “bang it out over the weekend.”

I grinned.

I stuck around just long enough to see whether they would succeed. They didn’t. (And who could have seen that coming?) But within a week or two, they had released something. I glanced at it. It had bugs that I would have avoided, because I already knew where those bugs had been lurking. And their solution only implemented a fraction of the features that I had been told were needed. This reinforced my suspicion that they knew of a shorter feature list, but were unable or unwilling to let me in on the secret. Nonetheless, they seemed satisfied with what they produced, and I was truthfully happy that they had found a way to get this important software delivered, buggy or not. But I also saw that unless they–as overworked as they already were–could develop all the software themselves, they would never be able to make the project a success (unless they redefined “success”).

Since then, I’ve fallen out of touch with the people on that project. I did recently check the public-facing project website, but that wouldn’t be able to tell me when or how much of NOKWID was ever developed. The website is still up—so the company is presumably still in business—and it looks like they’ve implemented some of the features we were talking about, related to NOKWID. From what I see, compared to the state of the site a year ago, they probably found a way to get more time and funding for the project, and scaled back the requirements significantly. That’s not necessarily a bad way to go, because it allows you to make mistakes and to grow your business organically.

As for me, since then, I’ve only worked on one more significant software-development project. To my friends and family, I blame the economy. “There’s just no work.” The truth is more complex, though. The whole thought of going back into a traditional software-development project positively depresses me, because judging from my experiences and the experiences of my colleagues, most of them are run poorly and arrogantly. I would only work on an engaging project in a collaborative team staffed with capable people. Such teams do exist, but they are rare, and I have not seen one since.

-TimK

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

I hope you get as big a kick out of this as I did. Here are a couple of recent craigslist ads I did not reply to. I mean, yeah, there’s getting work just to make money. But then, there’s getting work just so you can make fun of your new client.

So, maybe I might have tried to get on one of these projects, just so that I could get some Dibert-esque, “You gotta be kidding!?” blog posts out of them. But I didn’t want to have to deal with the headaches, hypertension, gastritis, and murderous impulses. So I figured instead I’d just write about them here. That should help guarantee that they never hire me. (Whew!)

First up, a startup company advertising for a Linux-Apache-MySQL-PHP developer. Hey, that’s right up my alley! But… Uh… I can only imagine that they’re actually serious. Frankly, this reads like a joke to me. (I added the yellow highlighting below, so that you’ll see what I mean.)

LAMP Programmer – PHP – startup

LAMP programmer needed to come in and pick up where another person left off. You must be available to start immediately and be skilled with PHP, MySQL and jquery.

The design is completed in valid XHTML & CSS. You will be responsible for wiring [sic] the entire backend of the site by the end of this week.

Please reply with qualifications, hourly rate and availability.

(If you are local and are a technical rockstar with high energy we will consider you for our team. )

• it’s NOT ok to contact this poster with services or other commercial interests
• Compensation: uncompetitive

Yes, that last line actually does say that their compensation is uncompetitive.

And whenever an ad says it’s looking for a “technical rockstar,” warning lights go flashing through my mind, because that usually means they have an impossible task that they don’t know how to handle, because they’re not willing to listen to reason.

So, the translated version reads like this: We hired someone to develop this website for us, but he completed only half the project and bailed— Hmm. I wonder why? So basically, we need someone to come in and take the blame when the fit hits the shan at the end of the week. You game?

Here’s another one, not quite as bad as the ad above, but funny nonetheless.

Drupal/PHP Developer needed ASAP. Referral reward available. (Medford, MA)

Hello everyone,

We are a small web development firm located in Medford, MA. We specialize in open source application development using Drupal. We mostly create custom modules for Drupal or modify existing modules to meet the needs of the client. We are looking for someone who knows PHP very well and knows how to develop for Drupal…

You must be able to work on-site, preferably 3-5 days a week we are usually at the office 10am – 10pm almost 7 days a week so hours are very flexible. This might eventually turn into a full time position if you interested in the future but at the moment we are only looking to sub-contract individuals. This is a GREAT opportunity for a college student, recent graduate, someone looking for a job or a side gig.

[ . . . ]

About us: We are currently 3 people working at the company. We are all young professionals (24-26) and take our job and company very seriously. We also have a videogame room to relax in at the end of the day if you’re into that sort of thing.

Thank you.

• Location: Medford, MA
• it’s NOT ok to contact this poster with services or other commercial interests
• Compensation: Around $17-$28/HR rate might change based on the project + your experience

Custom Drupal modules? Again, right up my alley! They were actually doing pretty well (grammatical errors aside) until they hit that “college student, recent graduate” bit.

Yeah, there’s the “on-site” garbage—I believe I talked about that in another recent post. The only two reasons why they’d want on-site is (1) in order to make sure the project team could always communicate—unlikely for a project of this size—or (2) because they don’t trust the consultant—and that’s a wonderful foundation on which to build a new business relationship. But the “on-site” thing is something that can possibly be negotiated later, like the rate.

In this case, however, I think I can understand why they want an on-site contractor and why they might not trust the consultant (as it were) to behave professionally. Because they’re looking to pay “around $17-$28/hr” for college students or green-behind-the-ears brand-new graduates. That makes perfect sense, because they themselves (all 3 of them) are pretty green. And since they’re all in their 20′s, they probably want someone they can look down on (rather than someone who could actually make their project a success).

(And the line about the “videogame room” just cements that perception in place. Yes, having policies that allow developers to relax and to think is of upmost importance, but in this context, it seems like they’re just trying to appeal to the frat-boy element. I can even imagine them saying, as I was told on one interview when I was in my 20′s, “We know how to have fun here, but when it’s time to work, we work.” That comment made me suspicious even those many years ago, that the manager would think he needed to say that to me. And just imagining it now, makes me sick to my stomach.)

My prediction: These custom Drupal modules they’re building, as many of them are actually worth anything, within a year will be a hoard of living dead. Then they’ll need to start all over again from scratch. But they probably won’t. Instead, they’ll hire one hacker after another to try to keep the company afloat, like a poorly constructed boat with just too many holes designed into the hull. That’s fine, I guess, because it means they can always hire for the lowest common denominator. It also means they’ll be spending a lot more money in the long run, and getting less and less value as time goes on.

When they say they take their “job and company very seriously,” what they mean is that they have a lot of passion for it. Yeah, I understand that. I remember passion. I’m even still able to muster some, from time to time, in my old age. I also understand that a junior staff needs the benefit of someone more experienced, to offset the foolishness and inexperience of youth. If these guys were smart, they’d allocate $70-$100/hr (or more) for a veteran web software developer to come in once or twice a week (at the very least) and advise them.

Eh well. I guess we all have to make our own mistakes. C’est la vie.

-TimK

Last night, I brought my elder daughter to her fourth sleep study, but the first that I’d seen her to. Sleep apnea runs in the family, and the Missus suspects that I have it, too. One thing is certain, that I haven’t been sleeping well, and I’ve been perpetually tired. Sleep problems could even be a cause of my depression. So Margaret convinced my doctor to recommend a sleep study for me as well. Last night, I got to see what I’m in for this coming Friday.

We arrived at the sleep lab at about a quarter after 8 in the evening. Everything was already quiet and dark, as the hospital day staff had already gone home for the day, and my Beautiful One was the only patient to be using the sleep lab that night. I had never met the sleep technician, a short, quiet woman in blue scrubs, with dark skin and short, braided locks, whom you could always hear coming, because her white sneakers squeaked when she walked. I had never met her, but she and the Beautiful One were clearly well acquainted. I sat and watched as she taped more than two dozen probes to my daughter’s head, face, and body, turning my pretty, little girl into a Borg child from The Next Generation. Then I kissed the Beautiful One good-night, and turned in myself.

I lay down in an adjoining room, and I read several more chapters of Holly Lisle’s The Ruby Key. Then I started hearing wild voices, speaking in a garbled, muffled tongue, encroaching on my imagination. And I knew it was time to fall asleep.

The room was cold, and I woke numerous times during the night, shivering, feeling my icy nose, and too tired to get up and ask about increasing the temperature. But sleep I did, and I dreamed, dreams full of vigor and comfort. In one, my father was driving us home from the sleep center, and I was trying to give him directions. Most of the dreams, though, I no longer remember. Eventually, I came awake, but I continued to lay there in the dark, letting my mind wander.

I enjoy those first, quiet moments in the morning, when I can meditate on the day ahead, imagine all that I desire to accomplish, narrow down the list to those attainments most important, what I actually expect to get done. Too often nowadays, household activity interrupts my mornings: the girls running around boisterously or watching loud TV, the wife unloading onto my shoulders her daily worries, or just the irresistible desire to pee.

But this morning, I came upon the following daydream:

I was interviewing for a contract job at a company who needed custom PHP code for a Drupal site. (In real life, I had read an ad for a similar gig during the day, so that explains the setting for the daydream.) I was sitting in a small interview room, across a table from the hiring manager. I knew he wanted an on-site contractor and that he wanted to pay no more than $60/hr, because that’s what it said in the ad.

I asked him what sort of process the development team uses.

He answered, “What development team?”

“The other developers I’ll be working with,” I said.

“There are no other developers. We’re just getting started building a development team.”

“So…” Puzzled, me. “Why do you care whether the work’s done on-site?”

I already knew the answer. There are only two reasons for wanting a developer to work on-site: (1) so that he can communicate easily with other developers on the team; or (2) because you don’t trust him.

I told the manager about a recent episode of a documentary series I had seen. (In the daydream, I didn’t name the series; but for your information, it was the latest episode of Penn & Teller: Bullshit! And the following is a true story.) A man’s fiancée wanted him to take a polygraph test, because she wanted to know whether there had been any inappropriate sexual contact between him and the strippers at his bachelor party.

“And if he passed the test,” I said with a sarcastic lilt, echoing Penn Jillette, “she’d marry him and trust him forever after, right?”

As it turned out, there had been no inappropriate sexual contact, at least nothing I would have needed to hide from Margaret under the same circumstances. But the polygraph interrogator made it sound as though there were. The fiancée ended up in tears, the man was devastated, and their engagement was officially off.

“Good for him,” I explained, “despite how painful the experience was, because a relationship must be built on trust, or else it’s bound to result in failure. Now, we’re not marrying each other, but we are talking about a pretty close business relationship, where I will have access your mission-critical software, and you’ll be asking me to develop it.”

“Yes,” he objected, “but we have to be able to verify that you’re doing the work. Trust is earned, not given.”

Actually, trust is never initially earned. Rather, if it is ever to exist, it must be granted on spec. And having developers on-site does little to build trust, because there’s no way for any manager to tell what his developers are working on or whether it’s necessary for the project. We have a word for managers who try, though: micromanagers. And they are one of the death signs for a software development effort. But I didn’t say any of this to the manager in my daydream, because it wasn’t relevant to the discussion, and it wouldn’t have changed his mind anyhow.

Instead, I gave him a useful solution: “Usually, that’s done by giving a new developer a small job to work on, and then seeing how it comes out. So… You use Drupal, right?”

“Yes.”

“Presumably, you develop your own Drupal modules.”

“Yes.”

“Okay, so then you define a simple module for a new contractor, ask him how long it will take, and get regular deliveries throughout its development. You get a finished module, at minimal risk, with source code that you can analyze for quality, an invoice that tells you how efficient this developer is, and then you can decide where to go from there.”

“All right.” He grinned at me. “I need a Drupal module that will insert a dynamic date and time into a document. How long would it take you to deliver it.”

“Well, the first thing I’d do is to recommend a specification phase, where we can flesh out the details of what you really want. The specification phase for something that simple will likely only take a day, but then I can give you a more accurate estimate of what to expect.”

“But you said,” he objected, “that I should ask the consultant how long it would take, and now you’re telling me you can’t tell me how long it’ll take!”

“Well, that’s the answer you should get in response to the project description you just gave me, because it’s not specific enough yet. Any consultant worth his salt should tell you what I just told you, or else you should get a different consultant.

“Let’s do a simple spec right here, and I’ll show you what I mean. May I?” as I picked up a blue dry-erase marker and stood in front of the white board mounted on the interview-room wall.

“Sure,” he said, and he leaned back in his chair, crossing his arms.

“Now, when you say you want a module that will insert a dynamic date and time, what is it going to be used for?”

He explained that they needed to be able to display within the body of a node the time left until an offer expires, but that they imagine it would be useful to have the module also able to display arbitrary dates from the node’s metadata or to do arbitrary date math.

“Okay—” I interrupted him. “How do you know when an offer will expire? Is that a field set by some other module? Or are you using the scheduler module? Or some module for your online store? Or what?”

“Right now, we’re just hard-coding the date in the body of the node.”

“Okay, so the content author himself just writes in whatever date is appropriate.”

“Right. We have another module that automatically changes the node body to other content after that date passes. But we also want the text to read ’2 days and 3 hours,’ or whatever.”

“I see,” I said, and I wrote on the white marker board:

Replace “[timeUntil YYYY-MM-DD HH:MM:SS TZ]“
with “2 days and 3 hours.”

“Now, that won’t include any JavaScript or anything to update the message in real time.”

“Yeah, but it’s still better than what we have now.”

“So something like this would be good enough to deploy for your content authors and get their feedback.”

“Oh, yeah,” he said, nodding his head.

“I could do that within a week,” I said, “20 hours of work, completely tested, debugged, and ready for prime time.”

“You mean 40 hours?” he asked.

“No. I usually bill 20 hours tops per week. The rest of the time I dedicate to marketing, other project, and so forth.”

“How do you afford that?” He eyed me suspiciously.

“My rate for this sort of work bottoms out at $65 an hour.”

“Oh.” His face fell, and he looked at the table, deep in concentration. “We were looking to pay no more that $60 an hour for this position.”

“Yeah, that’s almost 10% less than my minimum rate. And you could get a newbie developer at much less, and may even churn out code faster than I would. But his code won’t work reliably, and you won’t be able to build on it after he’s done, because it’ll be a mess, because he’s new at the schtick. What you get from me is software that actually works, meets the requirements, and you can extend later if you need to. So that ‘time left’ module? My version you could easily add other features to, arbitrary date math or whatever, if you needed to. The newbie version, depending on how experienced the developer was, you might not even be able to figure out how it works.

“And a newbie developer won’t be able to assist you on defining requirements, as I just did, or in architecting your modules or web sites, as I can—I’ve built loads of websites from the ground up, and you can even see them on-line.

“$65 times 20 hours or less, or about $1300 max. So that’s the maximum you have to risk, and if everything falls apart, you still get to keep everything that I’ve produced.

“Better yet, I’ve just given you about $20 of free advice here, and you saw how fast we narrowed down the problem to a manageable size. And I can discount you the first 20 hours to $60 an hour. After that, I’ll invoice you, and you can decide what you want to do from there.”

I didn’t want to offer him a rate any lower than that, because the last time I worked for less than $65/hr, the client ignored every piece of advice I gave him, and the project was a disaster. I had offered him a reduced rate, because a friend was one of the partners at the client company, and they were a start-up short of cash, and I wanted to do them a favor. But people believe that they get what they pay for, and in an ironic twist of human nature, if you charge them too little, they’ll make a mockery of your expertise.

Even so, in the daydream, I could see that I had this guy on the hook, and I was reeling him in. I don’t know whether he finally offered me the gig, or under what terms—although there was some talk of my working at my own office, for expediency’s sake, rather than on-site. But whether he accepted or rejected my offer, I left the daydream knowing that I had taken control of the situation and had made my case, and that if he bought into what I had to offer, I at least had a reasonable chance of being happy with the results.

So, what’s the point?

Suddenly, I no longer felt depressed about looking for software-development work. I suddenly felt like searching for software gigs and sending out copies of my résumé. True story.

We often don’t realize the value or the power of daydreams. We think of them as frittering away time. But actually, they are part of the mind’s creative engine, both for bad and for good, for hardship and for prosperity. They have the ability to fill our lives with worry and drag us into the depths of emotional darkness, or to lift our spirits and help us to stretch our wings. They can make us impotent. Or they can empower us.

Here’s to the empowering daydream!
-TimK

The beautiful Jessia Hime in a particularly down moment; © 2008 Jessia Hime; CC BY-NC-ND 2.0

I’ve been updating my software-development résumé, trying some different things in hopes of finding a reasonably productive SD gig. Along the way, I think I may rub a few people wrong, but I think it’s for the best. Because it’s the only way I know to ultimately accomplish my goals.

There’s something about the truly great accomplishments in my life that sets them apart from all the others: they were preceded by devastatingly tough times. One such accomplishment, of course, was meeting my wife Margaret. Before that, I dated girls who were bound to cause me heartbreak; I pursued girls that were bound to make me miserable; when I did meet a nice girl who could make me happy, I was sure to sabotage it (or ignore her). I spent 10 years in heartache after heartache, depression after depression.

But as many times as I swore off girls forever, I continued to play the sucker for the next pretty face that came along. Why? Because there’s an instinctive drive, deep in the heart of a man, that compels him to love a woman. Time and again, that drive forced me on and kept me trying again and again, until I found something that worked.

When the answer finally came, it was so simple, I wondered why I hadn’t discovered it before.

I have a feeling life is like that. You have to fail a few times, or a few dozen times, before you find the simple formula that works.

I was a software developer when I met Margaret in 1992, and I’ve been developing software for most of the years we’ve been together. After 20-something years of experience, the software-development industry has earned in me a certain amount of disgust. So the prospect of working as a software developer again rightly makes me wretch.

But the truth is that designing software is an enjoyable and creative endeavor, and one that I do damn well. I spent 14 years with a very special company, who developed electronic musical instruments, and I designed embedded software therefor. They were special, because so much of what the software industry does so wrong, they did right. It was fun to work there, as though we were a family. It was the fairy-tale job of TV-show heroes. It was like working for Captain Picard’s crew, or for Cage & Fish. I loved it there.

And after the company got bought out and laid off most of the staff, the crash of reality. I’ve never completely recovered.

Actually, I did spend many numerous hours, a couple years ago, working with a virtual team, as subcontractors for a large company. That was an enjoyable project to work on, not because of the project or the technology or the code or the company, but because of the people I was working with. We actually proved, through success, that it is possible to make a virtual software development team work, and what is needed to make it work.

But that was the exception that proves the rule. Why should I want to go back to full-time software development, when my colleagues assault me on every side with their own stories of horror?

And yet, because of the money situation, I fear I may have to pick up a software-development gig, even for just a few months, because it pays so much better than writing does for me right now. And if I pick up the wrong SD gig, it may kill me. (Whether or not that is hyperbole I will leave to your interpretation.)

This is the feeling of utter hopelessness that accompanies a severe depression. The feeling of being backed up into a corner, your life falling apart around you, no options, just misery, and the longing to curl up in bed at night and quietly never to wake up again.

And yet I know that the hopelessness is temporary, because 16 years ago, I found the secret of love, and I got Margaret.

And so I know if I try something a little different, maybe I’ll find that perfect software-development gig. Or maybe I’ll find the secret to making my writing profitable enough. I’m a good enough writer, because I’ve already overcome that hurdle; I’m sure of it. But as always, the challenge is the Big M: marketing.

Even as I write now, I continue to learn more and more about marketing, and specifically the kind of marketing that will help me, both in writing and in software development. If I try enough different tacks, I’ll finally hit on one that will sell my books. And probably quickly and easily. I know that if I try enough different résumé and interview tactics, that I’ll finally find one that will land me the right SD gig. Whatever the goal, wherever the hopelessness, I know that if I persist, I will succeed. And that, friend, is hope.

Here’s to hope…
-TimK

I’ve become used to extraordinary jobs, not “normal” jobs.

The following 10 things, which I hate about software development as practiced in much of the industry, I think will keep me from ever being successful or happy in a “normal” software-development job.

Along with them, I list the antiviruses that I hope will help me avoid these diseases, if I need to go back into software development, even temporarily.

1. Incompetent managers. Software development managers in general graduated from being software developers. Unfortunately, the skills you need as a developer are different than the skills you need as a manager. The best manager I ever had was not a particularly good or experienced software developer. Rather, she treated management as a profession, read books on how to be an effective manager, attended seminars, took classes, and as a result, she was good at her job. But most software-developers-turned-managers don’t treat management as a profession. Instead, some of them become telepaths, who expect you to know what they need without actually telling you; others become micromanagers, who expect to be able to do all the actual development themselves, using your eyes and hands and brain; still others become arguers, the worst of both worlds, who instead of letting you do your job, take great pride in pointing out everything they think you did wrong. So the next software job I take, I will be interviewing and trying managers carefully to make sure they know how to manage, regardless of whether they are good developers.

2. Snotty developers. I must confess to going through a snotty phase myself. It’s part of growing up. You have to live as a snot-nosed, young-whippersnapper, green-behind-the-ears code slinger before you can mature into a wizened Yoda figure. In fact, part of me still may be a snotty developer. I’m definitely snotty when it comes to my own work, because I don’t want anyone telling me how it should be done, as long as I achieve the intended results. But as someone who’s been doing this shtick for 20-something years, I’ve grown weary of junior colleagues telling me I don’t know what I’m talking about. And when something doesn’t work out as well as they thought it should, they persistently maintain that it had nothing to do with them, despite the fact that they had ignored every piece of advice I gave them. There’s only one sure-fire remedy I know of for this problem, and that is to insist on a higher rate of pay. People may balk at paying you through the nose, but when they have to—especially managers—they not only accept your advice, they seek it out, because for the money they’re paying you, they expect you to solve their problems.

3. Commoditization. That is, the devaluation of specialized knowledge. The most obvious manifestation of this disease is the company who outsources its development to a third-party contract shop in India or Mexico, and then wonders why the project is falling apart at the seams. A more insidious and pervasive symptom has employers and clients boil a job down to a long list of buzzwords, pattern-match résumés to those buzzwords, interview you to make sure you really do qualify for the buzzwords selected, and then look for the lowest price. And then they ask you to do everything under the sun, including those tasks that could be handled by a $20/hour contractor from Mexico. Instead, they ought to be looking for solutions to specific problems or for people to fill specific roles within the organization. For veteran jobs, that’s no longer about price, however, because if you’re specific enough, you’ll likely find only one or two qualified candidates, if you search for them, and whatever they want to charge you, you’ll pay. Again, the only sure-fire antivirus I know of is to demand a higher rate of pay, because for the money they’re paying you, they won’t treat you like a commodity.

4. Slipshod engineering practices. I am one of those programmers who actually believe software development is engineering. Many developers don’t believe in software engineering, or at most give it only lip-service. But software engineering is like gravity: you may not believe in it, but the result is the same when you step off that cliff. Developers who don’t believe in engineering experience bugs, hold-ups, overwork, and stress. To account for it, they blame the code, the programmers who worked on the software in the past, their development environment, the operating system… But they never do anything to fix it, because “we just don’t have the time.” Note, however, just because developers complain about not having enough time to fix the system doesn’t mean they’re using slipshod engineering practices. In fact, those developers who don’t complain are probably the worst offenders. Often, good developers complain about the code, but it’s really not that bad, because they’ve already fixed the worst parts of it, and the problems that are left just stick in their craws. These are the developers I’d love to work with. The quickest way I know of to assess the situation is to look at the code: Is it well-architected? Well-designed? Are there unit tests? If so, the team is probably using good engineering practices.

5. Neglect of quality. By “quality,” I don’t mean over-designed, fluffy, overly glitzy software. What I mean is, simply, software that works, that satisfies the customer’s needs, makes the customer swoon, has no bugs, does not constantly poke you in the eye—”See that?!” Ow! “See that?!” Hey! Cut that out! Quality is important, because it gives a team of engineers a sense of accomplishment, of pride, a healthy morale. And engineers who value quality will be professional, always improving their craft, always building better and better software. Again, a quick glance at the codebase should give some idea as to how highly the team values quality, because a quality team will use sound engineering practices. But you could also look at the finished product, and especially customer comments on the product and its support.

6. Black-and-white thinking. Frankly, I hate having my good ideas shot down with dismissive comments like: “Unit tests don’t catch every bug.” Yeah, but they catch more bugs sooner and cheaper than any other method of testing. Polarized, black-and-white thinking is actually a sign of depression, of hopelessness, of having given up. “My life isn’t perfect; therefore, I have no reason to live.” Sounds silly when put that way. But how many software teams are in a similar, self-imposed depression? “That technique can’t solve all our problems; therefore, it’s not even worth trying.” Almost every team has a naysayer, but such sentiments can cause actual depression in the more innovative among us, who actually want to better the team and its engineering practices. The antivirus is simple, if not easy: Early in working with a team, try to find one or two simple process problems and propose simple, direct solutions. Then sit back and see what happens. If you get a lot of hemming and hawing and ignoring and naysaying, think about whether you should split.

7. Focus on establishment. Humans have a natural need for stability and for camaraderie. That is, they need to feel like the floor is firm beneath their feet and that there are others on their side. But in some companies, these tendencies can become dysfunctionally pervasive. If you continue to do only what you’ve always done, only what everyone else is doing, you’ll always be safe from blame. But humans also innately need to do what they haven’t done before, to stretch their minds, to create. Because this gives one a sense of purpose. Rather than playing it safe, we should always be trying new things, and keeping those that work. But the dysfunctional company focuses on establishment, rather than on results. The antivirus is similar to that for black-and-white thinking. Early in the experience, try something new, and then see what happens. Do it early, before you develop an emotional investment in the project. It might even be best if the thing you try fails completely, because then you can see how the team handles failure. Even if your experiment fails, they should not make you feel like a failure for having tried it. If they do, think about whether you want to stay there.

8. Ignorance of modern research. Quick! Name at least 2 of the 9 teamwork-killers Tom DeMarco and Timothy Lister identified in their landmark work? It should be pretty easy, because they identified 7 of those 9 back in 1987. That’s what I mean by “modern.” Here’s another one: What 3 characteristics must a software team exhibit in order to have any reasonable chance of success, according to Alistair Cockburn in his research? Peopleware (2nd ed. 1999) and Crystal Clear’ (2005), for starters. This is what I mean by “modern.” Heck, we might as well even include The Mythical Man-Month in the list, because too many software engineers have never read it, either. At my next interview, while the development staff are quizzing me on my knowledge of Perl, PHP, and JavaScript, I’ll be sure to quiz them on their knowledge of Demarco and Lister, Cockburn, Schwaber and Beedle, Kent Beck, Michael Feathers—and of course, Frederick Brooks.

9. The blame game. Being caught in the blame game can cause stress, exhaustion, demotivation, and depression. It can also be the source of other maladies, such as black-and-white thinking, as engineers attempt to cope. Unfortunately, staffers don’t usually like to talk about the blame game, but a pointed interview question might reveal something. Something like: “Tell me about the last, big mistake someone made that cost the company money.” What was the fallout? Did anyone get yelled at? Fired? In a perfectly healthy organization, no matter how bad the error was, no one will have gotten yelled at; rather, it will just be accepted that everyone makes mistakes, because we’re all human, and the whole team will have looked at the process (rather than any particular person) to see how to avoid an analogous oops in the future.

10. Unrealistic expectations. I’m talking about the top-down variety here. Yes, engineers can—and frequently do—have unrealistic expectations of themselves. But that’s easily enough fixed. (Or at least I know how to fix it, with a bit of measurement, in my own estimates.) But I’m talking here about something different: Management wants such-and-such at such-and-such a date, and they won’t accept your promise that it simply can’t be done. When faced with such a situation, there are only 4 things you can do: Deliver less functionality. Take longer to deliver it. Reduce the quality (leading to delays because of unexpected bugs, and see #5 above—better yet, forget about sacrificing quality). Or spend more money (but adding people to a late project only makes it later—that’s Frederick Brooks, see #8 above). Management, under pressure, may not want to make real-world trade-offs, leading to overwork, demotivation, and depression for the engineers. Like the blame game, I don’t know any sure-fire way to discover this problem early on, because no one wants to admit to a new recruit that he’s walking into the lion’s den. But you might try asking about the team’s last overconstrained project or iteration, with a knowing, Columbo-esque gaze, and see if it prompts any reaction at all.

Now, if you happen across this blog post because you’re considering me for a job position, and if you think that I’m being abusive and unreasonable here, well, that might be a hint that I don’t want to work at your company.

Just a thought.

-TimK

But before I worked there, I tried to work at a supermarket, like my very first job.

This first job I worked as a teenage, after school, bagging groceries, then promoted to ringing up orders on the cash register, then to behind the customer-service counter.

I finally left in order to work with computers, mostly programming Lotus 1-2-3 macros for a small, local, financial-services firm.

From there, I went on to building electronic circuits at a centrifuge company, a co-op job I got in college. During class breaks, I worked full-time there; otherwise, I worked part-time after classes. And when the company’s embedded-software engineer left for greener pastures, I stepped in to fill his shoes… temporarily, until they could hire a “real” engineer. (I guess the fact that I had already had several years of real-life experience in computer programming and electrical engineering, and that I had been designing production code for them on several products, I guess those facts didn’t make me a “real” software engineer.)

So when I quit college—which is a different story—and the co-op-turned-temporary-fake-engineer job ran out, I was left without work and without direction.

I got a job at a local supermarket, behind the deli counter. I remember it feeling more natural and more pleasant than when I had previously worked at a supermarket, because i had grown a little and had experienced more and was no longer just a quiet, bumbling teenager, as I had been before.

Even so, after the initial probationary period, the deli manager told me he wasn’t sure I was working out, because some of his managers thought I was uncooperative. For example, one night, the manager asked me if I wanted to clean the slicer. I didn’t really feel like cleaning the slicer, so I answered her honestly: “No, not really.” So she gave me something else to do. Now, if she really wanted me to clean the slicer, all she would have to have said was, “Clean the slicer,” and I would have done it. But she didn’t say that. Instead, she asked me what I wanted to do. And when I responded honestly, she thought I was being insubordinate.

I realized that I had fully passed from the world of automatons, where employees are not expected to have original thoughts, to the world of professionals, where everything one does requires unique thought— And right about now, you’re thinking that I can’t possibly be describing the Dilbertesque world of software development… But that’s getting ahead of the story.

When the centrifuge company asked me to come back and do a little more work for them, temporarily, I took it. And when that conflicted with the deli job, I called and told the deli manager I couldn’t make it. He shouted at me over the phone and told me that I never thought of anybody but myself. Just like that, using those words. And his words apparently had the desired effect, because they really upset me. I called my father, who told me that I had to think about my career as more important than a deli job; and that I wasn’t even a full employee, because the deli manager had kept me “on probation”; and that the real reason he was yelling at me was that it was his job as manager to handle situations like that, and I had caught him with his pants down.

I returned my smock to the supermarket inconspicuously, in such a way that I wouldn’t have to deal with the deli manager. I did not say goodbye. I just never came back. (And I also avoided that supermarket for several years, even to buy groceries.)

Then a colleague of mind, an intelligent budding engineer who I had met at the centrifuge company, still today one of my closest colleagues, now an excellent software engineer, one of the best I know, who has helped me in my career more than I could ever return the favor, he tipped me off to an electronics documentation job at an electronic musical instrument company, the makers of Kurzweil-brand synthesizers and keyboards. That job eventually turned into a Diagnostic Software Engineer position. I started as an on-site contractor; then they hired me full time. From then until the time they laid me off, 14 years, almost to the day.

I didn’t realize how special that place was. When I started there, i was still a headstrong, snot-nosed kid. But they allowed me to be myself, and to grow, and they paid me for it. This was a small (less than 50 people), tight-knit group of enthusiastic engineers, of various disciplines, who loved music and loved contributing and loved creating quality musical instruments.

But after the parent company was bought out, and my job (along with those of most of the remaining staff) was reorganized out of existence, I was laid off, officially on April 1, irony.

I took several more software-development jobs, first as an employee, then as an off-site consultant. But what I found was that if organizational madness exists, there’s really no way to isolate yourself from it. I started writing full-time, because it allowed me to stretch myself and to create and to enjoy my work again, despite the fact that there’s little money in it, especially for a relatively new author who hasn’t yet developed a base of enthusiastic fans.

But with the current money situation, I fear I will need to find another software-development job, even just as a contractor. And when I say “I fear,” I mean that in its most literal sense. The whole idea looms before me as a horrific monster, which I would do almost anything to escape. Because for me right now, going back to “normal” software development is like going back to that grocery-store job, working behind the deli. I have gotten used to being creative and independent, to think outside of the box, and to value accomplishment. And even if I find programming an enjoyable diversion, the simple truth is that I no longer belong in a Dilbert cube.

-TimK

P.S. It occurred to me (much later) that I mentioned this almost 3 years ago, when I talked about leaving normal. I guess it’s still true.

[Note: This is a recounting of an experience from several years ago. Read the story from the beginning in order to catch up.]

According to psychologist Joe Griffin, the cycle of depression starts when innate needs are not being met. Among these are a sense of achievement and knowing that we are valuable to others. Setbacks like this, however, are just a part of life. What turns setbacks into depression is when they dominate one’s thoughts, they overwhelm him, and he loses hope.

Unfortunately, if my previous work situation epitomized camaraderie, this one did the opposite:

• Teams of engineers never got comfortable working together, because each was expected to show continuous progress on several projects at once. Therefore, one spent only a fraction of the time working with the same person on the same project.
• People working together on a project lived in cubicles long distances from each other, making communication a continual chore. The person I worked most closely with lived a 30-second walk from me, and I had to make a daily effort to say drop by and say “hello,” or else I might not see him for days at a time.
• We didn’t have motivational posters hanging on the walls–Thank God! But my manager would append would-be inspirational quotes to his weekly department status reports, such as “A professional is someone who can do his best work when he doesn’t feel like it. – Alistair Cooke” Oy vey!
• Shortly after I was hired, the company re-adjusted its pay-scale, to compensate for the dot-com years, they said. The end result was to cut the salaries of some of the most senior engineers. They soon thereafter resigned. Morale? Who needs it?

And then there was the fact that I got shot down over and over again, whenever I stepped out on a limb. The company that I thought should have been supporting me was instead shaking the tree.

Some of the poetry I composed during that time reflected my melancholy. It was then that I penned “Living Inside a Top,” a poem which begins:

I’m not leaving.
But my resume is up to date.

I also wrote “A Tribute to Lorelai,” which compared my situation to that of a spider’s dinner, as the spider performs its natural function, sucking the life-force from its prey.

I was miserable, because I felt like I could accomplish nothing, and I blamed my employer. I asked one of my coworkers, who was also a personal friend, “How long does it take before you get used to it?” He replied sadly, “You never really get used to it.” Some days, I would sit in my cubicle, browse job listings, and send out resumes and queries, just to make myself feel better.

I was wrong. I felt like I could accomplish nothing, but during my one-year stay there, here are a few things I accomplished:

• I took an out-of-control diagnostic-software project, and I brought it back under control, and I delivered it on time and within budget.
• I successfully figured out how to end-run around the corporate bureaucracy, in several cases.
• I learned a great deal about working with kinds of people that I never would have encountered anywhere else.
• I successfully turned an antagonistic relationship with one engineer into a friendly relationship.
• I successfully adapted XP-style project management to the project I was working on.
• I successfully negotiated with my manager to work on only one project at a time, for stretches of at least a few days.
• Even though engineers were (I was told) expected to put in massive overtime hours, I held my ground and worked at a sustainable rate, and my performance reviews didn’t seem to suffer as a result.

But my perfectionist thinking wouldn’t allow me to be happy with that. If I got shot down even once, it made me feel useless. This is why perfectionists are more prone to depression, because they think in blacks and whites and tend to overlook the silver-lining. I never considered that just because the company was screwed up in some ways, that didn’t mean it was also workable in some ways, and that I could still accomplish something, and that I had proven it by actually doing so.

Fortunately, I did find another job, and my depression lifted, because I had a renewed hope and vigor.

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

If one of the most powerful weapons against depression is hope, one of its most powerful fuels is hopelessness.

I attacked my next job with gusto and enthusiasm. The company had previously outsourced a project to an offshore contractor, and now that the fit had hit the shan, they were looking to bring it back in-house. The product was a stand-alone box with embedded software, and they hired me to take over the hardware diagnostics, which are used to ensure that the units sent to customers actually work.

Somewhere, I read that it takes six months for a new employee to become situated in a new job. But I did it in four. And then I crashed. Hard.

Prior to this time, I had been working in small companies. In a small company, when something needs to be done, you do it and get it done. At the time, I didn’t realize that in a larger company, there are people hired into key roles, whose job functions include preventing you from accomplishing anything too useful.

For example, when manufacturing powered up a new unit for the first time, they needed to install the software that ran it. This software came from the software department. Of course, as a diagnostic engineer, I worked in the hardware department, not the software department. That meant that after the manufacturing tech installed the device’s software, he needed to go through a whole separate process to install the hardware diagnostics. Now, when you’re building up thousands of these boxes, adding an extra step on each one is expensive. So the manufacturing engineer asked me if I could package things up so that he could install both the main software and the diagnostics in a single step.

Like an idiot, I told him that it should be no problem, and I set about making it happen. I talked to the release-engineering department and found out what would be required to get my files into the main software distribution. No problems there. Then I tracked down the software engineer who could modify his installer to install my files. In toto, we needed to tweak three lines of source code. We all seemed to agree it could be done quickly and with minimal risk. Everything seemed to be coming together nicely.

Then the software-department manager got together with my manager, and they quashed the plan. As I understand it, they were afraid the change might break something in the software release, and they didn’t want the CTO to blame them when the software was delayed.

As a result, that three-line tweak took six months to deploy.

In retrospect, I understand. After all, the software manager didn’t care how much time or effort or money that three-line change would have saved, and he didn’t care about the manufacturing engineer, and he didn’t care about me. He only cared about not being blamed for introducing more bugs into an already-late and out-of-control project.

My manager at least was big enough to deliver the bad news to the manufacturing guy personally. He stood behind the decision he had made and didn’t expect me to explain it, and I respected him for that. But that didn’t change the way I felt about being shot down.

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

Knowing what I know now, I wonder how I avoided depression for as long as I did:

1. Stress causes depression.
2. Perfectionists are more prone to depression.
3. Isolation reinforces depression.

As a software developer, those frequently go along with the job description. Seasonal Affective Disorder has gotten the rap for at least some of the funk, because many software guys spend most of their time indoors, duty-bound to their office chairs. But surely SAD can’t take all the blame. Long hours of solitary work in front of a computer screen, the amateurish demands of tech-heads-turned-managers, the over-constrained projects, the intolerance we have toward bugs, the widespread myth that software is “free,” and (most importantly) how we as developers respond to these pressures, all these must take some share of the blame for developers’ depression.

Several years ago, I experienced my first major bout of depression. I had been working at a small company for umpteen years. If you’ve never worked at a small, tight-knit company, you may not understand the camaraderie that grows between its members, which keeps the company going, even through the lean times. This is not just some abstract “teamwork” concept, but an inspiration and effectiveness that comes from years of solving problems together. We literally loved our work environment, and we loved working together. I loved working there so much, I had remained there all during the dot-com boom years, turning down headhunter after headhunter, even with the promise of exciting work and a higher salary.

In retrospect, if I have one big regret, it is that I didn’t pursue other jobs and higher salaries during the dot-com years. Because just before the company was bought out and I finally got laid off, I was making about 25% less than the going rate for engineers of my experience and skills. Meanwhile, recent layoffs at the company had saddled those of us who remained with more work than ever. And because of family demands, I was struggling to find enough hours in the day to get my job done.

As a family, we were stretching to make ends meet, and our credit-card debt was mounting. My wife was also working part-time, and starting her own business the other part of the time. The kids were in daycare, and each day I drove through rush-hour traffic to pick them up before 6 PM. Then on the way home, I sat bumper-to-bumper with the other cars on the road, while the kids shouted and fought, much too loudly for the interior of our small family car.

Everyone at work was in the same boat. Some of the most senior employees had even taken a pay-cut to keep the company afloat. And we all wanted the situation to continue, because we all loved working together. But I was still not earning enough to support my family, and there were too few hours in the day to accomplish what I needed to accomplish.

I should have been interviewing for other jobs. But my current employer had been more than flexible with my schedule, to allow me to see to family demands, and I didn’t see how I was going to find another job that got anywhere close to what I needed.

That winter, I felt particularly down. I was having trouble focusing on my work. I found I loved to watch TV, and I often had the TV on in the background while I was working at home. I suffered from frequent headaches, and I developed a nervous twitch in my left eye. One late-winter day, I sat down in my cubicle at work, in front of my computer monitor, and I simply began to cry. I blamed Seasonal Affective Disorder.

In a supreme twist of irony, I was laid off that April-fools day. Getting laid off was the best thing that could have happened to me, because one of the most powerful weapons against depression is hope. When they told me I was among those laid off, I remember feeling euphoria, because a great burden had lifted off me.

That day, my left eye stopped twitching.

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