I may have some perfectionist traits, but whenever I do a code presentation, usually for a training seminar for my folks, I end up spending a lot of time making sure the code is pretty much perfect and follows all the coding conventions.

Much of the time I’m borrowing example code from other sites or books, and I have to go in and clean it up. Often variable names are inordinately short or they followed some rule that private variables start with an underscore. Since part of the point in teaching your own seminars is that you can completely customize it for your developers, I don’t want to miss the chance to reinforce are standards.

The danger is two fold if I don’t do a good clean-up job. One, they have fun ribbing me about blowing some standard instead of focusing on the examples. Two, they think something is acceptable because I had it in some slide example that way like used a

instead of Log4J.

Anyway I’m mostly ranting on this because I’m in the midst of putting together a TDD seminar for my folks. It’s a little scary since I don’t feel like I’ve ever gotten to work on a TDD team, though I’ve practiced it on my private projects for a few years now. As I’ve learned when acting in the instructor role I need to be overly prepared because I get really nervous when I’m speaking on something I don’t know cold.

Since we spent millions on Websphere we’re now having integrate RAD 6.0 for developing into WebSphere Portal and utilizing JSF. I kept hearing bad things from developers about how you were tied into the RAD way of doing things. And phrases like ‘Drink the IBM Kool-Aid’ or ‘Swallow the Blue Pill’ abounded. Some of the things which seemed painful were:

1. Based on Eclipse 3.0 so we have to step back to Java 1.4.2.
2. To build a web project you have to have wonderful directories like <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">

   1	JavaSource

   </div>
   

and

<div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
  <table cellspacing="0" cellpadding="0">
    <tr>
      <td class="line-numbers">
        <div>
          1<br />
        </div>
      </td>
      
      <td>
        <div class="text codecolorer">
          WebSource
        </div>
      </td>
    </tr>
  </table>
</div>

at the top level.</li> 

  * You can only deploy through RAD.</ol> 

The truth turned out to be not quite so bad. We still can&#8217;t do any 1.5 specific things so no generics, enums or the like. The default IBM directories are there, but you can add your own, so there horrible names are a little more palatable. Why exactly did the default

<div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
  <table cellspacing="0" cellpadding="0">
    <tr>
      <td class="line-numbers">
        <div>
          1<br />
        </div>
      </td>
      
      <td>
        <div class="text codecolorer">
          /src
        </div>
      </td>
    </tr>
  </table>
</div>

directory have to be

<div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
  <table cellspacing="0" cellpadding="0">
    <tr>
      <td class="line-numbers">
        <div>
          1<br />
        </div>
      </td>
      
      <td>
        <div class="text codecolorer">
          JavaSource
        </div>
      </td>
    </tr>
  </table>
</div>

? Finally I was able to add a build.xml file and it recognized it as ant specific. It turned out I had to change perspectives to the Java perspective to actually run a target, but that&#8217;s just one of those annoying Eclipse things. So now I&#8217;m pretty sure I can deploy without using some god awful RAD wizard.

Eclipse just isn&#8217;t a very user friendly IDE. Just to add a file I had to go through the following menus:

<pre>'Right Click' > New > Simple > File</pre>

That took me about 10 minutes of hunting and I thought I was actually going to have to add build.xml at the file system level just to add a single file. As long as I can still run a normal ant build file and have it deploy in Cruisecontrol I&#8217;ll be OK with it. I&#8217;ll probably force myself to run it as a default IDE for a while so I can help developers with workarounds and then I&#8217;m running screaming back to IntelliJ.

I had high hopes for Behind Closed Doors: Secrets of Great Management by Johanna Rothman and Esther Derby. I’ve generally had good experiences so far with the Pragmatic Publishers. I’ve probably purchased about half of their titles at this point and I even occasionally listen to Andy Hunt’s podcast.

They hype on this made it seem as if there might be some real revelations or new ideas, but my feeling after shooting through it last night is that it’s not bad, but not a great title either. The book just lacks some quality to keep you reading and follows a well known management book paradigm. Basically you follow some fictional character through a series of meetings where the great management wisdom is revealed. I did find it interesting that I’ve listened to podcasts by Johanna Rothman and found her real stories to be a lot more engaging.

The book covers the following topics among others:

• One on Ones – Nothing really new, but after a recent spate running across this in the Manager’s Tools Podcast and a Ken Blanchard seminar or two I’m going to try implementing them seriously for a few months.
• Coaching – This is something I do a good bit of already, could do better, but no real major new tips here.
• Delegation – I can’t say I’m that great at this, but I didn’t really come across any new techniques here.
• Feedback – Obviously feedback is critical. The suggestion is to give it quickly and focus on behavior not emotional responses.
• Effective Meetings – They cover general meetings, weekly team meetings, and 15 minute standup meetings. All good information, but again no real new tips.
• New Hires – I liked the part about setting up a checklist for a new employee. I’ve found this to be important many times. And spending a lot of time preparing for interviews leads to better hires.
• Project Portfolio – Basically track your major projects and keep track what’s going on over the next month or so. I’d be surprised how many managers survive without this for long.

So as a technical manager you learn that general management practices apply to you. It’s all good information, but not revolutionary. Part of the problem may be that I’ve been a technical manager for 3+ years already so maybe I’ve crossed the line for a book like this to be terribly relevant. The thing that makes me think differently is I’ve listened to most of the recent podcasts at Manager’s Tools and they manage to cover the same topics, but I find myself really reacting strongly to their presentation. They reference real stories and debate some finer points of the topics like whether you should take One on One notes on a Tablet PC versus paper. And it could be the audio presentation is more effective, but I’m generally a visual learner.

Anyway I’ve picked up Prefactoring by Ken Pugh and so far it seems like an intriquing read.

I just had to laugh at this one, after we were pointed to it by some consultants. They were explaining that SDO is the great new way to do object to relational mapping, a “best practice”, as they put it. Turns out in the only available book, a redbook, on the subject IBM points out how great they are because:

SDO is a powerful architecture that brings access to data closer to the Web application designer. SDO can be integrated with JSF pages and data access is generated into the page code Java classes. SDO can also be integrated with regular JSPs and access is performed through the tag library provided by SDO.

In other words you can essentially embed your data into your presentation layer. This is a great best practice commonly seen in frameworks like Coldfusion. IBM is quite the innovator. Maybe they meant this is a “best practice” for slick, quick demos to managers who haven’t coded in years.

My personal thoughts on referral bonuses is that I prefer to avoid them. I’ve referred in probably four or five people on my own. Some of those companies paid referral bonuses, but I either split them with the candidate or just turned the whole thing over to them. Personally I only referred in someone if I had faith they were a good fit and the company was a good place to work. Considering I worked for at least one dotbomb I may have misestimated on that one, but I was up front about the risks.

As a manager now with an option to offer a referral bonus, I’ve turned avoided them. My theory is that if someone’s isn’t willing to recommend an acquaintance unless there’s a referral bonus, then they probably won’t make that great of an employee. Much of my bias against them stems from a past company where I saw referrals badly abused so that a few employees could make $10,000 or more referring in some dubious hires.

Given the number of resumes and interviews I had to go through for our last developer hire, I’m considering rethinking my approach to this. Since I’m going to be pretty thoroughly vetting everyone, maybe it’s worth seeing if adding a $3000-$5000 referral bonus. If we end up hiring without a referral again nothing’s really lost in the experiment. And if it ends up being a referral I make, I’ll try to convince HR to nix it since that’s just a bit unethical.