Safe from the Losing Fight

…ahem…

I am pleased to announce that as of today, December 25th, 2006, Elaine and I are officially engaged. As you can see, I was not kidding last time when I said engagement was immiment. From now on, people will take me seriously when I start threatening to marry someone.

For the people who didn’t think I was going to propose (or wasn’t proposing fast enough for them), may I say “nyah.” The current plan had been in place since mid-October, so I’ve known that it was going to happen. So there.

As far as the plan goes, it went OK, although it was almost derailed several times. We’re staying with my family, and we typically celebrate Christmas with the immediate family in the morning, then go to my grandma’s house to celebrate it with the extended family in the afternoon. Knowing that I’d never hear the end of it if I showed up to my grandma’s without being engaged, I decided that I should propose after the immediate family Christmas, but before we went to grandma’s.

The problem is Elaine is all nice and helpful. She offered to peel potatoes, and for a moment I thought I’d never get her away so I could propose. Fortunately, she’s a fast peeler, and I managed to get her to take a walk with me.

My parents live in rural Tennessee on twelve acres of mostly wooded land. The plan was to walk one of the trails, and when we got far away enough from the house, propose.

The only problem was it started raining soon after we started walking. We also had two voyeurs with us, who had a wonderful fragrance best described as “wet dog.” One was also a crotch sniffer. Very romantic.

By the time we got to the spot I had picked out, it was raining harder and the ground was muddy, making it difficult to kneel, which Elaine was kind enough to point out. Yeah, it was so awkward that at this point, she had it all figured out.

I went to a knee the best I could, mumbled something meaningful about love and whatnot that I had thought up before, and thrust a ring in her face.

She said “Yes.”

The end.

P.S. We had to run back to the house after that because it started raining really hard.

I’m finishing up packing. Like last year, I’ve decided to drive the twelve hours from Dallas to Chattanooga, as opposed to flying. It’s actually a pretty easy drive (I-20 most of the way), but it is a bit long, so I’ll be getting up early tomorrow.

Christmas is probably a time of reflection for just about everyone, but it is especially for me for a couple of reasons. First, I have a long drive, by myself, which seems to instigate reflection. Second, I’ve lived away from my family for several years now, and Christmas is the only regular time of the year I get to see them.

This Christmas is one of firsts, both good and bad.

It is the first Christmas that we, as a family, won’t all be together. My older brother is in the Army, currently stationed in Iraq. The Army did give him some time off recently, but for national security reasons they couldn’t divulge when until he was pretty much here. i.e. He called on Friday to let us know he would be home on Monday. Because of the insanely short notice, I couldn’t get time off to go visit him, seeing I had already scheduled time off for Christmas. We talked over the phone a couple of times while he was here, but it just wasn’t the same. We’re both strong introverts so we didn’t talk a lot, and didn’t talk about anything of importance. And even if we had, it’s just not the same as having him there on Christmas.

That’s not say that this Christmas is all bad.

It is the first Christmas that Elaine, my girlfriend, is spending with me and my family. With engagement imminent, I’m hoping this is a start of spending all of our Christmases together. Yes, I know that previous statement was extremely sappy, and I make no apologies about it.

Each year I look back and notice how my life has changed. Sometimes it is a little, sometimes a lot. It just seems to me this is one of those watershed years.

Scott Stevenson has created a new site, Cocoa Blogs, which is about… blogs… about Cocoa. It’s also about how brief and precious life is, and reminds us all how our time would be better spent posting more stuff about Cocoa. At least that’s what I got from the clock in the upper right-hand corner.

Anyway, I’m not writing about Cocoa Blogs because Scott needs my traffic or because he even listed yours truly, although the latter certainly helped. No, it’s because Scott stole my idea.

And by “my idea,” I mean it was an entirely different idea, which I stole from someone else, and also that the idea was very obvious, but, legally speaking, not to someone of reasonable skill in my profession, so I should have probably patented it. It did include the words “blog” and “Cocoa,” which is probably all that matters to a patent attorney and a jury of my 87 year old peers from Massachusetts.

The idea was spawned about a month ago, when I sustained head trauma and temporarily forgot how painful basic web application development is. I decided what the world really needed, more than peace, universal healthcare, or even Jelly Bellies, was a site cross between Digg and Technorati. For Mac development blogs.

I’ll pause while you catch your breath.

The basic theory is that, at the heart, it would be directory for Mac development blogs. Users could submit their or other people’s blogs for inclusion in the directory. Once a blog was in the system, it would take advantage of the fact that just about every blog has an RSS feed. It would pull stories and put them in an incoming queue (think Digg). Users could then vote on stories, and the most popular would go to the front page. There would also be all the required social site features, like friends, comments, spam, and an overabundance of twelve year old boys with no sense of perspective.

I abandoned the idea after I started up a Ruby on Rails project, spent several days getting basic user support working, and realized I had just spent several days getting basic user support working. Um… isn’t basic user support something that’s supposed to be implemented by the operating system? Or, the application framework at least? After realizing that I had a good bit of work to do before I got to anything remotely interesting, something shiny caught my eye, and I wandered away after it.

