This morning, at my daughter’s sleep study, as we were waking up, I had a profoundly encouraging and empowering daydream. It wasn’t an intentional visualization, something I wanted to see come about, but purely a spontaneous daydream, of the sort that encroaches upon your consciousness in those fuzzy moments just after you awake.
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?”
“Presumably, you develop your own Drupal modules.”
“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.”
“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!