Jøhnny Fävòrítê (johnnyfavorite) wrote,
Jøhnny Fävòrítê

my blue etching

My contract job with the Canadians is over. Thank god.

The boss was an incompetent egotistical asshole who respected no one’s opinions but his own. It is pretty amusing to me that one of the complaints he took to my bosses at the contracting company was that I was “not enthusiastic about the project.” Perhaps because voicing opinions different from his own often resulted in yelling and screaming? That has a way of diminishing one’s enthusiasm, all right.

I tried to quit multiple times. My boss at the contracting company urged me to keep trying, so I did. I kept my head down and did a competent but not outstanding job, keeping my mouth shut as much as possible. Then one day the Canadian boss just up and terminated the contract, and that was that. Oh heavenly day.

I got along just fine with his second-in-command, though. If I could have dealt solely with that guy, I’d probably still be working on that project today. I sent that dude an email after the fact, to see if there was anything I could do to ease the transition, and I answered a couple of questions he had. I learned that he didn’t know about the end of my contract any earlier than I did, and that this is a typical end to programmers that this company has hired.

Conveniently enough, a recruiter contacted me with a job here in Nashville, a few days before I got the boot. A big famous IT services firm with thousands of employees worldwide. I would of course have to work in an office again. The really appealing part was that it pays 55 bucks an hour. With a lot of mandatory overtime, I’d be making around 130k per year. That would be way more money than I’ve ever made before.

I went to the interview the day after I got the boot from the Canadians. The two guys I interviewed with were more clueful than I was expecting, possibly because the group I’d be working for is so small: six employees. I certainly wasn’t looking forward to returning to long hours in a cube farm, though. I decided to put them off as long as possible, to see if the contracting company could come up with something new for me.

After only a couple rounds of back and forth during the week before Christmas, I do indeed have another contracting job. I will be creating the iOS version of an SDK that delivers video ads, for a company in the Bay Area. This could actually be a good fit for me. Due to my exceedingly anal programming style, I am exactly the sort of programmer who should be writing SDKs for other programmers to use. And the guy I’m working with has seemed pretty humble so far, in stark contrast to the Canadian jerk I was working for last time.

Shortly before I secured a new contract, I heard through the recruiter that the big IT services firm had rejected me before I had a chance to reject them. I am a little surprised, because I thought the interview went really well. I guess they thought I wasn’t “enterprise-y” enough? Not enough experience in big companies, I guess? Calling that a bad thing demonstrates the vast gulf between their expectations and mine, I guess.

I think I have mentioned this before: when the situation with the Canadians turned sour, I contacted the guy in San Francisco I had turned down earlier. I thought he was ignoring me, but he finally wrote back, weeks later. By that time, my boss at the contracting company had convinced me to soldier on. By the time I lost the contract for good, I didn’t have the heart to contact him yet a third time. I guess I have to consider that opportunity to be a victim of bad timing, and move on.

I have to give the contracting company credit for getting me into a new job so quickly. And I think I get part of the credit, because I only had to “audition” once, and I nailed it. When I got the Canadian job, it was the third potential employer I was pitching to, I think. I did a lot better this time around.

Still, though, doing this as a career feels awfully tenuous. Constantly going to bat, proving myself over and over again. Little or no security. I guess this is my life from now on, if I continue this route.

On the other hand, the likelihood of me getting bored or burned out is near zero. That’s almost always how my earlier jobs ended: I just couldn’t stand that particular company’s flavor of dysfunction anymore, and I had to bolt. I guess that pattern sort of describes what I’m doing now, but the roles are more formalized.


And now, a bonus technical section. I left this until the end, because none of my readers will even vaguely appreciate this, except for Alex. (Heh.)

The Canadians have hired a guy with no iOS experience whatsoever to pick up where I left off. My access to their subversion repository has not been cut off, I guess because of my helping the second-in-command guy with the transition. This is the first time I’ve ever been allowed to watch somebody take over a project I started, and boy is it ever disconcerting.

I can certainly understand being ignorant of any particular corner of the tech world. There are many, many programming specialties, iOS being only one of dozens. It’s still a pretty new thing. What I cannot understand, from this particular programmer or anybody else, is willful, aggressive ignorance. Looking at the code he’s writing, it’s pretty clear to me that not only doesn’t he know anything about iOS or Objective-C, but that he’s also not willing to learn. He’s making mistakes that five minutes with an introductory text would have cleared up for him.

