Noticed today that Adium 1.4b16 is out with only three bugs left to be fixed until they release 1.4 final. I have to admit, this is one of the more complex pieces of code I use that's open source... it's put together by a bunch of guys that do it for the fun of it. Gotta appreciate the effort. I know I sure do.
This morning I noticed that HandBrake 0.9.4 was released - now with 64-bit versions that are Snow Leopard ready. It's my favorite way to rip DVDs for my Mac and iPhone - there's just nothing that even comes close.
This morning I noticed that iPhoto 8.1.1 was out on Software Updates. Not a major update, mostly effecting the facial recognition, but still, it's nice to see the update. I take a lot more pictures with my iPhone than I ever did in the past. iPhoto makes it very easy to organize and share them.
Today I had a most uncomfortable experience. We are using Subversion as our SCM, and while it's generally quite nice, it's a little difficult to branch with it. More to the point, it's difficult enough that some folks simply refuse to branch. This really makes the SCM a one-way train: no backing up... no detours... always ahead, straight ahead. It's really selling the product short, but more importantly it's very limiting.
So today I had changes that needed to go in, but needed database changes before they could go to UAT. It's all checked in because it's running great in Test, and I expected the database changes to be made this afternoon. Bummer is, they aren't going to be made, it seems, this afternoon, but that's not really the problem.
The problem was a teammate wanted to push to UAT with changes, and had updated before making their changes, which is something you should do. Problem is, they can't push to test until the database changes are done. So what's the fix?
Well, if we're using SVN, the solution would be to branch off the trunk one revision back of my checkins, add in the changes to the system on the branch, check it in, and publish it to UAT. Then, merge the branch back in on the trunk and everything is fine. There's a record of what went to UAT, and it's the "textbook" way of getting around this problem.
But what happens if you are unwilling to branch SVN? Well... you might ask your co-worker (that would be me) to back out their changes so you could put your changes on the trunk without any branching. This certainly works, because then I'll put them back in and everyone would be happy: the person that didn't want to branch wouldn't have to, and I'd have to back-out and then put back in again, my changes.
Wait a sec... doesn't sound like everyone is happy. I'm getting the short-end of the stick.
Given that people aren't going to want to use branching, the best solution (in my opinion) is a Distributed SCM - like git. With git, I would have had my code checked-in, but not pushed to the central repository. I'd build that into the "push to UAT" script so that the central repository always has what's in UAT, but every developer is free to SCM whatever they want without having to worry about others using that repository.
It really is a very unique way of looking at the problem: use a distributed model so that you don't have to interact with others except at times of mutual agreement.
I'm going to be pushing to use git at the Shop now. This is just not something I want to have to go through again. It's only happened once, but that was more than enough. I can't make people learn to use the tools, so the next best thing is to isolate myself from them.
This morning, another release of OmniGraphSketcher 1.1 (this time: beta 2) was released. It's getting more full-featured with every release, and I have to say, it is fast approaching my favorite visualization tool - DataGraph.
I think OmniGraphSketcher is focused on the Keynote-style graphs, and DataGraph is focused on the scientific journal market. Still, they are getting closer, and that's great news.
This morning the Panic guys released Transmit 3.7 but rather than it being a major release, the release notes simply state:
- Fixed an encoding bug that could cause issues with both international filenames and WebDAV.
which seems a little anti-climactic, but so it goes. Still, a great app by a fine bunch of indie Mac developers.
Today I spent a good bit of the morning finishing up a few things on my first yearly review here at The Shop. One of the most disappointing things about the review was that I needed to create a development plan for the coming year. This makes sense then you're talking about a 27 year old kid - but by 47, if I'm not on the top of my game - and able to stay there, then I shouldn't be in this position. It's like asking Tiger Woods "Yo, Tiger - what are your plans for a better game next year?"
I'm not saying I'm the Tiger Woods of coding, but I also don't need to have a development plan because people are put-off by my intensity, and some are scared to approach me. While I don't see this as a wonderful asset, I have to say that the review pointed out that my skills, speed, quality of work, and communication are the best around. "Raising the bar..." and "Setting the standard..." were quotes from the review.
So yeah, I can be focused and intense, and this can put off some folks. I don't mean it to happen, but then again, it's not like it's a mystery, either. Anyway... I needed to finish up some stuff with the review. Tomorrow it'll be over, and we'll see what happens as a consequence of this with the bonus. That will be very enlightening.
Once I was done with that, I had to mess around with this web app I inherited, and once again, found how horribly built this code is. The original author decided that comments were unnecessary at the time, and subsequently was not able to help me with anything I needed to figure out. He's a nice guy... I like him, personally... but if I were his manager, I'd tell him that if he did this again, I'd have him on app support for six months. It's a disgrace.
So I had to struggle through this bad codebase trying to figure out what needed to be done, and while it was only about 3 hrs of work, it seemed like an eternity. I want to do a good job, but it's tasks like this that make me want to scream.
When I got done with that, I was able to spend a little time fiddling with Filemaker Pro 10 on the application for a friend's office that needed a few changes. Interestingly, the changes were very minor - the format of a date field, the change of a report field, the calculation of the rows in a table... pretty simple stuff. It took me no more than an hour and all the things they've been worrying about for months were fixed.
It's amazing how unimportant customer service is to some folks. The original developer was getting $80/month for this app, and they wanted a few changes. He probably could have changed them in 10 mins, but chose not to. Things kept getting nasty, and finally, he told them it's over. That's a first - the developer firing the client. But that's when they came to me.
Too bad. He's out $80/month and they get what they wanted all along. His loss.
One of the tools that has made the last year of my professional coding very nice is the H2 Database Engine. It's 100% Java, it's fast, it's flat-file or in-memory, and it's just as rock-solid as PostgreSQL. I love both of these databases, and while I can use others, if I get the choice, I'll use one of these.
H2 is amazing as an in-memory database, but it does file-system database as well. It's got all the things you'd want in a database: multi-version concurrency control, triggers, foreign keys - the works. It's super simple to use as well. Could not be easier.
Love it when we see things improving in it.
Today I saw that Björn was able to release MacVim Snapshot 51 with a lot of additions - including a Core Text renderer that should be the fastest way to render text on the Mac in Leopard (and Snow Leopard). While I haven't seen a lot of lagging rendering, it's always nice to see the best you can see when you're hoping around and scrolling in an editor - like Vim.
Again, Vim is probably my favorite tool for working with text, and MacVim is an excellent port to the Mac. It's really something you have to try.
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?
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.
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:
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.
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.
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.
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.