The answer to your question depends on a lot of things but mostly
1. How big a job or time-consuming of a job is the re-factoring going to be?
2. Where are you in terms of deadlines and external commitments to getting stuff done.
3. How bad is what you have without re-factoring and how bad is it going to be to continue with it without re-factoring.

Generally, for hobbyist or personal projects you can do whatever you want but just be wary of the fact that constantly rewriting stuff in an attempt to make everything perfect and beautiful is a good way to never actually finish anything.

For non-hobbyist / stuff you are doing professionally, it's a different situation -- often the choice isn't yours to make when dates need to be hit and so forth.

Ideal solution: write up the perfectly designed code the first time in fifteen minutes.

It's half a jest, but seriously, good design is not very hard, and provides enormous returns for your effort. Good design is all about making your life easier. If you're spending more time designing and coding something "elegant" versus only coding something crufty, you're not doing it right.

Anything is NOT done before you refactor your code.
I usually split coding to small tasks, after each task, I refactor for it.
Or I will refactor if there is enough code, eg. 1000 lines of code.
The small refactor is lower cost than big one (refactor after whole project is done).

My first question is, do you guys often do the quick and dirty thing, and then go back to fix it later; or do you get a hold of yourself and make sure you get the job done well, first and foremost?

This really depends on a number of factors:

• Why are you writing the code?
  
  
  
  • Is this just a quick disposable test to find out if an idea works, or is it production code? If it's just a quick test that will be thrown away it's often best to simply get it working as quickly as possible, but production code should always be as clean as you're able to manage within any other constraints
    
  • Is the code part of a larger project and/or likely to be reused? Are you likely to need to adapt the code for other uses? When writing code that will be re-used, which you might need to re-purpose, or which will be part of a larger system it's important that you design it as well as possible. If you're writing a little script to automate a one-off task it really doesn't matter as long as it gets the job done properly.
    

Are you time limited? If you have a deadline to meet you might not have time to formulate and implement a better solution. Obviously if the "quick and dirty" solution is too dirty and will cause extensive additional problems or might not work correctly you'll need to try your best to get the deadline extended, but if it's going to work fine and won't cause a massive blow-out in some other area or at a later stage then it can sometimes be necessary to simply choose the solution that allows you to meet your deadline.

How "dirty" is the "quick and dirty" solution? As above, is it just a sub-optimal solution that will otherwise work alright, or are there serious problems with it?

Who will have to work with the code? If it will never be touched again it probably isn't overly important. If you're the only one who will have to work with it you might be comfortable with the less optimal solution for now. If others will have to work with your code then you probably want to put your best effort into the best/clearest design you are able to implement.

Do you refactor while coding, or do you refactor after everything's done?

A bit of both if needed, although refactoring while coding can normally be kept to a minimum -- almost entirely eliminated once you're more experienced -- by designing properly in the first place.



Do the best you can, but expect to make mistakes as you learn and grow as a programmer. It won't always be practical to fix all your mistakes if you want to continue to progress, but as long as you recognise and learn from them that's fine -- save perfection for when you're writing important code.


...and just to re-enforce what others have said, Code Complete is well worth the money once you've saved up.

Refactoring and feature additions should be in separate commits. This allows the definition of refactoring as a "behaviour preserving transformation" to be useful in a practical way beyond the immediate point of use - it's helpful information to have while regressing to find the source of a bug, for instance. If the refactoring is mixed with other changes it becomes much less useful.

Ideally, I'd like refactoring tools in IDEs to work with version control to check in and revert as I refactor/undo - and potentially even branch when I start refactoring then merge when I'm done and the tests pass.

When not working to a defined interface or protocol, I'll code a bit, get a good result, then analyze and (usually) re-write what I've written in an effort to make it easier to expand or to maintain, usually by identifying the generalizations that will make it flow better. Just as often, once I have something working, I'll then design a cleaner architecture that produces the same work, but with less spaghetti-coding. This holds true whether I'm working on terrain generators, machine-code assemblers, or data processing.

I mostly work in Java these days, so Eclipse's refactoring tools are often leveraged to re-organize my namespace, especially moving inner classes out into their own files with just two clicks. Moving classes from one namespace to another with all references kept intact is always nice.

When I do have to arrive at a specific interface, though, which is about half the time at work, I naturally have to work the same way we arrived at that interface spec in the first place; start at the goal, and problem-solve my way to the implementation that achieves it. This is generally actually faster than the other way, but because I won't always have progressively implemented versions along the way to the final product, it usually feels slower.

I've learnt through bitter experience that you should always start from a working, committed code base before attempting refactoring. As to the question of when to do refactoring... whenever it feels right. Seriously. If the codebase is all messed up and its eating away at you, spend some time cleaning it up. If its "ok", but not as elegant as it could be, but you're ok with that, then ignore it and work on other features.

Sometimes refactoring adds nothing to the codebase other than piece of mind. Other times it spawns useful ideas you might not have had otherwise.