I heard an especially annoying podcast by Nancy Flynn on using IM at work. The whole tone of the talk was how companies needed to get control of IM clients because their “rogue” employees might expose them to some sort of litigation risk. These employees are dangerous because they download these IM clients and use them to communicate more effectively.

The solution of course was to lock down everything and establish strict policies. What goes unspoken is that by locking down a tool like IM you drain it of effectiveness. The underlying assumption is not to trust your employees which is where a lot of bureaucracy comes from. The reality is bad employees will abuse any privilege, so you’re just taking things away from your best employees.

Of course personally I try to be careful using IM much because it can be a pretty annoying interruption if you pay to much attention to it.

This Monday as I was typing my way through a demo in front of 7 developers I noticed as I made typos, etc, that most of the comments were coming from the front row. Turns out after I talked to several people in the class that it was hard to read code in 12pt type at 1024×768, especially from the back row.

So far I’ve found two fixes. I can change the default font size to about 16pt in IntelliJ IDEA or since I’m on a Mac I can set the universal accessibility option to zoom to about 1.5 times when I hit the Apple-option-equals combo. I’ll probably just go with the 16pt size option though

As I needed a break after prepping for and teaching a JUnit TDD class I dove lightly, feet first into Ruby last night. Since Ruby’s already comes with OS X this was even a bit easier than I figured. Just playing with Strings so far, but I really like that the unit testing package is in the core libraries, or at least I think it is, I’m really green at this point.

Anyway I could see some real benefits in having something like JUnit included with the core java libraries to really help encourage unit testing.

I ran through a seminar with 7 of my developers today covering JUnit and TDD. Overall I think it went pretty well. I overestimated the material and labs we could get through, and I ended up dumping two labs out of five. Still they got a real hands on experience and I still managed to run through Bob Martin’s Bowling Game Kata.

I snuck in a good bit of pair programming. We had to run the class on our own laptops with only a few to go around, thus all but one of the developers were paired up. As usual I overheard some good conversations debating the best approaches. The one solo developer shot through the labs faster than any of the pairs, but I’m just going to chalk that up to his skill level.

I think by the end of the Bowling Game Kata that a lot of them really got it. Over the next few months we’ll see how well this strategy worked. Next I get to spread the wealth to the rest of our java developers, and lucky for them I’ve worked out some of the kinks in the class with my first group.

The number one request for a follow-up class focused on approaches for testing databases and GUIs.

I was talking code with a very old friend, junior year of high school counts as pretty old for me. Anyway he mentioned that I wrote some scary Perl code that he had to look over back in 1998. I admitted that yes, I was just cutting my teeth on more complex coding at that point and I was in a bit over my head. I remember back then thinking that my solution felt wrong even though the 3000 lines of procedural code worked. I remember thinking only that I felt better that a good bit of the code was modularized into individual functions that were generally not to big.

I had the same feeling the first time I tried to implement unit tests with JUnit about 3 years ago. I did the traditional test the DAOs approach which was really pretty much testing the database. The tests took a good while to run, they broke all the time because the data got out of sync. And any change to the DDL and more test rewriting. My approach just felt wrong, though I couldn’t pin down why. Tomorrow I’ll pass that story along to my developers when I run them through a JUnit class so they can understand that this stuff isn’t necessarily obvious the first time through.