Becoming a Software Professional

In most areas of sport (and life) a professional is one who gets paid; an amateur is one who does it for free and for fun.

Steven Pressfield tries to define the difference in The War of Art:

The amateur plays for fun. The professional plays for keeps.

To the amateur, the game is his avocation. To the pro, it’s his vocation.

The amateur plays part-time, the professional full-time.

The amateur is a weekend warrior. The professional is there seven days a week.

I think he's got it wrong. There are plenty of programmers who don't "play for  fun," who program as a vocation and not a hobby, who work full time, and who are there, often unhappily, nearly seven days a week. That doesn't make them pros in my book.

To me the difference has nothing to do with money or love. It's a different attitude:

• Amateurs go through the motions, professionals focus on what they do.
• Amateurs are satisfied with good enough; professionals push the limits.
• Amateurs just do their work; professionals do their work and study it.
• Amateurs see their work as an isolated subject; professionals tie nearly every field of study to their work.
• Amateurs exercise skills; professionals exercise them--and practice the most important ones.

Thinking about this, I'm halfway between amateur and pro--and I'm now determined to be a pro. That's what this blog is about.

What’s this blog about?

Software Economics is about the costs of developing software and how (and how not) to reduce those costs.

It’s also about what makes software valuable, and how (and how not) to make it more valuable.

This blog is the result of musings on the subject that I’ve had over a 40+ year career in software, and some recent, intense investigations.

I hope that it will help me organize my thoughts and focus my investigations.

I also hope it will provoke some good comments and new ideas from readers.

It’s based on the following hypotheses and questions—and no doubt will surface others.

Technorati Tags: Economics,Goals

• Most companies are not very good at developing software—but some are great. What can we learn from the great ones?.
• Most programmers are not very good at developing software—but some are great. What can we learn from the great ones?
• Most companies that are trying to improve software development are going about it the wrong way—but some are doing it well. What can we learn from them.
• How would an individual (me, for example) go about dramatically improving their own software economics?
• How would a manager go about it?