A common pattern when going through labs for various java classes is the pattern of building some main() method, performing a number of operations and spitting out a bunch of System.out.println()s. It’s an easy way to get feedback and avoid having to start with much context. Unfortunately it’s really a procedural style and requires eyeballing the output to see if things worked as expected.

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.

Land the Tech Job You Love turned out to be a good read full of actionable advice for job seekers who just happen to be techies. It covers everything from creating three versions of your resume to preparing a portfolio of work products to take with you to the interview. All of this is good advice.

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.

As a hiring manager the world has gotten easier with respect to getting some independent information on a given developer candidate. For many years now I’ve taken to doing a bit of googling for any candidate that passed the initial resume screening test.

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.