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.

(To be continued…)

This blog post is a selection from a new book I’m writing, tentatively titled I Never Thought I Was an Idiot! Confessions of a Veteran Software Developer, exploring the many missteps programmers make. It’s written in a humorous, self-deprecating style–and serious at times, as the story demands–and my hope is that you’ll see yourself in some of the anecdotes. If you think you’d be interested in this book, please…

• Click here and take 10 seconds to register your interest.
• Subscribe to this blog in order to read more snippets and stay up to date on the progress of the book (or subscribe via email using the form in the upper-right of this page).
• Leave a comment below.

Check out the other posts in this series.

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

This blog post is a selection from a new book I’m writing, tentatively titled I Never Thought I Was an Idiot! Confessions of a Veteran Software Developer, exploring the many missteps programmers make. It’s written in a humorous, self-deprecating style–and serious at times, as the story demands–and my hope is that you’ll see yourself in some of the anecdotes. If you think you’d be interested in this book, please…

• Click here and take 10 seconds to register your interest.
• Subscribe to this blog in order to read more snippets and stay up to date on the progress of the book (or subscribe via email using the form in the upper-right of this page).
• Leave a comment below.

Check out the other posts in this series.

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

This blog post is a selection from a new book I’m writing, tentatively titled I Never Thought I Was an Idiot! Confessions of a Veteran Software Developer, exploring the many missteps programmers make. It’s written in a humorous, self-deprecating style–and serious at times, as the story demands–and my hope is that you’ll see yourself in some of the anecdotes. If you think you’d be interested in this book, please…

• Click here and take 10 seconds to register your interest.
• Subscribe to this blog in order to read more snippets and stay up to date on the progress of the book.
• Leave a comment below.

Check out the other posts in this series.

Software developers have a wonderful explanation for why there are so, so many software bugs. Unfortunately, it’s a highly technical explanation that’s very difficult for the layman to understand. I’ll try to summarize, but be aware that the following is a gross oversimplification.

The root problem is that software is complex. And it’s not just that software has complexity. It has a lot of complexity. And there are different kinds of complexity. For example, there’s necessary complexity and unnecessary complexity, architectural complexity, design complexity, protocol complexity, and API complexity. And then you have process complexity, such as whether you are able to deliver working software or whether you blame your manager and call him a dork.

Needless to say, software developers like to blame bugs on the complexity of software–or on their managers–but mostly on the complexity of software. However, that’s only part of the real cause of software bugs. Software developers have a dirty little secret: most bugs are simply caused by simple human error, and many of these can be prevented.

Back in the day, I designed some software to factory-test audio equipment. This is back before we had source-code control and automated regression tests–as if most projects today have automated regression tests. I was working on the project alone, without even anyone to do QA for me.

At one point, the factory asked for a small change to the software. It amounted to one line of code, a trivial change. So I made the change and sent out the modified software. The guys at the factory installed it and tried running it, but it didn’t work, not at all. So they emailed me back, and the next day, I looked into the problem. I had made a critically stupid mistake. There was a simple typo in my code. Obviously, I had not tested my testing software. How is that for irony?

Fixing the bug took me only 30 seconds, but this 30-second bug had cost the time and convenience of several people in at least 2 departments of the company. Bugs are many times cheaper to fix before you send the software to production.

My manager asked what had happened, and I told him. He then advised me, in future, to test my changes things first, before sending them out. And not being a complete idiot (only a partial one), I agreed with him.

This experience is one reason why I am such an avid believer in automated testing, because simple unit tests could have caught that bug before it left my hands… although even good automated tests can’t save you if you don’t pay attention to them, and sometimes we do ignore them.

I’m not saying that software developers are incompetent, only that they’re human, and humans make mistakes. Developing software involves making choices about what code to write and what code to put off, which bug to chase and which one can wait until later, what lead to follow up on first, in order to get the biggest bang for the buck. That’s why you can never depend on the perfection of software developers to eliminate bugs, but you can depend on human incompetence to create more of them. Developing software is knowledge work, and knowledge work requires choices. And experienced software developers aren’t really better at it than newbies. It’s just that veteran developers have learned rules that compensate for their natural human incompetence, when they actually follow them.

Many years later, I encountered another opportunity to prove the incompetence of human nature. I was helping a client develop a web-based system, named with a three-letter acronym that no one knew the meaning of. Here I’ll call this system “YUM,” because those three letters are as good as any other three. This system managed the client’s business processes. Now, only certain employees and clients could log into the system, and when one logged in, he was only able to see certain data and perform certain actions, depending on his role in the organization.

