Back in June I went through the pain of trying to make my way through Spring: A Developer’s Notebook. It turns out that Bruce Tate himself admitted that the book was badly done in his Amazon one star review:
My appologies to all readers, and O’Reilly customers. I let you down. There’s no other way to put it. This book’s quality sucked.
Makes me feel justified in my frustrations. It does bring up huge issues about O’Reilly’s editing standards. If most the examples don’t actually work how did this ever get published?
This is a snapshot of an Excel Sprint Burndown spreadsheet for one of my projects. My employee, let’s call him George P. Burdell, isn’t allowed to be a Scrummaster. It’s political, but basically they want to move real slow with rolling out Scrum, so we’re doing it anyway in “super secret squirrel” mode. Hence funny little notations like this one.
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:
- Based on Eclipse 3.0 so we have to step back to Java 1.4.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;">
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’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’s just one of those annoying Eclipse things. So now I’m pretty sure I can deploy without using some god awful RAD wizard. Eclipse just isn’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’ll be OK with it. I’ll probably force myself to run it as a default IDE for a while so I can help developers with workarounds and then I’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.