Whenever I'm working on my personal project I do things that many modern developers would balk at. I'll design and redesign components left and right, I'll leave components in a half completed state, and I'll write the bare minimum of tests to ensure the system works. This is the risk that comes from approaching programming as an art-form. However, as any other artist, I will not go out there to show off my project until it's done, so I don't have to worry too much about pissing people off with my erratic style and questionable intermediate decisions.
On the other hand programming as a profession must be wholly different. If I am getting money for code the expectation is that people want to see whatever they're paying money for. In this case I don't have the opportunity to screw around and try to match the perfect set of ideas to the problem set. Instead I will give myself two or three iterations to do what I've been paid to do, and then I'll clean it up so it satisfies the technical requirements.
Fortunately the latter style of programming tends to lend itself a lot better to TDD, agile, responsiveness and all those other terms we love to throw around until our clients give us that blank stare. At the very least projects you get paid for should have some sort of spec, so you'll be able to say for certain whether you have or have not done what's expected of you.