The Difference Between a Professional and an Amateur by Mike Cohn

Are you a professional or an amateur?

I'm going to ask you to consider being a professional. But, before I do and before you can answer the question I posed, I need to make sure you are fully aware of what I mean when I talk about being a professional.

For me, the difference is simple: A professional always does everything necessary to complete a job. An amateur sometimes chooses only the fun parts.

An amateur golfer, for example, may thrill at the crack of hitting a 300-yard drive but hate putting. And so that amateur may frequently choose to pick up the ball once it's "close enough" to the hole.

A professional golfer could never do this. The professional may still prefer hitting the long drives over making intricate putts. But the professional knows he needs to do both parts of the job.

The difference between professionals and amateurs shows up on software teams in the team members who only do the portions of the job they like.

This can happen on any role on a project. It could be the tester who doesn't enjoy talking to customers ("Analysts do that."). Or it could be the product owner who only wants to think about strategic, big new features rather than going into the nitty gritty of the implementation.

For any job there are good parts and the bad parts. The professionals do the full job, not just the fun parts.

One of the more common amateurs I've been encountering lately are programmers who will only code exactly what they are told. "I gave you precisely what you asked for," they'll say. And there's nothing wrong with that reply in some cases. But it's not appropriate all the time.

The professional programmer brings his or her full brain, experience and creativity to the job. When asked to develop a feature, the professional thinks about it: Are there gaps in what was asked for? Are there alternative and better solutions? Will it lead to later problems? And then the professional has conversations with the product owner based on the answers to these questions to determine exactly what the feature will look like when implemented.

In contrast, the amateur says, "OK, I'll give you exactly what you asked for." That's easier. The amateur programmer doesn't have to think about the work beyond the specification. Just code what was asked for.

Similarly, an amateur programmer says, "I just write code; I don't test." Oh, that programmer will probably do a bit of testing on his or her own code. But when the team nears the end of a sprint and could use a little help testing for a day, an amateur programmer is likely to just code ahead on the next features rather than doing the more helpful--but to some, less desirable--work of helping test.

Not doing all parts of a job is a luxury only afforded to amateurs. An amateur can hit the glamourous, powerful 300-yard drive and then pick up the ball on the green without putting. The amateur can write code and not be concerned that no users are benefitting from that code until a tester catches up and tests it weeks later.

Professionals don't do that.

A professional knows that ultimately his job is to do whatever it takes to help the team. Often that means taking the time to have conversations about the tasks at hand or taking on some of the less desirable parts of the work.

It’s hard to be agile with a team composed largely of amateurs. Amateurs tend to take the distinctly non-agile attitude of “that isn’t my job” and “I only do this type of work.”

Amateurs are more likely to be highly specialized and to feel entitled to work solely within their one specialization. While this can lead to people in that role feeling more efficient, it will reduce the overall throughput of the team. (That is, overall team velocity will suffer even though one role may feel more efficient.)

For many reasons, a team of amateurs makes software development more difficult.