Safe from the Losing Fight

In preparation for C4[3], Wolf has put up videos of the talks from C4[2], including the one I did on contracting. Hopefully someone will find it useful.

I typically don’t write about my cartoon obsession here, but I recently ran across one that seemed appropriate.

This is Zits from 7/14/2007, in which Jeremy, the main character, learns a harsh reality about life.

I bring this up on my blog because I became more acutely aware of how much “that FICA dude” was getting when I became self employed. When you start writing the checks yourself, as opposed to your employer taking the money out before you even see it, there is an even more stark realization.

When contracting, I get to see lots of code. Some of it is good, some of it bad, and some just leaves me scratching my head.

For example, I came across this today:

//ASSERT(1);

Apparently things had gotten so bad for this programmer that he needed to make sure 1 still evaluated to true. I’ve had days like that. Better yet, when done, he just commented the line out, helpfully allowing future developers to quickly make use of his wisdom.

Such a philanthropist.

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.

For those of you who actually read this blog for the articles (as opposed to the pictures), you’ve probably often wondered: what is it, exactly, that you do? Other than make a fool of yourself? In order to answer that question, and have something to do, I present what my daily schedule is like.

8am – Wake up, scratch self, turn over, fall back to sleep. No respectable software engineer gets up this early.

8:15am – MacBook Pro’s dancing in my head. Unless you’re my girlfriend, in which case, I only dream about you baby.

9am – Wake up and realize I do not own a MacBook Pro. My dreams crushed, I see no reason to remain conscious, so I scratch myself, turn over, and fall back to sleep.

9:30am – Apartment maintenance personnel decide that I have slept long enough and begin pile-driving two feet outside my bedroom window, where in the alley they have apparently decided to construct a large shopping center.

9:31am – Contemplate the needed trajectory of a rock that would injure, but not kill, said maintenance person. I might need my ice maker fixed at some point.

9:35am – Give up on plan to maim maintenance personnel because it would involve moving a part of my body, and, let’s me honest, who doesn’t want an large 24-hour supermarket directly outside their window?

10am – Unsure if I am yet awake, maintenance personnel begin mowing what’s left of the grass outside my bedroom with a bush-hog machine.

10:01am – Stagger the 10 feet from my bedroom to my “office.” Manage to stub my toe on no fewer than seven objects. As required by law, at least three are more dense than depleted Uranium.

10:02am – My now semi-awake brain discovers that the computer/printer combo doesn’t not provide this “food” that the Wizard needs, badly.

10:03am – Stagger over to the refrigerator. My agile feet know the path well, and manage to run into the same seven objects.

10:05am – Think about how good a breakfast with scrambled eggs, bacon, and blueberry pancakes would taste. Unfortunately, I am a bachelor so anything that cannot be made from hot-dogs and month old bread is out of the question.

10:06am – With hot-dog flavored “PopTart” in hand, return to the computer.

10:07am – Digg and Slashdot.

11:03am – Decide to actually “work.”

11:04am – Start pulling down code to work on with Perforce, the Fast Software Configuration Management System. The file set consists of three small text files, one resource file, and a large image file describing how the software system works, assuming they had actually built it that way.

12pm – Lunch, which is a hot dog, stale bread, or some combination thereof.

1pm – Perforce, the Fast Software Configuration Management System, actually completes the synchronize operation, leaving me with three small text files, twenty corrupted resource files, and someone’s half eaten pimento cheese sandwich.

1:01pm – Consult Digg and Slashdot, while contemplating why anyone uses Perforce.

2:00pm – Remember that people use Perforce because the alternatives are worse. For example, Visual SourceSafe is a service by Microsoft in which they send a salesman to your place of business to kick you in the seat of your pants repeatedly. In the Professional version of SourceSafe, the salesman also steals your credit card and purchases a site license for Microsoft Money.

2:01pm – Attempt to log into the client’s bug database, so I know what to work on. Discover that I do not have access to bugbase, which is on the internal network, because I did not file a business case for why I need it, three years in advance.

2:05pm – Call the client’s IT department, explain that I need network access from my Mac. To avoid getting the wrong software, keep mentioning that I am using a Mac during any awkward silences and anyplace in the conversation a normal person might say something like “hello.” Sensing my urgency, IT promptly sends me five copies of the Windows software.

2:10pm – Call IT department back to explain that need Mac software, to which I am promptly told “We do not support Windows 98.”

2:15pm – Finally reach the one Mac IT person, whom they apparently keep locked in a cage in the basement, and feed old PowerTalk documentation. He cannot send the software via email because of the 32 byte email attachment limit, but he is able to smuggle out a CD of the software, on the back of one of the many fruit bats in his cage.

2:30pm – Discover that VPN software does not reliably connect to client’s network, but does, in fact, waste a large amount of space on my hard drive and not uninstall.

