Here’s an addendum: pressure programmers with only one task at a time. For example, if you have a project with three critical tasks and a week to do them, do not assign all three tasks to a single programmer, and give him next week as a deadline. Instead, assign the first task with a one-day deadline, pressure him to get it delivered, and repeat with the other two.

If they are assigned three “critical” tasks at the same time, many programmers will stop being productive. Some are simply so overwhelmed and stressed that productivity drops. Some feel that if “everything is critical”, nothing really is. And if you prod them about task X, they can always say, “but I’m working on Y and Z!” and they’ll probably be right.

But put one item on their plate as “critical” and “due today!”, and they feel motivated to get it done. They’re pressured, yes, but they can actually think about what they’re doing instead of worrying about the two other hovering deadlines. And should they fail to finish that one task, without a good reason, you can reasonably chew them out for missing deadlines.

Of course, it is your job as a project manager to decide on a reasonable implementation timeframe for each task (That’s if you’re familiar with the code; if not, you have to talk to your progammers instead of guessing, and remember to pad the estimates!). It’s also your job to shield the programmers from management, which will otherwise undoubtedly swing by to check in on tasks U, V and W.

My last post explained that boring projects pay more. By this principle, which shall hereby be dubbed The Law of Life Sucking, the most exciting projects are those that pay nothing. You see, it is unlikely that you will be badgered to hurry up on a pro bono project. In the absence of tight deadlines, you can learn how to perfectly plan and execute a project. You can play with new technologies, utilities or libraries. You can scrap it and start from scratch. And then, you’ll know how to use those things for your paid projects, and you’ll earn more money, which will reassure you that you are, after all, a calculating, heartless soul.

You see, the amount of love you feel for a codebase tends to be inversely proportional to the compensation. The reason, when you think about it, is simple. Legacy code has  by definition been around for a while, and if someone is willing to invest into maintaining it, instead of re-writing it from scratch, the software likely a) is rich in features and b) has users. Those are signs that the company has cash.

A good strategy, if you’re a freelance coder, is to have one or two long-term contracts maintaining code for someone who can pay, and take on fun, creative startup projects once in a while. And cheer up! Eventually, the clients with the legacy code will cave in and give the go-ahead to rebuild it all from scratch.

It’s also your fault that I have to explain “why I charge three times more than the guy you found on Craigslist”. Be fair to you and me. Track your hours. Bill accordingly.

How much is fair? I’ll give that some more thought and write a post later.

I hit the reply button and typed, “No.” Then it hit me: she’s not a web developer. She does not sit around all day reading Sitepoint and A List Apart. If she did, she would not pay me. So instead of writing an annoyed “I thought I explained this,” I realized that if she was asking, I had not explained it well enough.

Then I did some research and put key fixed vs. elastic layout arguments into a memo. Hopefully she will be positive about my arguments. And if she still disagrees, the memo was nevertheless worth the ten minutes of effort, and will score many brownie points. First of all, she will understand that the site was developed a certain way for a good reason, and not due to incompetence. Second, she will be pleased by my extra effort to provide information, making her more eager to hire me next time. And third, she will hopefully be a client for a long time, and by giving her brief lessons here and there, I minimize confusion, and by minimizing confusion, I minimize the amount of work that I have to be redo in future projects.

And besides, don’t we all hate doctors and car mechanics that act like jerks because we don’t understand their work?

• Print designers like pretty fonts. “What do you mean I can choose Arial or Verdana? Why can’t I use Zabolofsky Sans Serif Bold?” Web fonts are a pretty foreign concept and they will pressure you to make text images using their pretty fonts. Resist.
• Print designers think a monitor is fixed-size, like a book. “So do I make this 800×600 or what?” This will give you trouble beyond launch. Because print materials do not change after printing, print designers think only of how the page will look when it launches. They often do not plan for expanding pages to accommodate more content.
• Print designers don’t get web usability. Print material usability is pretty simple. Pick up; read; turn page. The web has hundreds of implicit usability rules, such as: logo links to homepage, scroll bars are best left undecorated and at the rightmost side of the screen, fonts are best when big and ugly etc etc. Prepare to explain all these points to your designer client.
• Print designers use wacky print terminology that will confuse you, e.g. “Can you change the gutter and leading on this text?” Huh?
• Print designers don’t get programming. A print designer is an artist; a web developer is an engineer. For a good artist, the hardest part of the process is catching the creative spark that makes things look great; implementation is fairly easy. For an engineer it is quite the reverse. A print designer may not get, for instance, why it takes you two days to code an entire site and then three weeks to figure out why this goddamned rollover isn’t quite right, or even worse, why a form that looks ok still doesn’t work okay.
• Form over function. Designers have tended to be quite apathetic to one or more of the following: whether the user flow makes sense; whether users will read all of the copy; whether the products will sell; whether the site is even a good idea to begin with. Understandably, they do care about whether it is pretty. This makes a ton of sense in the print world, where people do judge and buy a book by its cover. But in the web world, where the most popular sites such as Ebay and Amazon are also the ugliest, it just doesn’t fly.