YUM didn’t know anything about which users were allowed to log in and what they were allowed to do, but it found out this information from another system, which had no name. We found it difficult to talk about this other system, but somehow we found a way. For the purposes of this story, I’ll call it “YUM-LOGIN.” Now, the client was upgrading YUM-LOGIN to a new system that supported all the software they used, not just YUM. I’ll call this new system “MUY-LOGIN,” from a Spanish word meaning “YUM spelled backwards.”

Migrating to the new MUY-LOGIN was straightforward: I refactored the existing code to support multiple authentication methods, split out the YUM-LOGIN code into a separate authentication module, and created a new authentication module to support the new MUY-LOGIN API. (And yes, this is actually “straightforward” to a software developer. Remember what I said about complexity.)

I could tell the new MUY-LOGIN code worked, because the QA guy and I could test it. But how could we know that the old YUM-LOGIN still worked? It was “too difficult” to write a true unit test for this legacy code, because it was too poorly designed. Software development is knowledge work, and knowledge work requires choices, and that was Choice One. In retrospect, I should have bitten the bullet and written some unit tests before I refactored the YUM-LOGIN code, but I’m getting ahead of the story.

The only test we had for the YUM-LOGIN code fetched some test data from one of the production servers. This is a poor way to test software, and especially in this case, because the YUM-LOGIN server subtly changed its behavior over time. We needed to update our test from time to time to account for undocumented changes in the way that YUM-LOGIN responded to it. As a result, we weren’t always able to tell whether our code was actually broken, or whether the YUM-LOGIN server was going yucky again.

So when I noticed that the YUM-LOGIN test was failing, I figured it was just the server acting up again, and I didn’t investigate any further. That was Choice Two. I figured that it really wasn’t that important anyhow, because we had no plans to use YUM-LOGIN anymore, because we were migrating to MUY-LOGIN.

I double-checked my changes, confirmed that everything else was working, and released the code. The QA guy on the YUM project helped me test and debug this code, and I couldn’t have done it without his help. But he too was only testing against MUY-LOGIN, because he didn’t have a server set up to use YUM-LOGIN, because we weren’t planning to use it anymore.

Inevitably, when the client deployed the new version of YUM, the MUY-LOGIN server didn’t work as expected. The guys who were developing MUY-LOGIN needed to fix some additional stuff in order to support YUM. Oops. But until that could happen, the client enabled the old YUM-LOGIN code–good thing that I had kept it in there!–except that they couldn’t get it to work. The only thing left to do was to roll back YUM to the previous version, until we could get the issues straightened out.

At first, I thought that maybe the YUM-LOGIN server was no longer working right, because my YUM-LOGIN test was failing. But that turned out not to make sense, because the previous version of YUM still worked fine. And then I noticed that our YUM-LOGIN test also passed with the old YUM code. That meant that I had actually broken something when I added the MUY-LOGIN support.

I finally tracked down the problem to a bug in my changes. I had refactored the code incorrectly–another typo–and I had left off a required parameter. Of course, all of this rigmarole could have been avoided, if only I had actually listened to the automated test when it told me that I had broken something. That’s what the test is there for, after all. But I had on good-faith belief doubted that the test was lying to me and that my code probably worked, based on Choice One and Choice Two, which most experienced software developers could see themselves making just as I did.

What can we learn?

1. Never depend on human perfection for quality software.
2. Always test your code.
3. Always test it several times, at different levels.
4. Use unit tests and automated system tests and manual QA testing.
5. Even though writing unit tests can be hard when it comes to legacy code, it may very well be even harder and more expensive (not to mention embarrassing) to hunt down bugs without the benefit of unit tests.
6. If you doubt that a test is giving truthful results, find some way to verify it (like running it against a known-working version of the code) before just writing it off.

This blog post is a selection from a new book I’m writing, tentatively titled I Never Thought I Was an Idiot! Confessions of a Veteran Software Developer, exploring the many missteps programmers make. It’s written in a humorous, self-deprecating style–and serious at times, as the story demands–and my hope is that you’ll see yourself in some of the anecdotes. If you think you’d be interested in this book, please…

• Click here and take 10 seconds to register your interest.
• Subscribe to this blog in order to read more snippets and stay up to date on the progress of the book.
• Leave a comment below.

Check out the other posts in this series.