2:31pm – Call IT department again to explain VPN software does not work. IT carefully explains that I must either rewire my apartment, reconfigure my router so that it is solely and permanently connected to their network, or move to California and/or India for VPN to ever work. They are not sure which. Smoke signals are suggested in the interim.

2:45pm – Randomly change settings in the VPN configuration until I can actually connect to the internal network. Discover that although I can connect, I have no security access to any servers on their network, including the bug database. Furthermore, IT has decided that, for reasons of productivity, anyone connected through VPN should not be able to access anything outside their network, such as, for example, the computer sitting right in front of me.

2:56pm – Call IT department to be granted access to the bug database. The IT person that I reach calmly explains that, yes, he can grant me those privileges, but won’t, because he strongly suspects that will allow me to do actual work.

3:03pm – Have my contact within the client company call IT and explain that its OK for me to do work because I do not work in IT.

3:30pm – Feel smug about getting to bill client for all the time IT wasted.

3:31pm – To celebrate victory over IT, Digg and Slashdot.

3:52pm – Examine the first bug I am supposed to fix, which is marked as “severe” and a “crasher.” It states: “When I press Command-Q, the application quits.” I spend the next hour on the phone explain why that is expected behavior. The phone call ends with the quote “Well, that’s stupid and Apple should change it.”

4:52pm – Digg and Slashdot.

5:23pm – Examine the next bug I am supposed to fix. Although it is simply a misspelled word that has been in the software for seven years, it has now become “urgent,” “must fix,” and, “severe.” Oddly enough, the bug was entered by a technical writer.

5:33pm – Open up Xcode, Apple’s integrated development environment, specially designed for the Mac user who has lost the will to live.

5:38pm – Change the resource string to fix the misspelling, which the previous engineer was unable to do, because, apparently, he could not locate the second button on his Macintosh mouse.

5:50pm – UI designer notices that I fixed the misspelling, and suggests other improvements to the wording, such as rewriting the host operating system from scratch to use more color gradients.

6:04pm – While muttering under my breath about out of control UI designers, Digg and Slashdot.

6:45pm – Examine the next bug, which is from a customer, requesting that we add support for XML file formats and the ability to shave an enraged badger. After serious consideration, I decide to defer the bug for next time.

7:02pm – Receive call from marketing demanding to know why XML files/badger-shaving feature was deferred. They cite numerous customer anecdotes in which they needed the portability of an XML file combined with the ability to shave an angry badger. Most cases involve alcohol, in which the badger had consumed prodigious amounts.

7:30pm – Look at code for the first time today.

7:47pm – Marketing calls back saying what the customer probably, really, honestly, truly needed was a way sober up the badger. They swear the badger is a nice guy, but only acts that way when he’s drunk. Plus he has a bad 5 o’clock shadow.

8pm – Receive call from potential client, asking if we could port his Word processor for Windows to the Mac for twenty nine cents and a large portion on his company’s stock, currently held in a gum-ball machine.

8:28pm – Starving, I crawl to the refrigerator, where I discover a veritable treasure trove of food, in the form of Cheerios, underneath the fridge.

9:02pm – Realizing I am spending too much time reading Digg and Slashdot, I go read Dilbert, Get Fuzzy, and Pearls before Swine.

9:18pm – Return to code and marvel at the fact the compiler has not openly mocked the code in iambic pentameter or simply refused to compile it out of principle.

10:07pm – Digg and Slashdot.

10:41pm – iChat with business parter in which we ridicule Xcode’s speed, code quality, and inability to shave an enraged badger who’s had a few too many drinks.

11:11pm – Notice that the auto-complete in Xcode is actually recommending other, more reputable companies I could be working for.

11:38pm – Digg.

12:06pm – Slashdot.

12:49am – Change egregious code “if ( foo ) doFoo();” to the much more sane “if ( foo ) { doFoo(); }”, on the initial thought that I get paid by the character.

1:22am – Discover the entire Xcode help file is one page that recommends using a better IDE, such as MPW.

1:30am – Change the completely erroneous “if ( foo ) { doFoo(); }” to the actually readable “if (foo) {doFoo();}”. Note the bytes saved by the removed whitespace on my accomplishments.

1:40am – In an attempt to find a snippet of code in my project, Xcode inadvertently finds life on Mars. Still unable to search an arbitrary directory in less than ten steps.

1:44am – Change “if (foo) {doFoo();}” to “if ( foo ) doFoo();”, and wonder what fool added the unnecessary braces and removed the spaces.

1:54am – Against doctor’s orders, read old copies of Inside Macintosh, Volume 1 until I fall asleep. He recommended a large mallet to the head, for the reason that it is less likely to cause severe brain trauma.

As you can see, the life of an independent software engineer is not for the faint of heart. No doubt you have more respect for me now than you have ever had before.