To date, I have spent at least 20 hours, spread out over four months, on the job.

I have been berated for things including, but not limited to: spelling mistakes in the copy provided by the client; uninteresting web design for the form (?!); the stock image selected for the splash screen, after the client failed to respond to requests for design guidance, being “not ‘Colorado’ enough” (???); the splash screen image not being big enough (because users HATE fast-loading pages). I am not even going to get into the number of database schema revisions that had to be made, or the fact that she didn’t get how to use the CMS I created to update registrant choices on the form.

My favorite exchange was regarding the proofreading. She sent me a list of events with a ton of misspellings. I nicely told her she could enter the events herself through the CMS I gave her. She didn’t get it. So I nicely entered the events for her.

Next day: “There are spelling mistakes!”

“That’s the copy you sent me. You can edit in in the form at http://blahblah.”

“Why do I HAVE TO EDIT IT?! I EXPECT SERVICE. YOU SHOULD NOT BE DOING THIS FOR A LIVING.”

Look, Ms. Retarded Client. Say you paint houses for a living (and if you don’t, you should). I pay you $x to “make my house look good”. You ask me what color to paint it and I say “white”. So you come over jolly as can be and paint my house white. Then I say, “Why is it such a bland white? There is nothing appealing at all about this white. Can it be a little darker?” Of course you would say to me, “Look Ms. Dumbfuck, I can’t repaint your house ivory, because I asked you in advance what color you wanted, and you said white. If you’re going to have your house painted you can educate yourself enough to know that ivory and white are different colors.”

“Ugh. Fine,” I would say. “Now please wash my windows.”

“But I am not a window washer!”

“WHAT?! I’m paying you $x, and you said you would make my house look good, and you can’t even wash my windows????”
Conclusion 1: If you can afford to choose your clients, choose clients who understand what you do.

Corollary 1: Pad for retardation. If your client is not savvy, they WILL make ridiculous demands. Plan ahead and quote twice the price. At least.

Conclusion 2: You are a programmer. Sometimes you are also a sysadmin.
You are not a:

• designer
• artist
• proofreader
• content manager

Make sure your client understands this.

Upon receiving a task to complete, these project managers first ensure that no direct communication occurs between the client and developers.  Then they ask developers for hourly time estimates. Upon receiving an optimistic appraisal they nod, and silently multiply it by (at least) two. Based on this augmented hourly estimate, they calculate a timeline in dates. Then they multiply by two again. This is the deadline the client gets. But the real trick: don’t tell the developers. They will think they are still sticking to their original time estimate. They will get stressed out, they will miss their deadline, but because they think the client will kick ass, they will stay up late to get it done shortly after their original deadline. And that, my friends, is how to deliver a product ahead of deadline to the client.

Corollary 1: Developers cannot also be project managers, unless they learn to lie to themselves.

Corollary 2: Clients cannot be project managers.

Corollary 3: Excellent project managers are not a waste of space and oxygen.

This is dedicated to my favorite projektfuhrers.

It is the Sisyphusian cycle of meetings to discuss why something has not been done, the answer to which is usually, “I was in too many meetings discussing why things haven’t been done.” Developers oughtn’t be subjected to this. Developers oughtn’t even be subjected to meetings to discuss what they will develop. A developer’s job is to develop stuff.

Here’s some Pamprin for PMS:

* Tech-savvy project managers. They can answer tech questions and pitch tech solutions. They can make action items to pass on to developers.

* An engineering watchdog. This person, probably the project manager, makes sure that requests to engineering are filtered through her. She prevents developers from getting sucked into meetings.

* Daily checkins from coders. Just a brief summary of what was accomplished that day. Since a developer is not in any meetings he has no excuse for an empty list.

* Weekly action item feeds to coders. Take what the project managers decided and translate it into action items. These items should reappear, completed, on the developers’ daily checkins the following week.

This is sure to be implemented in every company right after global warming, world hunger and Turing’s halting problem are solved.