That’s what I did at my first job. Well, I considered it my first “real” job, though it was my second steady job after I quit the grocery store. And you could have called the IT job I had previously held a “real” job, because it did involve some programming. But I considered this new job the first of my then-yet-to-be career. (Looking back over the past 20-something-odd years, I wonder whether I ever had a truly “real” job, or whether they were all just time-fillers until I figured out what I really wanted to do with my life.)

This company originally hired me as an electronics lab technician for the summer, after I finished my freshman year of college as an electrical-engineering major. Because I was only a co-op student, they paid me bargain-basement wages and gave me less than zero respect. This didn’t bother me, because I was young and impetuous and didn’t care what the old fogies thought. Still, the job turned out to be wonderful practical experience, and I continued working there part-time even after classes resumed. And it turned out to be a career-changing opportunity.

At this company, we made centrifuges. A centrifuge is a finely tuned piece of laboratory equipment, a complex, electromechanical device whose sole purpose is to spin stuff around really, really fast. You may have seen one in your doctor’s or vet’s office, that whirring, little box that spins your blood around at thousands of rotations per minute, until it’s dizzy enough to be psychoanalyzed. I started working there just after they began designing centrifuges with computer brains inside them. (Hereafter, I will use the term “microcontrollers” rather than “computer brains,” because I want to sound smart.)

In a turn of fate, I designed one of this company’s most innovative, microcontroller-controlled control systems–which sounds way smarter than “computer brain”–and I ended up dropping out of the electrical-engineering biz and taking up software engineering, forever.

It all began when my manager asked me to investigate a new microcontroller, the 68HC11, or “HC11” for short. The HC11 wasn’t actually new technology, and they actually didn’t want to use the HC11, but the old microcontroller they had been using was so obsolete, they couldn’t get parts anymore.

This company, like many, suffered under a caste hierarchy among engineering disciplines. The mechanical engineers were in the top caste, and electrical engineers were second-class citizens. This couldn’t have been good for morale. During the time I was there, everyone in the electrical engineering department quit, one by one, except for the manager, who left soon afterward.

As engineers left for greener pastures, another co-op student and I gradually took on more and more of the responsibility of developing the hardware and software for new products. And when the software engineer quit to take a better job, I ended up writing all of the the embedded software.

But if electrical engineers were second-class citizens, then what were we, the electrical co-op students? I already mentioned that they gave us less than zero respect, and this didn’t change just because we were now doing real engineering. Even though we were doing much of the design, we were never invited to the project staff meetings. And we were never consulted on specifications for the products we were designing, even though we understood the designs better than anyone else in the company. But I found a way to get back at them.

I was tasked with programming the embedded software for the first HC11 product, soup to nuts. I asked the hardware engineer to make a simple, harmless change to the tachometer circuit, which measures how fast the stuff is spinning in the centrifuge. This was to make my job easier, or at least that’s what I told the hardware engineer. In reality, the change allowed me to measure how fast the rotor was spinning about 100 times more accurately than was ever possible before.

Using the power of the new microcontroller, the HC11, I designed revolutionary, new tachometer software, coupled with a revolutionary, new motor control, which actually modeled the physics of the centrifuge. By the time I was finished, the display showed the rotor speed to within 10RPM, but in reality, the system was controlling it to well within a tenth that. None of this was in the product specs–which, by the way, I never got to see. But it was too late, we joked, because the feature was already in code, and I couldn’t take it out now.

This was a huge surprise to the marketing guy, and when he found out–or so I was later told, because I still wasn’t invited to the project meetings–he stared wide-eyed and exclaimed, “How long did you plan to keep this a secret!?”

Since then, the company has changed ownership, and the product I worked on has been discontinued. (Although you can still find it on the used-centrifuge market.) I don’t know whether any of the new centrifuges use the same software, or whether it was all too complicated for the programmers who followed me to figure out.

And I also tend to think the marketing guy was probably overreacting, because the centrifuge market doesn’t seem to care so much. Faced with the same situation again, there are some probing questions I would ask first about the true requirements of the project, before I went off half-cocked and designed a whole new, exciting control system.

This blog post is a selection from a new book I’m writing, tentatively titled I Never Thought I Was an Idiot! Confessions of a Veteran Software Developer, exploring the many missteps programmers make. It’s written in a humorous, self-deprecating style–and serious at times, as the story demands–and my hope is that you’ll see yourself in some of the anecdotes. If you think you’d be interested in this book, please…

• Click here and take 10 seconds to register your interest.
• Subscribe to this blog in order to read more snippets and stay up to date on the progress of the book.
• Leave a comment below.

Check out the other posts in this series.