This isn’t a novel concept, I’m aware that Jeff Langr and Mike Clark have talked about using this technique to pick up new languages. The concept is to remap these sort of lab exercises as TDD style means writing some tests using JUnit or TestNG instead. It takes a few minutes potentially to explain to students how JUnit works, but the concept isn’t much more than understanding executing a main method. There are some good bonuses:

• If they haven’t done TDD, the students get a chance to experiment with it in a classroom environment when they’re already prepared to learn new things.
• They don’t have to do strict TDD to get a benefit, but they can still take a learning test approach. Not sure what a given method will return just write a quick assertion and check.
• You have executable examples to look at long after you leave the class. This can be a benefit when you need to troubleshoot some issue you’re having.
• You don’t have to eyeball the results.

Next time you’re in a lab showing main() methods and getting feedback from System.out.println() just start with a test instead.

Hudson has a Continuous Integration Plugin game that gives you points for successful builds, adding tests, removing TODOs, etc. As a plugin it started out simple, but now allows you to get points based on:

• Doing a successful build.
• Adding new successful tests.
• Fixing PMD, FindBugs, or Checkstyle warnings.
• Fixing a compiler warning.
• Fixing a TODO.

Around a year ago I tried it out with my development team. It looked like a fun way to reinforce good practices, but I wasn’t sure how it would play out. As a dedicated gamer I loved the idea, but development teams contain all sorts of other personalities.

At the end of the year it was a mixed success. One developer really took to the plugin and even reported bugs and modified the rules to make it reflect reality a bit better. He brought up the scoreboard in a few team meetings and gently tried to foster some competition. At the end of the year he easily led the leader board. I had one of the higher scores myself as a caretaker of Hudson since I often ran builds to clarify something that had been configured wrong or to setup a new project. For the most part the rest of the team knew it was there, but never mentioned their score or ribbed anyone about how low or high they were on the scoreboard.

The key behavior you want on any development team is that the developers care about the CI build and fix it quickly when it breaks. As the year went along this behavior began to be integrated within the team. It took a bit of prodding in some cases, but eventually all the developers felt bad if the build was broken for long and stopped to fix the build before moving on again. The CI game may have played a small role in this, but I was happy with the results. I’d recommend trying it with any team and see how your results go. It didn’t encourage any negative behavior and the results could be impressive with more gaming centric developers.

Long ago Scott Ambler discussed the idea of a specializing generalist, an element critical for Agile teams. Stumbling across the definition of a generalist who has developed some deep skills in certain areas, but broad skills in a variety of functions felt natural. As a very old web developer I long ago spread out from my development roots. Passion and a love of learning led to a much wider spread of abilities. Just a few were:

• Project management which I happened into building web sites, intranets, and e-commerce projects. Eventually this would lead to picking up a PMP and moving into a Scrum Master role.
• Java and J2EE after starting my career with Perl and CGIs. I started with raw servlets and JSPs. From there I moved into Struts, DAOs, JSTL. Then to help with consulting gigs and get a broader view of the large J2EE stack I picked up a bunch of Sun certifications ending with the Sun Certified Enterprise Architect. I consider the path of preparing for all the certification tests and the project worth far more than the cert itself.
• Build tools were always a passion as I wanted to automate as much as I could. This led to a long time setting up the ant builds for every project and eventually looking into maven and the wonderful rake of the ruby world. Not too long after I discovered cruisecontrol and started setting up CI for every project. The last few years I’ve focused primarily on Hudson which is a fine build server, but I’m always looking for new ideas in CI servers.

As I stepped into management roles staying a generalist was critical. I can’t speak for other professions, but if you don’t stay well steeped in the technologies and practices that your team do much of your feedback will be dismissed as the ‘Pointy Haired Boss’. You need to be able to checkout the current version of a project, do a build, and talk to your tech lead about why they chose to use iBATIS over Hibernate for the ORM. You need to be able to walk through the code in some nasty legacy project and really feel the pain as a developer explains how the one JSP is 4300 lines long.

It’s also insurance against downturns. If you have skills in a variety of areas and can come up to speed quickly on new technologies many options are open. If you’re a manager who’s let the technology side slip away you have to fight for a very limited number of spots out there. Plus being a specializing generalist means you’re always having new learning experiences which is a great payoff all on its own.

The hidden gem in the book is the great guidelines for technical managers on how to conduct the recruiting process:

“A hiring manager who wants to get a real feel for her candidates’ skills will ask for examples of work. When I was hiring programmers, I told every candidate that I called in for a face-to-face interview to bring in code samples, printed on paper, so that we could discuss them during the interview. Unfortunately I was definitely in the minority. Ilya Talman, on o the top technical recruiters in Chicago, to me that he estimates only 15% of hiring managers ask to see samples of work.”

– Andy Lester

For developers bringing in their code and going over it gives you a much deeper feel for a person’s development skills than any single behavioral question.

