RoboZen

Last year, I wrote about one secret of successful project managers: strategic lying. If your programmer tells you a task will be done in three days, it will be done in a week, and you should tell your client it will be done in two weeks, to be safe. Conversely, if your customer tells you they need something in a week, tell your programmer it is due tomorrow.

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.

Dear Yelp.com,

After two years of silence, I appreciate your sudden and continued, nay daily, efforts to bring me up to date on the culinary scene in Brooklyn, New York, where I no longer reside. Happy to hear from you but, unfortunately, miles away from any city served by your delightful application, I scrolled to the unsubscribe link at the bottom… only to be promptly transported to a login page.

“Hello there!” your website seem to say. “You, beloved user, have arrived to change your subscription preference. Welcome! Surely you and I cannot have become so estranged that you do not even remember your password? No no, you’re here daily, I can feel it! There’s absolutely no need for you to click ‘Forgot Password’, request a password reset, check your email, come back to our website, enter a new password twice, be redirected to some other page, go back to your email, find the unsubscribe link, click it, uncheck all the cities you are subscribed for, and click submit, just so you can stop getting crap from us. No siree! We’ve thought this through, and we wouldn’t make life so hard for you.”

“We’re as sure of your commitment to us as the reputable fellows with the moniker United.com. When you selected to opt out of electronically delivered offers, they had no doubt that you had your frequent flier number, used once and only once, memorized—because you fly frequently! Get it? And there was no question that you would feel more secure entering a four-digit PIN number than one of those silly-sounding passwords like myGErbl123. Because after all, they want you to feel as important as if you were at an Automatic Teller Machine, and not just at any old website trying to please for the love of god get them stop sending you crap.”

Seriously, if you are from one of a bajillion companies who do this unbelievably irritating and stupid thing, please stop. People just want to break up with you nicely, not be dragged through divorce court. Give them an unsubscribe link that works with one click. Jerks.

Best regards,
Flooded with Mail

I’ve seen many a source code that is neat and XHTML-compliant everywhere except—for some mysterious reason—forms. There is some unspoken rule that tables are the only way to align form fields into two even columns. That rule is wrong. Without further ado, here is how to rid your pages of the final vestiges of layout tables (tested in Firefox 3 and IE6, the best and worst of all possible worlds):

HTML:
<div class=”field_container”><label>First Name</label><input type=”text”></div>
<div class=”field_container”><label>Last Name</label><input type=”text”></div>

CSS:
label {
width:150px;    /*Or however much space you need for the form’s labels*/
    float:left;
}

I’m serious, that’s it. So if I see another table, YOU’RE FIRED.

Apparently, not all developers participate in pro bono or opensource projects. You should, even if, like myself, you are an empty shell of a human being who gets no fuzzy feelings from helping others.

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.

Unsurprisingly, my feelings towards projects vary. The ones I hate involve labyrinths of legacy code, infrastructure nightmares, and new requirements to turn the Tower of Pisa into the Empire State. The ones I love give me a blank canvas on which I can paint an MVC masterpiece after lovingly drafting a throng of specs. Also, they pay shit.

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.

I’m a notoriously compulsive hobbyist. I seem to have new pastimes every week, and today they happen to be gardening and writing short stories.

I bought a handbook that lays out the basics of short story writing (plot, character, dialogue, yadda yadda) but some pages into it, I decided, “Fuck it. This feels like work. Writers are supposed to chug wine in brasseries and let the drunk angst write itself, right? Nabokov and Kundera and Maupassant never wrote outlines and character sketches, silly!”

So I throw the book in the corner and get to it. I write five pages of rambling prose, hit save, and call it a night. This morning, I re-read it. I find that it’s lacking…plot, character, and dialogue. So I think and think and finally sigh and write an outline. A character sketch. Some dialogue. Then I go back to my original piece, ready to carve it up and make it play nice with all my new notes. I start laboring through it sentence by sentence, and then I realize: “Dear God… I’m refactoring!” I quickly close the thing and get back to work, which is the same goddamned thing except I get paid for it.

Anyway, the point is this. We’re used to seeing movies where writers are easy-going, substance-abusing geniuses who just get smacked in the head by a muse who writes their novels for them. Likewise, movies tell us that “hackers” plop down in front of a scrolling jumble of green ASCII and “crack” NSA servers in five minutes. You don’t see ‘em motionless before a screen, thinking… that’s lame!

But the reality, for both writers and programmers, is that a project should be 80% planning and 20% implementation. (Arbitrary statistics, but it’s something like that.) You should have a database schema, wireframes for your UI, and lists of models, controllers and functions before you write a line of code. Because if you just go with the flow and create a bunch of crap, trust me, it will be broken beyond belief and you’ll be better off re-writing it from scratch.

P.S. Maybe next week, if my plants are still alive, I’ll write something deep comparing coding and gardening.

Some people have asked where I’ve disappeared to. Well, it’s been a long, dark winter over here in Sweden, and I’ve been [hibernating/trying not to commit suicide/coding/growing my company]. Mostly that last one. I’ve struck two long-term development deals with iAmplify and Digipoint, hired another programmer, and then pretty much went to sleep hoping that I’d wake up to April. And here I am, look forward to more updates!

This is not immediately obvious those who charge a flat rate per project, instead of by the hour. But unless you track your hours, you know neither how much you’re making on your current project, nor the fair price to charge for a comparable project in the future. Remember, $2000 might sound like a pretty pile of cash for a site, but unless you know how long it took you to build, you don’t know if you’re making any more money than a busboy.

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.

In your CSS, you specify that your #header, #footer and #sidebar elements should be baby blue. A week later, your picky designer asks that they be changed to lilac. Of course, you can change the color for all three elements, but, as the DRY gods will tell you, find/replace is error-prone.

You should only specify colors (and, preferably, most attributes) only once in your stylesheet.

The Wrong(ish) Way:

.header {
color:baby-blue;
font-size:humungo
} .footer {
color:baby-blue;
font-size:tiny;
}

The Right(er) Way:

.header, .footer {
color:baby-blue;
} .header {
font-size:humungo
} .footer {
font-size:tiny;
}

Check out the Swazz Calendar. Small file size, easy to integrate and actually works.

One caveat: by default, it sets the date the European way (dd/mm/yyyy). To change to the American format, find the following line in the prepcalendar function:

calvalarr[d]=”+(d-cd)+’/'+(cm-(-1))+’/'+cy;

and change it to:

calvalarr[d]=”+(cm-(-1))+’/'+(d-cd)+’/'+cy;

Then find these lines in function lcs:

ccm=curdtarr[1]-1;
ccy=curdtarr[2];
prepcalendar(curdtarr[0],curdtarr[1]-1,curdtarr[2]);

Change them to:

ccm=curdtarr[0]-1;
ccy=curdtarr[2];
prepcalendar(curdtarr[1],curdtarr[0]-1,curdtarr[2]);

Voilà. (That means “There you go” in English. ;))