What's it all about, Alfie?

Well... now that I'm an employee in a 300+ person organization, it's Yearly Review time. I had avoided it for about 8 years as a consultant, but there's no avoiding it in large-ish organizations these days. It seems that everyone is interested in getting feedback from the employee on their year, giving them feedback on the reality of their year, and then having them provide feedback on others around them. It's a process that's pretty standard with a few local modifications in most places I've heard about.

My question is this: Is it really a useful exercise, or is it just something to fill HR folders? I'm not convinced it's a clear-cut answer.

Certainly, the biggest advantage of these types of reviews is to cull out the under-performers. In this litigious society, every CEO and HR manager is trying to avoid a civil suit on some wrongful termination. So rather than worry about those lawsuits, they have these reviews. These form the basis of a written, regular, feedback of the employee's lack of acceptable performance. Then, when they choose to fire the person, they have all the written records to point to so as to avoid the lawsuit.

But is that really necessary?

The Overly Cautious Types

Certainly, it's one way of protecting yourself against lawsuits. But so would formal letters of poor performance. In fact, that's how they did it 30 yrs ago. You were told you're not "meeting your numbers" a couple of times by your boss. Then you got a letter, and then you got fired. It's pretty simple, and it's pretty direct. There's a cause, and an effect. There's no reason to wait 3, 6, or 9 months for the annual review process - you let them know when it's appropriate. Period.

Even in this day and age, I've been taken aside and told "Hey, lighten up" from time to time on a particularly tough day when I've been grumbling a bit. I can accept the reprimand, life is like that. If you're working your hardest, I for one, am not surprised that you ruffle a few feathers. So, in general, I'm a big fan of the "as needed, when needed" approach to both negative and positive feedback.

You can't train a dog not to poo in the house by yearly reviews. Address the issues when they occur with the proper level of documentation, if necessary.

But for those overly cautious types... those worried about civil suits... I can see some value in the ability to document people that should be fired. But the downsides of the review process to nearly everyone else is staggering.

The Standard Employee Review

Each review process has several categories. I've seen as few as 5 and as many as 20. They are all just varying degrees of job component classifications. In that, they are all the same. So let's look at the typical employee first. They are a middle-of-the-road employee. They get their work done acceptably, nothing amazing, but nothing bad. They blend into the woodwork, as it were, and do their jobs.

This person may think of themselves as a A-quality person in some regard. Maybe they are right, maybe not. But what's the real value of telling them that they are a C-quality person? Does it make them work harder? Not really. They are a grown-up. They have made their decisions. Maybe it's their home life, maybe it's the time they need to spend in their bowling league, but for whatever reason, they are giving the employer all they are going to give.

So who gains by telling this person they aren't as good as they'd like to think? No one. The reality is not going to motivate this person - in fact quite the opposite. This is going to demotivate this person. It might even make them feel a little hostile towards the manager or employer. Why? Because as much as this person may be kidding themselves, they wanted to believe that their efforts - and everyone makes efforts from time to time, is seen and appreciated. This "honest" feedback may be honest, but it's not going to help.

The alternative is true as well. A person that seems them as a C-quality person is not going to believe they are an A-quality person. They have a bad self-image, and no amount of management praise is going to change their self-assessment.

In either case, this isn't really helpful feedback. It may be necessary for a lot of reasons:

• setting yearly bonus expectations
• preparation of "cutback" lists in times of trouble
• assessment of people to be moved to less important projects

useful reasons, all - but not really helpful to the employee. Face it, all these can be accomplished with a talk from the manager or again the old style letter.

The Flawed Star

Let's look at the case of a person that is exceptional in nearly everything but one activity. Maybe they don't communicate well. Maybe they don't interact with customers in the best way. Maybe they don't understand the business as well as others. But in all other regards, this person is a star. What about them?

This person has decided that one part of their profile is just not as strong as the others, and like many human beings, chooses to do something they enjoy rather than work on something they do not. So they pour more energy into the things they are good at, and leave the things they are poor at to suffer. What does the review process do for them?

Maybe it is news to them, but most likely, they know exactly what the truth of their skill-set is. They don't need to be told. It's almost annoying that their faults are brought up again at this time, when it's clear that in every other regard they are such an incredible asset to the team. They aren't going to get cut. But every year they are going to be told how great they are except...

If it's not news to them, then they fall into the last category.

The Self-Aware Employee

In this case, the person knows how they are seen, what their strengths and weaknesses are, and has come to terms with them. They aren't going to be changing because someone fills out a form. They have decided exactly how hard they are going to work. They are either going to surf the web - or not, but no amount of reviewing is going to change their mind. This is who they are. Period.

To many, this person is annoying. In the extreme. They seem not to care that they can be better - no matter how trivial the work may seem to be to improve. They play to their strengths, and accept their limitations. Because of this, most of the time, they are very successful. When they aren't, they don't loose sleep over it. It just is.

For this person, the process is a joke. It's someone else's idea of a way to cover their behinds in case of the civil suit for wrongful termination. In the end, this person drifts through the process, accurately representing themselves, and the opinions of others, which possibly interesting, are not sufficient to sway this person from their course in life. It is, after all, their life, and they have purposefully chosen this path.