Code samples give you a sense of how the developer looks and how important code hygiene is to them. You can ask about decisions as to why they didn’t refactor a longer method or why they named a class a particular way. In many technical interviews you’re never asked to go through code at all.

If you’re not already requiring code samples for prospective developers I’d suggest trying it out at the next opportunity. You’ll be surprised at the insights.

Back in the early to mid 2000s this search often didn’t yield too much information. Back then Facebook and LinkedIn either didn’t exist or were just getting started. Blogging was popular, but still relatively rare, and Twitter was still waiting for ODEO to fail first. I often found the only relevant hits in some old USENET posts, but they were often at a time when the candidate may have been in college. I can’t even remember getting a candidate who had a blog or one who worked on an open source project. Today the picture is different.

Assuming the candidate doesn’t have a very common name you’re about 80-90% likely they at least have a LinkedIn page and very often Facebook or twitter accounts show up. I get really excited if I can find a blog for there or even better some source code from an open source project or so. As a hiring manager this stuff is golden as you can get a lot of background on a candidate to help decide if they’re meeting the bar for at least a technical phone screen:

• Consistency: Does the LinkedIn or other information line up with the submitted resume. You don’t want to see a candidate who reports their job experience very differently online. Slightly out of date is fine, but when the employed dates are off by years, you’re probably not going to make the phone screen cutoff.
• Passion: This is a critical factor in any hire. Do you really enjoy the career you’re in or trying to break into. Blogs and open source here are easy ways to see this in a candidate. If they contribute maven plugins or work on a build tool you can see they really care about automation and release management. Negative opinions of certain technologies aren’t bad here, techies are passionate about what they don’t like as well, but I like to see reasoned arguments and a passion for some alternative.
• Learning: I only want to hire candidates who excel at picking up new technologies, tools, business domains, and practices. Seeing some tutorials, reading your twitter posts about messing with Clojure, or even seeing a list of books you’re currently reading along the side of your personal site can present compelling evidence that you enjoy keeping up with the software development field.
• Communication: Written content helps evaluate how someone communicates and blogs are especially helpful here. Even tweets can give you a sense of how someone can string together punchy short sentences. Often all you can find are posts in forums asking for help with a product issue, but the person’s skill at asking for help and describing the issue can give you a feel for their abilities.

I haven’t mentioned other items that you come across like that their kid sister had breast cancer or that their favorite hobby is Ultimate Frisbee. Those facts aren’t relevant to how they perform on the job. I try to ignore them altogether when doing research.

Finally, I’d suggest that if you’re on the market, and a many developers are currently you might want to at least look at your online profile. As credit checks and drug tests have become regular screening items for a number of employers an online search of your name is certainly becoming almost a standard item. There’s not much you can do if there’s something unfortunate out there that shows up at the top of Google searches. By enhancing your online presence with relevant blogs, twitter, or other publishing sites you can build up a more recent history that’s relevant to hiring managers out there who google your name. You might want to just go ahead and include it on your resume as long as the majority of the content is relevant. And contributing to an open source project is a great way to stand out from many other candidates and worth pointing out on a resume.

I took an opportunity to head down to OSCON a week or so ago on a free expo pass. I always wanted to attend OSCON up in Portland, but I never had the opportunity to go. Anyway I invited another developer along and made the morning drive down to San Jose amid unusually light traffic. Reminded me of the times I drove around during the dotcom bust.

As an expo attendee there were a number of free things to do beyond walking around looking at vendors. The bulk of these involved attending OSCamp which initially looked sort of like it might be an Open Space type offering, but ended up being more of a loosely organized mini conference. I listened to three different speakers.

Bill Shupp from digg.com gave a talk on the PHP PEAR proposal process works. The key takeaways were that it helped to bring PHP coders into a more formal process where you follow some coding standards, are expected to have unit tests, and go through a code review process. He explained that digg.com had really gotten into unit testing and TDD including hiring the author of PHPUnit to help them with the adoption. They are also running a CI server and a nice 52 inch monitor with red or green for each currently running sprint.

I didn’t catch the name of a speaker who explained how he got into open source through the PHPbb bulletin board software, but it was nice to see a high school student who really felt empowered by contributing to software that’s used by thousands of sites.

Marcus Westin from Meebo gave a talk on Javascript best practices which included a mention of HTML 5. It was compelling enough to make me think I should look into it. Meebo is essentially a giant javascript application and Marcus explained that he’s a full time Javascript engineer. I hadn’t really thought of the idea of full time javascript developers, but Meebo is actually hiring even in the bad economy. He talked about how they’d been cleaning up the codebase over time, but there was still some 8000 line Javascript file that was too hairy to refactor. Sounds like a great challenge to get some test harness around.

Overall I enjoyed the free expo day at OSCON, and if I get the chance to be sponsored by my employer in the future I’d put it on my short list of potential conferences.

