What's it all about, Alfie?

There are a lot of times in my life when I'm really on the fence about something. I want to get the new 17" Unibody MacBook Pro with the quad cores and the 512GB SSD, but we're trying to sell our house and move to Naperville, and I think maybe I should hold off until we're moved, and see how things look then. On the fence.

I've been on the fence for the last several months about what to do about my position in The Shop. I've entertained the idea of leaving, and I've talked to the management about my concerns that might move me to make that decision. I've asked for relief - in the form of working at home for a while, and that was rejected as I was considered too vital to the team to allow the remote work option. Again, on the fence.

There's a lot to like about The Shop. There are plenty of people I enjoy in a lot of different spots. There's a new pseudo-CTO that has promised a "cut 10%" policy that promises to get rid of the deadwood that's a significant problem here. He's also understanding of the fact that there are serious problems in such fundamental things as the market data, and is working to address them. There's a lot to like, and a reason to think it's going to steadily get better.

But then there's the one really significant downside: I work directly for Ralph.

On a normal day, Ralph is a micromanaging, untrusting, manager that believes he's always the smartest one in the room. And while I agree with these words, they were first spoken to me by Ralph's managers. It's not a good situation, but when Ralph is busy in meetings, or quietly working on something else, it's easy to forget he's sitting six feet to my right. But when he chooses to assert his management over me, it can get very uncomfortable.

I was raised with a serious work ethic, and respect for those over you. Not that I would hold doors for Ralph if I saw him out on the street - but in the workplace, he's the manager, and the organization has made that decision, and deserves my obedience to that decision. If I don't like it, I am always free to pick up and leave. That's my choice.

So I'm again on the fence. If Ralph is quiet, it's not too bad to do my job and get some decent measure of satisfaction, and go home at night feeling that I offered a great service to the company for the salary they paid me. Even when Ralph is asking me to check on a few things, or add a few things, it's something I can handle. But when he goes off on one of his micromanaging binges, it's hard to keep my mouth shut.

Such was the case today.

Today, he was trying to find out the reason some group's end-of-day P/L wasn't matching what we had, and wanted to have me make some changes to the system we have that generates our numbers. I tried to explain that the difference between what we had and what he wanted was a design decision - specifically, there were a few "prices" we could use for a future, and the difference was between two, and we were using one, and the change would move to the other.

The problem would be that this would impact a lot of people, and the reason that the one was chosen in the first place (by the original developer) is now totally lost because he doesn't remember, and didn't comment why he did it. I was trying to explain that I didn't know why the system was the way it was, and Ralph get pretty testy.

"Can you send me the code?" he asked. 'Sure', I thought... with absolutely no coding experience in Java (limited to Matlab and Excel), he's got no chance to actually figure this out. I'll send him the files out of the SVN repository - even sending him different revisions of the file to show what I meant: the change was made, but the "why" was missing.

After a few minutes, I hear over my shoulder: "Bob, what's the code doing here?" I turn to see that he's got the latest code up and focusing on the location I highlighted in the email with the links to same. I got a little frustrated, but said nothing. I rolled over, and I'm guessing it showed on my face, or in my tone, but after about 30 seconds of me explaining the code to someone that doesn't know an object from a chair, he said rather loudly: "Hey! I need you to clam down!"

"Ralph" I said, "I'm frustrated because I feel that you don't trust me."

"Do you know the answer to the problem?" He asked me. "No? Then I think I might, so I wanted to look at the code."

Now this is a guy that's got no idea of what Java is. He doesn't understand references, objects, links, he's well intentioned, but clueless, in this regard. I try to explain a few things to him and he's not getting it. I have to explain several times over. It's getting out of hand.

In the end, he tells me to remove several lines of code (I suggested we not do that), and even get rid of error messages that he says are not errors at all. I realize that Ralph has gone off the deep end, and it's not worth having any further conversations with him. I agree to do what he's asked, do it and am done with it.

After about 15 mins, I realized this was a blessing in disguise. Ralph got me off the fence. He made it a very black and white decision for me: stay here and work with him, or go to a place that's actually nice to work.

No question.

When I made that decision, I was actually happy that the blow-up happened. Yeah, it was noisy, and yeah, it was out there in front of the entire group, but in the end, he made it possible for me to make a solid decision.

Thanks, Ralph. You made it easy on me.