Here’s a choice nugget I found:

    NSLog(@"The size of history is %lu", sizeof(history));
    NSLog(@"The contents of history is %@", [history objectAtIndex:0]);

    if ((sizeof(history) == 4) && (XYArrayHasObjects(history)))
        NSLog(@"I AM DONE");
        [AppController switchToTabBar];
    else NSLog(@"I PITY YOU FOOL");

So, let’s see if we can figure out what in the hell he thought he was doing.

Apparently, he’s trying to determine if ‘history’ contains any objects. So the obvious thing to do is check its size, right? Hence the first NSLog() call, to see how big it is. Except he’s checking the size of the pointer to the array, rather than the array itself. And the sizeof operator is evaluated at compile time, rather than runtime. And that whole rigmarole is completely unnecessary, because he apparently also found XYArrayHasObjects(), a small inline function I wrote, which does exactly what he wants: returns TRUE when an NSArray is valid and contains one or more objects.

But never mind all that! He has determined that, when he gets the result he wants, the size of ‘history’ is 4! So put that test in there! Which is always true, so long as you are compiling for a 32-bit architecture. The first and only time that test will fail is when this code is compiled for a 64-bit machine, where the size of pointers is 8 bytes. IT IS TO LAWF.

Okay, never mind how mind-bogglingly stupid that is. Everybody makes dumb mistakes in the beginning. What I find really incredible is that there is no way he actually tested this. He should have run through this method at least twice, once when ‘history’ contains objects, and again when it doesn’t. Had he run that test, he would have seen that sizeof(history) was 4 either way, and therefore that this test is meaningless. But no, he never did that, and left this bogus test in there, for all eternity. A time-bomb, waiting to blow up, as soon as iOS devices get 64-bit CPUs.

See, this is the kind of programmer my former Canadian boss would rather work with: young, inexperienced, unable to debug, willfully ignorant, no opinions of his own, and (presumably) easily bossed around. Puh-leeze.

AAUUGH, I know I should stop looking at his commits, but I can’t help myself. What a train wreck. I wish they’d just cut me off from their subversion repo and save me from myself.
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

Looks like student coding. Someone who didn't read any of the language (or other) documentation. At least they did try printing out values to see what they were doing, though you'd think they'd clue in that it is unusual for the array always to have 4 elements. I wonder if the boss will ever notice that their software is mal-functional, but then there are many commercial programs which have a pretty interface but garbage inside (first time something unusual happens, untested of course, lack of error handling will crash them). Customers even buy them.

Still, that looks like application code, so it won't break too much if it doesn't work perfectly. Just hope that guy doesn't try writing library code until he's gotten better.

Hope that next contract works out. Meanwhile over here in the game business it's Christmas layoffs due to lack of work from nervous clients (Black Friday sales don't meet expectations, their stock prices slump, they freeze all contracts). I'm treating it as a nice unpaid vacation break; they usually decide in January or February that they need something to sell for next Christmas, and then it's rush rush get the next game done before September. So I have time to try out Debian + KDE (Fedora-16 + Gnome was unworkable on my old PC - install DVD doesn't even boot any more), and maybe restart some Haiku work if time permits (got some more VNCServer tweaks to do for better iPad compatibility).
your assessment of the exact nature of the broken-ness of his code was a little different than mine. but that's the beauty of extremely stupid code, isn't it? because, dang, how the hell can you guess what was going through his mind.

every time i look in on haiku, it seems that they are getting a little closer. you have to give them props for persistence. can't imagine what i'd do with it myself, though.
Curiosity prompted me to look at how I would have done it. A single Google query for NSArray gave me my answer. This took me less than 30 seconds. http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSArray_Class/NSArray.html#//apple_ref/occ/instm/NSArray/count

And I don't know anything about iOS or Objective-C...
yep, that is exactly the method he should have used. that he couldn't find this out for himself is troubling.

bonus chatter: there's a reason i wrote an inline function to perform more or less the same thing. given the dynamic nature of objective-c, it's not too uncommon that, even though you've got a pointer to something that ought to be an NSArray, it is actually some other type of object. in that case, calling the 'count' method on such an object could cause a crash, or at the very least, it indicates that things in your program have gone horribly wrong. or maybe your pointer is nil, i.e., it doesn't point to anything at all. so rather than write this fairly complicated sequence of tests every time, i packaged it all up into an inline function. that's all an "extra for experts" type thing, though. for his purposes, just calling 'count' would have been close enough.