About half my career has been inside professional service firms. The work has quite a few perks and you’re constantly pushed to learn new things. Having spent quite a bit of time within IT departments as a manager I did sometimes missed the wealth of different clients and projects you’re exposed to as a consultant.

I’m not sure how common the practice is, but after leaving my last professional services firm about five years ago they let me know they considered me part of the alumni network. I remember thinking it was a novel way to approach employees who leave your company on good terms. I’m not sure how common the approach is, but I think it pays significant dividends. Over a few years I got a few little goodies in the mail including a USB key at one point and I ended up doing a few very short engagements to help out the local office.

For the professional services firm this sort of practice is a little extra effort, but pays particular dividends:

• You maintain a good relationship with former employees which helps in a small way your overall brand.
• Those employees may send prospective new employees your way who are already well recommended.
• Former employees may need some professional services and you’re often invited to compete for work.
• The alumni member may throw some leads your way when they find out about potential projects.
• Those alumni members may someday return to your firm bringing back valuable experiences from their time outside the firm.

As I now find myself returning to the fold with my former firm, I’m impressed with the little extra effort they took to stay in touch.

Unit testing is a practice that takes years to sink in. For many the first experience with the green/red bar is interesting, but not life altering. Maybe it was just a quick demo. They go back to the normal debugging patterns in the IDE or with printing output to the terminal. They try testing for a bit and find battling with legacy code just doesn’t feel like its worth the effort.

How do you effect change here? After experience with several groups I’ve found a gradual approach to work better than total immersion:

• Exposing the team to the concepts, especially if they haven’t really seen a true TDD session.
• Explaining the benefits to them as developers with reduction in defects, better code that’s easier to refactor, and knowing that when you get asked to work on a legacy codebase with a decent test harness that you won’t have to cross your fingers that the new feature you added didn’t break some other code.
• Continuing the conversation through one on ones and other means of how testing is going and where they’re having trouble writing tests or how writing the tests first might work a little better, or even starting with just some larger integration tests. With one team I asked the question of all the developers every week, ‘How many tests did you write this week?’
• Celebrating as code coverage metrics start climbing and pointing back at the reduction in defects.

While I often hoped the process of becoming real TDD style developers would take people a few months, it often took years. I never saw overnight success with adoption, but after time I started to see ‘aha’ moments among many of the developers:

• A developer who was dedicated to testing let about 20 unit tests start failing because he’d made some changes to the domain model. He knew he needed to get back to them, but had prioritized some other work. As the tech lead on the project who I’d worked with for years saw the failure email from the CI server he rushed over right away and got the developer refocused on fixing the tests first.
• Another developer finished off a recent project release and had zero real defects. The code coverage was well over 80% and among the best tested code in the organization. I’d started introducing testing to that developer over 6 years ago, but now he feels bad not writing tests.

As a manager and a person I treasure these stories as I hear them even if it they were years in the making. They’re more important than any kudos on an annual review or a big end of year bonus.

The picture pretty much speaks for itself. I haven’t had to make business cards on my own in years, but Zazzle made it pretty simple to do online. I created the logo at faceyourmanga.it. Even in the days of the web a card can have some impact.

Every status report needs to cover the basics like budget, scope, and schedule. Other than that the big thing is to point out new risks or items that have been mitigated. In an Agile context the status reports can often be eliminated entirely, but it tends to be a document people hold onto when getting adjusted to Agile. They often looks like paper versions of dashboards with the traditional red/yellow/green designations. All green means no need to read. Then again I once worked for a director who was actually color blind so I’d make sure the colors are also spelled out.

As a PM I remember borrowing my first status template from another PM who had in turn adopted it from her time at Andersen Consulting (Accenture after the rebranding). I adjusted it, but I’ve used it ever since. I can’t say I have a favorite format for project status reports, but I do know they need to communicate the key points as succinctly as possible. As a PM it’s important to know who’s going to actually read these reports. Some of your audience much prefers to here a verbal update even if it’s very short.

As a manager the best approach to status reports is to stay directly connected with your projects so you don’t need to rely on them. You should be spending a significant portion of time with the bigger projects or the projects that are struggling potentially only relying on status reports for the well oiled smaller projects that are just getting done. And don’t forget to reward those projects that are just getting done right without much need of your services. These are the well managed projects that should be rewarded more often.

Finally, I think I should expand on email and status reports. As managers you typically get 150-200+ emails a day many CCed or forwarded to you as an FYI. When you send that very detailed status report as a Word attachment much of your audience will never read it. I realize PMs often spend a painful 30-60 minutes tweaking the status report to send out every week only for it to go almost completely unread. What I really want is the key points of the status report directly in the email. That means you can send the attachment, but make sure you copy the critical stuff into the body of the email. The pain involved in not being able to read it in the preview pane, having to click on the attachment, wait a few seconds for Word to bring it up and render it just to start reading that nothing critical really happened this week often isn’t worth it. And an email link to the status report buried in project server is rarely any better. So, please don’t rely on attachments.