All the Perl that's Practical to Extract and Report

Feast to feast? Or famine to famine?

VSarkiss on 2002-05-01T02:26:38

So just as I get fed up with one client's

  • crappy environment (newbie programmers who need everything spoon-fed to them, yet find time to question every design decision I've made)
  • crappy pay (10% rate cut mandated by "poor economic conditions")
  • crappy payables (transferred to a manager who decided she'd rather pay once a month rather than every other week like our contract states)
Another one pops up.

I got a call from a friend I'd worked with about ten years ago, who's a director at a major newspaper, asking if I could help with their next generation data warehouse. I jumped at the chance, but it'll be some hard work for a while. I'm not one to burn bridges. Plus I really can't just shoot a client and walk away; it's just not in me. I think I owe them better than that.

So what about all my grand plans for my own development? Sigh, back-burnered again. But I figure I "gotta get while the gettin's good".

I really wanted to get a Mac and see if OS X really is "the arrival of Unix on the desktop". Then there's the Quicktime editor my friend wanted. And the digital camera thingamajig. I need more tuits, that's all there is to it.

Contractual obligation

gizmo_mathboy on 2002-05-01T04:12:46

Let me get this straight.

1) Your client wants to change the contact

2) You don't want to drop this client and go to a potentially sweeter gig.

Hmmm...I say hold them to the contract or pose the counteroffer of a shorter contract so you can get to the datawarehousing project.

Of course I've been told that the more patient individual in a bargaining session can usually do better. I call it honing your Machiavelliain skills.

Then again what do I know. I'm still a wage slave trying to make partner in my company.

Re:Contractual obligation

TorgoX on 2002-05-01T21:06:55

newbie programmers who need everything spoon-fed to them, yet find time to question every design decision I've made

After much fretting, I decided some time ago on an approach to this. It is to assert: "I do not explain things; I do them. I am not paid to explain them, or justify them."

Feel entirely free to throw in their faces every piece of evidence that you've seen on their inexperience, and say "because you make that elementary of an error (or because you have that kind of a hole in their knowledge), you are not yet capable of understanding my design decisions quick enought and well enough that I'm going to bother explaining them. I am not your teacher. If you want to learn, get a library card and read these books [have a list ready] or go to school, and then get a clue and spend ten years programming like I am. And when you see code I write, ask 'what is brilliant about this?' rather than 'what can I proclaim is supposedly wrong with it?'. And in either case, keep it to yourself, because I'm not paid to care what you think. In fact, one could argue that I'm paid to not care what you think."

Exercise for the reader: figure out how to apply that to Opensourceland, where noone is paid for anything.