>>>>I do it all the time, If you deliver poorly written code that is difficult to maintain, you're doing your customer a disservice and providing shoddy work. As a professional, I would expect to be paid to the job and for doing it right. The nature of software development is that you don't always get it right the first time. Sometimes I do get it right, sometimes not, because it takes time to fully understand the problem and the solution. Sometimes you don't fully understand it until you've gone the wrong path. My customer pays for me to learn about how to fix the problem and for the fix itself.
>>>>
>>>>>"When you get the code working, rewrite it so it looks like you knew what you were doing all along"
>>>>>
>>>>> then try billing the client for that.
>>>
>>>Yes but quite often a client will want function now and rewriting something that works adds zero functionality now. All this rewrite for correctness strikes me as ivory tower stuff.
>>>
>>>If you write crap at least comments help.
>>
>>There's a school of thought that says "Comments are lies". When I first heard about it I thought it was total nonsense. Now I think there's a lot of truth to it. If you add comments, you have to maintain them just like you maintain the code itself. Far too often, even with my own code, I've run into cases where the code's been updated but the comments haven't - so the comments are lies, or at least misleading or incomplete.
>>
>>If code is "crap" then the comments are almost always worse.
>>
>>Every experienced programmer knows that the absolute best code is no code at all. One could similarly argue that the best comments are no comments at all. The holy grail is code written such that its purpose and operation is obvious to anyone with a reasonable grasp of the language used, and with no comments required.
>
>As Mike Feltman used to tell me, "Great code is self-documenting." :-) That said, comments should be for documenting design interactions that might be helpful if one is looking at the code for the first time. However a document succintly explaining the big picture design is the one that really matters.
>
>I think the problem with "Just get it working and get it out the door" is that it creates a mindset where design is considered a time-suck, ivory tower luxury and garbage code is applauded if it is written quickly and doesn't blow up before the check is cashed. It leads to some really intellectually lazy work that may fool managment for while but perpetuates the cycle of bad apps written by hacks later maintained by even less qualified hacks.
>
>I contend it is possible to write good code and good apps in a time-efficient fashion if habits of design and best practices have become second-nature and are insisted on as a matter of personal pride. I get tired of hearing people make the excuse that doing it right takes longer. I think knowing *how* to do it right takes a little more professional preparation but the actual doing it right is actually more efficient. The truth is, there are whole lot of people in our business that don' t have the intellectualy curiosity, auto-didactic discipline or mental horsepower to do what this demands.
>
>I've had a pretty diverse exposure to other professions and aspects of life and I can say that the most interesting minds I have encountered have been in this field. But I also find that there are a whole slew of people doing this who are completely ignorant of just how far over their heads they are. Writing software is really pretty easy. Writing good software isn't.
>
>I like this :
>
>http://m.techrepublic.com/blog/programming-and-development/seven-traits-of-effective-programmers/6750

Maybe your thinking of software as a polished tool. I'm thinking of it like popcorn :-)