Verdict

So I look at all this and think in the end, it's a waste of time. Talk to, warn, and fire those that need firing. For the rest, tell them when they do something good, and talk to them when they do something you wish they hadn't.

Anyone that has kids knows this. If you want good kids, talk to them. Don't make it a yearly process. It just doesn't work that way.

Today I've been doing a fair share of heads-down coding on the Google Visualization DataTable in Java - to get it up to the current JavaScript API published by Google. I started with this update a few days ago, but I stopped at the filtering and sorting. Today I dug into the filtering and allowed either a Java List<Map>, or the standard JSON array of maps. To make this a little easier, I made a parser to take the JSON string and convert it into the Java List<Map> and then have the JSON version of the method call the Java version. Pretty simple, but the converter was a little tricky, but not too bad.

I was pleased with the filtering. It worked wonderfully, and while it's probably not the highest performance implementation, it's pretty good, and certainly good enough for what I'm going to be using it for initially, which is just filling out the API spec. But if there becomes a problem later, I can imagine a few ways to make it nicer, I just didn't mess with them, and so performance tests to see which is better.

But the really nice thing was just that I was able to shut the floor out, listen to some decent music instead, and focus on coding. The one thing I really enjoy. That was the treat I gave myself today - the pleasure of creating. I really don't get to do it enough.

I noticed this morning that Google Chrome dev 4.0.249.0 was out for the Mac, and it fixes the nasty JavaScript bug that I submitted to Google a while back. I'm really excited to see this fixed, not for the Mac, per se, but the fact that this was the reason the Google Chrome Frame stopped working.

When I got to work and restarted IE 8, I was able to see that the auto-updating of the Google Chrome component in the Google Chrome Frame was working and my pages were working once again. Fantastic! I really love it when good software is written by great engineers.

This morning I came in to a horrible problem brought on by a new business focus, and folks not asking the right people what the possible impact would be of a seemingly simple change. Both of the apps I'm responsible for suffered this morning - one was a disaster until I could get a fix in the code for the problem, and another was simply not showing the right data. Arguably, not a lot better, but at least it was up and running.

The problem started long before I joined the Shop with the decision by someone to make all the databases case-insensitive sorting. This means that the data: "Steve" and "STEVE" are different in the database, but if you try to do a SELECT on the data, you'll get both values on any variation of "Steve" in the WHERE clause.

Let's assume we had a table in this database where people's names were held.

then it would be possible to do the query:

  SELECT * FROM people WHERE FIRST='steve'

and get:

but you'd get the exact same results if you did:

  SELECT * FROM people WHERE FIRST='STEVE'

or:

  SELECT * FROM people WHERE FIRST='sTeVe'

It doesn't matter to the query processor. I can't see a possible reason for this - why not just force all the data in a table's column to be uppercase? It would make it case-insensitive, but not open you up to the following disaster.

Last evening something was added to this mythical table - a new "Steve Jobs". Let's say the table originally looked like this:

and they wanted to correct the mistake in the case of the name. Well... the obvious change to me is to run the SQL:

  UPDATE people
    SET FIRST='Steve', LAST='Jobs'
    WHERE ID=412

But that's not what was done. No, they created a new person so that the database looked like this:

now we're in a pickle. When we try to find Steve with the SQL:

  SELECT * FROM people WHERE FIRST='Steve'

we're going to get both of the rows:

and where we were expecting one row to be returned, we now have two. Different systems will handle this differently, but there's no way the database will be able to differentiate them by their names. In reality, the ID is all that you have, and that's typically not visible to the users of a complex system.

This is what hit me this morning - two rows, and the new row was the first one returned, and it wasn't completely set up properly, so a lot of the supporting data wasn't there. Disaster.

Since there's nothing you can do to the SELECT statement, you have to filter the output, so my code went from:

  String    sql = "select ID from people where First='" + name + "'";
  ResultSet rs = stmt.executeQuery(sql);
  if (rs != null) {
    if (rs.next()) {
      id = rs.getInt("ID");
    }
  }

to:

  String    sql = "select First, ID from people where First='" + name + "'";
  ResultSet rs = stmt.executeQuery(sql);
  if (rs != null) {
    while (rs.next()) {
      if (name.equals(rs.getString("First"))) {
        id = rs.getInt("ID");
        break;
      }
    }
  }

and then later in the code, of course, I need to check and see that I actually got something.

While it's not horrible, it's something that's totally avoidable by either setting the case on the fields in the table, or allowing correct case determination in the SELECT statements so that this would easily have been found out early in the process.

As it was, I spent several hours on this - fixing code, and planning for other similar problems as they migrated datasets in the database. It's just not necessary.

Today I've had a little fun with ampersands. Those little buggers are nasty to get right in the URLs and the HTML pages and XML config files of a typical Tomcat web site. But after having done it enough today, I think the rules are pretty simple, but need to be followed to the letter.

In URLs - Escape, Escape, Escape!

