Ok. I spent over 20 years programming in corporations. For the last year or so I have been programming for my own enjoyment creating web apps and iPad apps. How is my programming behavior when I'm programming for myself different from when I'm programming for my employer? How does it feel?

Well, working for myself, I don't often take on a project that looks boring or that is simply a repeat of something I have done before. Working for a productivity-enthralled corporation, I often worked on things I had done before or spent time guiding others in doing things I had done before because that is more "productive". (Productive being defined as whatever produces the largest payout for the corporate officers. I used to think it was whatever benefited the shareholders most, but that has proven not in fact to be the case.)

Doing something over even once when working for a corporation is seen as an admission of failure or incompetence, so a large amount of effort is spent in design to make sure that it is done right the first time. Of course it is not always done right the first time, so additional effort is spent trying to avoid simply admitting failure and starting over -- which would have been the right thing to do in many cases.

I really only write applications for myself. If I wouldn't be interested in using it, then I'm probably not qualified to write it. Contrast that with the corporate world where many programmers don't even understand what the application they're working on is for.

When I code for myself I usually start in what amounts to a prototyping mode -- just make it work; don't worry about architecture, memory leaks, patterns or anything. Just make the application work and demonstrate that all the essential algorithms and the UI flow are understood and uncover any hidden gotchas. I usually uncover the possibility of great features that I didn't originally think of and discover that some features I thought were really cool are not in fact very useful and seem to be difficult to implement properly in any case.

So the definition of the product is influenced by the experience of building it and trying to use it in the first phase of development. In a corporate shop, that level of feedback is generally non-existent -- the barrier between the programmers and the domain experts for the product is so high that product specifications are essentially given -- and the programmers couldn't judge whether a feature is useful for the end user or not anyway.

Then I re-factor the prototype to create the final product, copy-and-pasting paragraphs of code into new classes and often re-writing the same piece of functionality many times until I either can't think of how to make it better or until I'm actually satisfied. At this stage, there are times when the code is so broken that it won't even run. Imagine this in a corporate shop: 'What do you mean you're making it better? It worked yesterday and it doesn't work now. Shouldn't you be spending your time fixing something that is broken instead of breaking something that works?"

I don't have a schedule. It's done when it's done and its done when I'm not embarrassed to release it. I may decide that a feature is not worth the bother and remove it -- and wait to see if someone requests it after the app is deployed -- but not because I'm being measured on meeting some arbitrary schedule.

I never start a project if I already know how to do everything required. That would be boring. I want to discover new technologies, alternatives to the way I have been doing things, and learn new stuff. I could write another C# Windows program using Visual Studio on a PC -- or I could write an iPad application in Objective-C using Xcode on a Mac -- or I could write a web-based app using Pharo Smalltalk and Seaside on Linux. It's just more interesting to learn the alternative platform tools than to keep doing the same thing over and over. And I find that I can make better judgements about the quality of the platforms involved than I could when I relied on prejudice and ignorance.

I heard somewhere that an expert is someone who learns more and more about less and less until he knows all there is to know about nothing at all...