Professional Development

Interview: Tom Copeland of PMD & Rubyforge

This is the first in a series of interviews we're making available to the CodeSnipers community. We have been working to track down people who we thought had something valuable to say about the software development community, tools, practices, or direction. Some of the names you will recognize immediately, others you've probably never heard of, but all of them have made an impact in one way or another. Without further delay... our first victim... er... is Tom Copeland of the PMD project.

Some of our community may be familiar with the Java tool PMD, but many are not. Could you tell us a bit about PMD and your role in the project?

Sure! PMD is a utility for finding various "opportunities for improvement" in Java source code. It uses static analysis, meaning that it parses and analyses the source code without actually running the program, to find unused code, unnecessary object creation, and bad practices. You can run it using Ant/Maven/command line/various IDEs and generate text, HTML or XML reports.

The value of ignorance

Several weeks ago, I read Stephan Paternot's book A Very Public Offering. He was one of the co-founders of This book then described the rather spectacular rise of the company, including a very impressive IPO - and the equally impressive crash of the firm. was one of the first big online communities. The story is a typical tale of the dot-com boom and bust.

I do not really want to talk about the book though.

Before the story itself begins, before the table of contents even, the reader finds the following quote:

Those who say it cannot be done should get out of the way of those who are already doing it.
- a wise fortune cookie

You know what? I like that.

AJAX and making Customers Feel Good

I've been working on a project for one my biggest customers now for many months. The system is huge, has automated a huge amount of work previously done by hand, and quite a bit on its own depending on specific business rules. One of the things it does is pull together various bits and pieces of information and puts it together into a single item for further processing.

The difficulty has been that there are so many rules, so many different conditions, and a variety of other things that affect the output, it gets to be quite difficult to test and preview the items. A few weeks ago, I had an idea... AJAX.

Soda in the fridge

There is an interesting thread over at Joel Spolsky's The Business of Software discussion forum:

[...] we got a new director of engineering. During a meeting on why we were late on our current project and what could be done about it, I joked and said he could get us a fridge in the lab with Mt. Dew in it. Well not an hour later, a guy comes in wheeling a mini fridge...stocked with Mt. Dew.
Personally, nothing has motivated me more to want to work in that dull white lab and put in some extra effort then that small jesture. (Provide a nice place to story)

Guide to Hiring Developers - Part III

This is the third of a three-article series that touch upon the subject of hiring developers. The first article had to do with CV screening. The second article discussed the process of the 1st interview, which is the equivalent of the phone screening that several companies do. The final part discusses the process of the 2nd interview. The 2nd interview is 100% technical in nature. My target is to see the candidate's level of technical expertise plus some things about her character. I have three main goals in this interview:

  1. Assess the candidate's technical expertise.
  2. See how the candidate reacts to difficult questions.
  3. Bring the candidate down to earth.

The Career Programmer: Guerilla Tactics for an Imperfect World

Here is something I learned over the last couple years, with the lessons mainly being conducted between the hours of 9 and 5: It rarely matters what is right or wrong. Decisions are not always based on logical thought. As a developer/programmer/software engineer/etc. you can say you just want to do your job and create software. The reality is that the work environment may not be entirely in agreement with your goals. Maybe other individuals/departments follow their own agendas at your cost and maybe you do not receive the freedom (and tools) to actually do your job. There can be many problems. Christopher Duncan's The Career Programmer: Guerilla Tactics for an Imperfect World is a book worth reading to understand your environment and deal with it more effectively.

Which books do you keep on hand?

There are a handful of books that I make a point of keeping close to my desk as general reference guides. I thought I'd take some time to share my list and see if there are others out there that I'm missing. Suggestions for specific languages, concepts, or principles are welcome.

Finding that software designer

In lots of companies software designers and software developers are separate job positions and require different skill sets. Software designers are those individuals who pay special attention to GUI standards, usability and overall system coherence. One of their roles is in a way to act as user's advocates to ensure that the software is designed in a way that the users are able to use it painlessly.

They are then constantly reciting (or questioning?) the opinions and teachings coming from Don Norman, Jacob Nielsen, Bruce Tognazzini, Joel Spolsky and, of course many more. Usability and consistency may be some of their favorite words.

Not Stopping

So, you're a programmer?
Well, yeah ...
Some corporate drone, sitting in a sad, dark cube?
Um, no, well, it's not like that ...
What, you don't sit in a cube?
I do when I am in the office. But I have this idea, I am working on at home ...
An idea?
Yeah yeah, and let me tell you, this is gonna be big. Real big. Seriously man, check it out...

And then it's all over. He had to get me started and now he has to listen to it all. His cool composure, the fresh tan and the overall contempt was too much to bear. I want to insist that there's something cool happening in my life, too. My wife tells me later that I had that wild look in my eyes again, as I was explaining myself, gesturing like crazy.

Guide to Hiring Developers - Part II

This is the second of a three-article series that touch upon the subject of hiring developers. The first part discussed the whole process and then focused on the issue of CV screening. This part discusses the process of the 1st interview, which is the equivalent of the phone screening that several companies do.