Buttons followed after me, but was injured in several humorous altercations.

Currently most of the business we do at Order N Development is contracting. All of our clients handle us, as contractors, differently. Some seem to be better at managing contractors than others. As a way to improve relations, or potential relations, I’ve put together a list of things to watch out for when managing contractors.

Pickup lines

The first thing potential clients do is approach us and try to determine if we can help them (that’s deep, I know). Unfortunately, the confusion seems to come in when they determine what information we, as an engineering company, need to know.

First, remember we are not your customers or your VC. We do not care, or need to know, that your ultimate goal is to revolutionize the way people make tuna fish sandwiches. We do not need a PowerPoint presentation so laden with buzzwords that it is no longer comprehensible by mere mortals. Please save that information for the venture capitalists, who swoon over that sort of thing, and as a result, vomit up large quantities of money.

It seems like 98% of the potential clients we hear from insist on using the word “revolutionary” somewhere in their introductory email. Don’t get me wrong, it’s good to know that you’re enthusiastic about your product ideas. But we, as potential contractors, aren’t motivated by how revolutionary you think your idea is. We simply want to know what you need done. To this end, it would be better if someone from your development staff contacted us, rather than someone from your marketing staff.

Ultimately, we will want a functional specification to work off of. If you do not have one, we can help you create one, but we still need to know, in clear terms, what you want done. And that means never using the word “revolutionary.”

The first date

After a potential client has selected us and all the appropriate paperwork has been done, I’m ready to start. Unfortunately, I’m not always able to, because IT hasn’t setup VPN, email, access to file servers, code repositories, or whatever. I’m not sure if it’s because the group I’m working for didn’t tell IT everything they needed to know, or if IT simply doesn’t have a good process for bringing contractors on board. What I do know is that some sort of IT snafu happens just about every time.

On one contract, the original IT person did not create my account correctly (as evidenced by every subsequent IT person noting, “What the hell was this guy thinking?”). As a result, it was difficult to gain access to the servers I needed access to. Also, my VPN account was incredibly flaky, and every few weeks I had to spend some quality time with the client’s IT department getting it sorted out. This persisted the entire contract, which was more than six months long. This had an obvious impact on my effectiveness as a contractor.

Although not my first choice, I don’t mind staying on the line with the IT department, charging you my normal hourly rate, while they sort things out. However, if things are already setup by the time I start, then you don’t have to waste any money waiting for IT, and I’m not forcibly subjected to Barry Manilow’s Greatest Hits. Its a win-win.

Getting what you want

Once I start the contract, you should know what you want, and should communicate that to me. More specifically, if I’m to do feature work, there should be a specification, and I should have access to it. If I’m doing bug fixing working, there should be a bug base, and I should have access to it.

This part seems really obvious, but apparently it’s not. I should not have to contact you via phone or IM every other day, asking for a new task to work on. You should not be handing me a single task each time, and telling me to call you when I’m done with the single task. There should be a list of tasks that I can work from, which can be in the form of a spec. Otherwise, a lot of time is wasted waiting for the next assignment. (Yes, people really do this.)

I know I’ve railed about this before, but if I’m working on bugs, they should be reproducible bugs. If your QA team is not producing quality bugs, that sends a clear message to me: “This company is not serious about fixing bugs, so you, as a contractor, shouldn’t be either.” I should not have to fight with your QA to get steps to reproduce a bug. i.e. This should not happen:

Subject: Plugin crashes
Priority: Highest

Description:
The following plugins crash when I used them:
…(list of plugins)…

Comments:
Andy: What are the steps? Where in the plugins are we crashing?
QA: Various places.

That’s a paraphrased bug report from an actual QA. It crashes in “various places.” If your QA can’t be bothered to write down steps they already know, why should I be bothered to try to fix it?

Trust issues

Although not necessarily specific to managing contractors, some clients simply don’t know how to manage people.

I don’t care if you used to be an engineer, or even if you played one on TV, you shouldn’t be micromanaging me. If you’re going over every little thing I do, one of us is redundant. If it is a trust issue, then you should call me and we can work things out. Otherwise, you’re wasting both of our time, and your money.

To the other extreme, someone from your company should be available when I need them. Whether it be to ask technical questions or questions about invoices getting paid, someone should be there. It is very difficult to make progress if I need a technical question answered, and my contact promptly signs off anytime I ask them anything.

I should also note that one extreme, such as micromanaging, does not preclude the other, such as hiding. Some micromanage a single small bug fix, then disappear off of the face of the planet when I need to know where a particular resource is stored.

If you have a micromanaging manager, then that’s something you need to handle internally, as a general issue. However, when you assign a technical contact for me, make sure they are the responsive type.

Wrapping up

Hopefully if you hire a contractor, things will go well for you. Hiring a contractor is difficult because they are often an unknown. However, if you keep the above things in mind, it should increase the chances of having a good relationship with the contractor, and getting what you want. If the contract does fail, it should help assure you that the problem probably wasn’t on your side.