For the lack of a plan

I spent close to five hours working on an assignment that I thought would take me an hour at the most.

It was an ad hoc project, and as often the case with many ad hoc projects you can’t really tell how long they’d take till they were done. My initial estimations were based off of casual look-throughs the source data I was working on, and a rough understanding of what the requirements were.

Expecting it to be not too complicated, I jumped into the assignment without thinking too much about it.

I’ll think about it as I go along, I thought.

And going deeper into the assignment, I quickly grasped what had to be done. A plan of attack was developed on the fly, and on I went.

Almost five hours later, on I was still going.

What went wrong?

I think the biggest mistake I made was rushing into things. I wanted to get the project out as soon as possible, and had set unrealistic internal and external completion time estimates. This led to a complacency at the start; an escalation of worry in the middle; and a near-panic toward the end.

With a little more forethought, I might have saved myself chunks of time. Had I known the multiple files I needed to process were so similar, I’d have done it in batches instead of piecemeal. Had I known the requirements more intimately, I wouldn’t have removed data I eventually needed. And had I known how unstructured the data would be, I’d have quoted an extended timeline that would have given me more breathing space.

In an attempt go faster, I skipped what might perhaps have been the most important thing: planning.

Student loans and how the deed is infinitely stronger than the word

Interesting article giving the perspectives of three people with outstanding student loans and how they’re paying it off.

I’d never been that heavily in debt and I do sometimes wonder what I’d do. Though I cannot say for sure, I do not see myself holding off the payment of loans if I could I help it. But I probably won’t need to theorise much more as in a few years time my mortgage will kick in and it’d be interesting to see if I’d practice what I preach about paying loans off as soon as I can. I cannot say for sure if that’s what I’d do.

That’s the thing about people: they may foresee themselves doing one thing, and saying they’d do it, only to do something else altogether when they really do it. They’d say I’d buy Brand X, definitely and then just as quick go on to buy Brand Y for no other reason than that because they felt like it. That’s definitely something to think about when collecting user responses in surveys and the like when major decisions are going to be made based off of it.

User requests are like hunger pangs

“So, when is the [request] going to be ready?” he asks me, the fourth person to ask in a one-week period.

This, I think to myself, is probably real hunger.

“I’m working on it,” I reply, which means I’m waiting it out to determine how important the request really is. The moment I can confidently say it’s a valid “need”, a real hunger, I move it into my high-priority queue and start work on it.

It’s not that I don’t wish to help, but system/application/report requests have a tedency to come in hugely inflated, seemingly much more important than they really are. More a reaction to an itch than a true life-saving need it’s thought to be.

I like to think of requests that come into my queue as a type of hunger. There is real hunger: the haven’t-eaten-for-days-and-starving hunger; and then there’s perceived hunger: the after-dinner craving for Pringles hunger.

When a request is of the “real” hunger variety, no matter how long you try to wait it out it’ll always be there (and the people who are requesting it won’t let you forget it’s there!)

“Perceived” hunger requests, on the other hand, tend to go away like after-dinner cravings when you give it a little time.

One problem with giving in to these “perceived” hunger requests is that, like the afore-mentioned Pringles, once you “pop you can’t stop” – these sorts of requests tend to come one after another. And it’s difficult to know when to say no because each request isn’t really that different from those that came before it.

A precedent, once set, can bind you to a cycle of petty requests (“why did her request go through and not mine?”) for the life of the project.

So my advice is: wait and see. If it’s really important you’ll be sure to know.

Which reminds me, it’s time for supper.

Choose your customers

Seth Godin recently had a great post on choosing your customers. He’s not the first to say this, and he’ll certainly no be the last, but it’s always good to hear reminders like this.

Choosing your customers first (before doing anything to get customers) isn’t intuitive. Heck, choosing your customers isn’t intuitive (who cares who buys my product as long as they buy my product, right?) but it’s definitely one thing to look out for.

When you have a project that you personally like and believe in, and one that you want to succeed, the last thing you’ll want to do is to go out to find champions for your project without thinking about who those champions are or what they stand for.

Before you know it, you’ll have people whom you thought were on your project’s side, but who actually have their own agendas. And you may end up fighting a creature you brought to life, twisted in ways you’d never imagined.