This morning I saw that DataGraph 2.2 was out, and while I haven't been pushing that too much, it's nice to see the significant improvements that he's been making in the application and framework as time goes on. It's also very interesting to me that a significant portion of his libraries are in C++. Interesting.

Anyway, great to see the improvements.

This morning Gruber had a re-tweet about the real take on stupidity, and the original tweeter referenced this Wikipedia page. It's priceless.

It talks about the reason that so many uneducated (stupid) people are so sure of themselves, and so many really intelligent people are not. The crux, in my opinion, is that those with more knowledge know how much they don't know. Those that know very little feel they have it all pretty much under control.

Yeah.

From the article:

The unskilled therefore suffer from illusory superiority, rating their own ability as above average, much higher than in actuality; by contrast the highly skilled underrate their abilities, suffering from illusory inferiority. This leads to a perverse result where less competent people will rate their own ability higher than more competent people.

which also includes this fabulous quote from Bertrand Russell:

The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt. -- Bertrand Russell

This helps me feel much better about what I've been feeling lately. It made me giggle... it's made me feel much better about where I've been, where I'm going, and how I'm going to get there. What a lift.

This morning after I updated with the Security Update 2010-003, I noticed that Skitch said the beta period had expired and I needed to update. Yikes! I'd hate to be without Skitch, and I typically get these updates long before the beta expires. So I immediately updated and while it took a lot longer than normal (maybe a ton of people in the same boat as me?) it was back up and running.

It's far far too valuable in what I do to not have Skitch.

This morning I noticed that Apple released Security Update 2010-003 on Software Updates for the expressed purpose of fixing the remote code exploit in the Font handling. Pretty amazing that someone found that - in the fonts, of all places, but hey, if it's there, they will probably find it.

It's a touch annoying to have to reboot the box, but that's what it takes.

Today I had the very uncomfortable first of a co-worker coming up to me and telling me that they couldn't understand the code I'd written. It contained boolean algebra, and while it's not as easy as '1 + 1', it's not a lot harder to anyone that's been actually trained in the field of programming.

The code in question was using bit-mapped flags like the following:

  public static long ERROR_404          = (1 << 0);
  public static long ERROR_408          = (1 << 1);
  public static long ERROR_500          = (1 << 2);
  public static long CONNECTION_REFUSED = (1 << 3);
 
  // set up which errors you don't want to log
  long  ignoreErrs = ERROR_404 | CONNECTION_REFUSED;
 
  try {
    // ...snip...
  } catch (FileNotFoundException fnfe) {
    if ((ignoreErrs & ERROR_404) == 0) {
      log.error("Got an Error 404 (FileNotFoundException)!");
    }
  }

where it's clear that we don't need a full integer for each of the errors I wish to not log. Just a bit. Which makes perfect sense - so long as the number of errors you're trapping for are less than the bits in a Java long datatype. But in our case, it was jsut fine - I think we had a total of five errors to look for.

So my co-worker was clearly flustered about the code that allowed for the selective logging of each error type. They didn't understand that the code snippet:

  if ((bunchOfFlags & aMask) != 0) {
    // ...blah...
  }

is just saying: "If the aMask bit is set in the bunchOfFlags". It's a simple true/false condition, that (unfortunately) Java won't allow to be written:

  (bunchOfFlags & aMask)

because it says it can't compare a long to a boolean. Ugh... OK, fine. I'll put in the == 0 and Java will be happy. Still... I'll admit it's a little trickier when you're working with "negative logic" like what errors not to log, but really... is it all that hard?

Clearly, the answer is Yes for this person.

So I spent some time today, and I'm sure I'll need to finish it up in the morning because the big motivation for this level of control over the logging is my belief that errors in the log of any application should be a call to action and not "noise". Unfortunately, this isn't universally agreed in the group, and we have people that want to see errors that they have no intention of putting a halt to, where as I want that particular noise eliminated.

But being asked to remove boolean algebra from my code... that's a first. Amazing.

This afternoon, Gruber tweeted about this article from a writer I'd never heard of. I decided to read it and was stunned by the complete and utter lack of understanding about the human condition displayed by the writer.

He said:

David Brooks: Yes. I was going to say that for the first time in human history, rich people work longer hours than middle class or poor people. How do you construct a rich versus poor narrative when the rich are more industrious?

