Joel Spolsky argues recently somewhat tongue in cheek that Java just isn’t a good language to differentiate potential programmer candidates. At a high level I can agree with the sentiment that you want to know that someone knows more than Java.

On the idea of weeding people out I can’t say that his focus on understanding the ins and outs of pointers makes a whole heck of a lot of sense. Doing my undergrad at Georgia Tech in Physics many years ago my weed out courses were Differential Equations and Thermodynamics as I remember. I remember a time honored tradition at Tech was explaining to the incoming freshmen:

Look to your right, now look to your left. By the time you graduate neither of those people will be there.

I remember thinking at the time that they were exaggerating. By the time I graduated 4 years later I realized they weren’t.

Still with most candidates I look at the college they graduated from is a single line on the resume. Much more important is what they’ve actually done and whether they can actually describe it. A really great candidate would have a blog they could point me at and maybe an open source project or two that they had contributed to. I’m not sure that having them explain pointers means much to me, but I do typically ask a question about which language they’d prefer to use and why?

I have a defacto rule I try to follow with resource allocation. For any project beyond simple maintenance I always assign 2+ developers. The reasons are fairly obvious:

• At least two developers know the source code.
• Each developer is able to bounce ideas off the other one and help work through roadblocks.
• It’s hard to develop tech leads if most people work on solo developer projects.
• It allows each developer to typically work on more projects per year, lessening the chance that the only project they work on ends up being cancelled.
• If a single developer goes on a 3 week vacation the project grinds to a halt.
• I don’t have a lot of developers who own certain software products and are then over utilized for any enhancement requests. Example, one of our products typically has at least one major enhancement per year. We have one developer who really knows this product and so whenever the business decides to add an enhancement we lose his talents for a few months, often in the middle of another project.
• And lastly, “The bogeyman hates the buddy system.” Or spreading your risk is almost always a good thing.

Stumbled across this post by Dave Churchville where he argues that J2EE has killed of OOP. I find it pretty close to the truth with the web applications we build. We don’t get to build a whole lot of first class objects. I find many of my developers haven’t grokked OO all that well, because J2EE largely allows them to ignore most of OO.

Over the Xmas break I finally freed up enough time to do a shallow dive into Ruby via the Pickaxe book. So far it’s very enjoyable for a variety of reasons.

This is the first completely new language I’ve tried to learn after becoming test infected. It’s nice to do really simple things and keep executable tests around as a learning tool. So even very simple things like how Ruby handles escapes in single versus double quoted strings becomes

:

def testSingleVersusDoubleQuotes
  assert_not_equal("This line has a\n carriage return",
                   'This line has a\n carriage return')
end

I’ve seen Mike Clark take this approach to learning Ruby and Jeff Langr take this approach with Java 1.5, which is part of what gave me the idea.

Then there’s the shiny new toy aspect which is so far pretty obvious. Ruby is the new cool language. I think one advantage to this that I’m experiencing is that the Pickaxe book is a very good intro text to a language. I remember not really being happy recommending an intro book for Java programmers until Head First Java came out about 2 years ago.

Finally, there’s the simplicity aspect I find very appealing. Java and its associated frameworks, libraries, and tools has grown into a complex mix no one could ever expect to fully master. Ruby is at this point pretty simple. I haven’t even really looked at Ruby on Rails, but one web framework versus the plethora in Java does sound enticing.

Anyway it’s a good time of year to play with shiny objects.

For a while now I’ve seen the following error show up in our Checkstyle reports:

There was a pattern to this where any custom exception couldn’t be looked up. After about 30 minutes of googling about usually just finding people’s checkstyle reports I came across the suggestion to take out</p>

</a>. That solved the problem.