I've actually written about this topic before - but I think it's important especially when considering quality. Often times the first solution we code is not the best one. It might do the job but you've most probably coded it while focusing on the steps to arrive to a solution and not really implementing it in the most effective manner.
For me, my initial codes do not often follow the conventions or standards in the project I am working (unless I master it completely). I code to understand how parts link to each other and how I can reach the expected solution. Once done, I note the flow and stash my codes. I try once again usually after a break, now with a better view of the situation.
In addition, at this stage, you can also optimise your codes in a way that is more understandable to other human beings. For instance, instead of writing everything in a single function that might be difficult to comprehend, you can then break it into parts that is easier to follow.
Now this is possible if and only if time is not the highest constraint. If you have urgent deadlines, this approach might be challenging.
In my perspective, the initial codes are an excellent way of understanding the problem, the domain and the framework you're working; plus how to stitch everything together.
To conclude, the main idea is to keep the option possible for redoing your initial work.