I mean really? To think that the rich actually work harder than the poor? What planet is this guy on? Clearly, he's never worked manual labor on a construction site. I've done that. Not even close, baby.

Thankfully, he's shown to be the ridiculous idiot he clearly is. But still... this is the kind of slop that gets the Republicans voting for Sarah Palin. Yikes.

I just got done talking to my two teammates about the value of defensive coding. Specifically, that there is value in Java of checking the value returned from every method call - including the JVM's new operator. I'm stunned that these guys believe that it's "silly" to check for things like that. I say, that's the bloody point of checking things in code. Have they not read Code Complete? Have they never really built large, critical systems that simply didn't have the option of failing?

My guess is, the answer is No.

In my code, you'll see a lot of code that looks like this:

  /**
   * This method returns the reference to the BKIRCProtocol that is
   * going to be monitoring the traffic from the IRC Server while we are
   * connected to it. If there is no listener defined at the time this is
   * first called, then create one because we really need to have it.
   */
  public synchronized BKIRCProtocolListener getListener() throws BKException {
    if (_listener == null) {
      _listener = new BKIRCProtocolListener(this);
      if (_listener == null) {
        throw new BKDebugException("BKIRCProtocol.getListener() - no protocol
          listener was present and one could not be created. This is a serious
          Java allocation error and needs to be looked into.");
      }
    }
 
    return _listener;
  }

Where I follow a new with a test for the resultant against null. It's standard coding style for me. When I was at First Chicago, I had the great fortune to work with an incredible group of guys. They were pivotal in having me look at coding as something a group can do as opposed to a series of individuals. In that group, I learned the value of having the code look like one mind wrote it. Debugging and fixing was as easy for one as it was for all. The style wasn't exactly mine, but we agreed on one for the group, and it stuck. It was great.

I have been trying to re-create that kind of experience and to some extent, I've been able to succeed in very limited cases. But I have seen it again. When you look at coding as not your work, but the team's work, you start to see that there's more to it than what you think. You care about the next guy getting the call to fix a problem you might have created. But when you write as a team, it's impossible to tell who wrote it, and that makes debugging vastly easier.

I guess I'm just surprised that I'm talking with developers making six-figures and they are talking about "how often" in the error checking. It's just stunning. You only have to write it once, and then it's always going to be there. That's the "how often" you need to focus on.

Expect more. Build it better than it has to be.

Today Apple announced upgrades to the MacBook Pro line. It's pretty slick. There are a few things that I really like about the machine:

• Core i7 - this will give me single-threaded performance of a 3.33GHz machine and when that's not needed, four cores (2 physical + 2 HT).
• New Graphics with Dynamic Change - no need to change the GPU you want to use in System Preferences and logout/login - the GPU is now automatically chosen based on the load. Plus, it's a faster, better GPU for the OpenCL bits.
• 512GB SSD - this is amazing to me: 512GB and SSD. That means all the space I have now and it's all a lot faster. Amazing.

Of course, it's not cheap, but then again, they never are. They are, however, the best laptops on the market. Amazingly Cool.

Yesterday I was adding a feature to one page in my web app, and I wasn't happy with it at all. It was excessively crowded, and to me clearly looked like a forced fit. Yet, this is just what I was asked to do, and until I really completed it, I couldn't be 100% sure that it'd be such a horrible mess. But it was. Holy Cow! What a mess.

So this morning I decided that I was going to leave that page as-is and add the feature to the web app as a new page - specifically used to show historical data for some portfolios. I know it wasn't what my manager wanted, as he'd "talked" to me trying to understand what I was building. I told him to wait and see, and still he kept at me about trying to understand. I hope I made it clear that I wasn't interested in back-seat designers, but I'm guessing he didn't get the hint at all.

In any case, I decided that I was going to do this, and it didn't matter what he said. I was going to do it right, because I just knew there was a better way to visualize the data. So I didn't stop.

When I got done with the page - heck, I didn't need to get done with it, but just to the main visualization. It was clearly a vastly superior interface for this kind of data. Far cleaner, far clearer. Wonderful. I wish I had a screen capture of the two to compare, but it's not in the cards at this time. So it goes.

What impresses me most about this experience is that I did just what I wanted to do and came out on the other side with something that was vastly superior for the end user. I'm not going to be bullied into making a slap-dash product again.