If you're in a JSP, or Java, in general, then the easiest thing for a URL is to use the URLEncoder that's in the standard JDK. It's possible to do the manual replacement, but it's so easy to use the URLEncoder that there's really no reason to do it the hard way.

  StringBuilder  vars = new StringBuilder();
 
  var.append("report=").append(URLEncoder.encode(report));
  var.append("&page=").append(URLEncoder.encode(page));
  var.append("&name=").append(URLEncoder.encode(name));

it's so easy, that there's no reason not to. However, a surprising number of developers forget to do this simple act.

In HTML Pages Go Verbose

It's been said that the escape sequence &amp; is one of the most verbose HTML escape sequences, and I have to agree. It's a mess, but it needs to exist for the reason that the ampersand is the escape sequence initiator. So it goes. In HTML, use it. It's just what you have to do.

In XML Config Go Verbose Again

It makes a little bit of sense to have the HTML and XML escape sequences for ampersand the same, but as with other things, I would not have been surprised if it had worked out that things were different in the two markups. What I am surprised at is that the URL escape code (%26) is not allowed in the XML config files, but then again, I guess it's exclusively for the URLs.

There's what I learned today. Doesn't sound like much, but it was a pain to pin down.

I had a pretty rough weekend, and Liza still isn't feeling very well, so today has been a short (8 hr) day at work because I needed to be home to help her out. It's no fun having a migraine, and with all she's been through, it seemed to be the least I could do. So I left a little early.

Before I did, it was a day of messing with the configuration of one of my inherited apps to make it more granular for the business. Their plans for next year include paying closer attention to things in slightly different portfolios, so the took a very large one and made it several small ones. Nothing really earth-shaking about it, but there's a lot of little configuration details to make sure that things are ready to go. Nothing earth-shaking, but time-consuming.

I sure hope Liza is feeling better tonight.

UPDATE: we took her to the doctor near the house and got her a migraine 'shot' to clear up the migraine. It's a horrible thing. I wish she felt better.

Today started off very nicely. I fixed up a few more things on my web app and was able to get rid of the fixed calendar on two pages and replace it with a pop-up version of the same calendar. It allowed me to free up a nice 200x200 px area that I really needed to free up for some other GUI elements. It was really nice to get something done and make progress on something.

I was then able to keep moving and add a new feature to the web app and allow a few interesting aggregations on the client. It was interestingly easy - I took the data, had the mappings from the existing columns to the aggregating columns and then simply run through all the rows collecting the data into the aggregate columns. Simple. One nice little function in the code and a few GUI widgets and we're good to go.

It's been very nice to get real progress made today. No problems with legacy apps... no never-ending performance problems... it's nice to make progress.

Today I finally had time to finish my move to the new development 'server' box in the server-room. It's a little 4-core 1U box, but it's what the "standard" development server is. So be it. I needed access to more memory than my desktop would hold, and this guy is capable of holding 192GB - which is nice, but it'll start with 32GB and see how we go from there.

Since I have no root access, I have to check a few things, ask a few things to be changed, and repeat until everything is set up as I need it. Not exactly hard, but it's detail work that needs to be done right so that should I need to build another box, they'll be able to use this as a template and stamp them out quite nicely.

After I got done with the move, I made a few much needed GUI changes to my web app. The fixed calendar was just taking up too much room and it had to go. Thankfully, it's also easily made into a pop-up calendar, with an INPUT tag associated with the value. It took a little messing with divs, but I got something that looks pretty nice, and now there's a lot more room on the page for new GUI features. Not bad.

Today has been a really hard day. I've worked all day trying to get the speed of this one process hitting a legacy Windows app up enough to make the users happy enough so that they don't ask for features cut to get the speed where they need it to be. I totally understand why they need the speed. I also know what's causing it to be slower - it's the additional features, but there has to be a balance between the two - for there are people that the new features are the more important part, and others that the speed is the more important part.

So I'm trying to get speed and features, but today was very disheartening.

For ten full hours I tried to get the speed up. I tried everything I could think of, and then thought up new ideas, and tried them. I was sure I could find the speed - but I couldn't. I ended the day with the same cycle times as I started with. Sure, they were a lot better than the production values, but that was hardware. Run the process on faster hardware and you get faster times.

Obvious, but it's all I had.

That's what we'll run with until we get even faster hardware for this guy. It's not really rocket science, but it's more than a little frustrating. But like so much in life, there's nothing I can do about it past what I've already done.

Today I spent a lot of time trying to figure out what the problem was with the hardware for this little feeder app to this larger webapp. I started with a desktop box, and got it set up and running. The times were nice, but still about twice what it was running on my desktop. So that spun off a big investigation as to why seemingly identical boxes are off by a factor of two.

After that for a bit, I was given a Windows Server to check. It was fine, but the times were slower - primarily due to slower processors in the server. Still, it was nice to see that I was able to run the application on Windows Server as opposed to just XP. But in the end, "nice, but no good", I was still a long way away from the marks I'd taken using my desktop.

When I went back to the desktop to try and account for the factor of 2, I noticed the network card was running at 1/10th that of my desktop, so I called in the network support guys to ask to have it switched up to 1Gbps. Turns out, they can't start until 4:15 pm. Yum.

I wish this was more clear-cut. I have something, but not enough. Have to keep at it tomorrow.