Hi @shannon.ladymon. Thanks for asking!
Firstly, there’s not a right/wrong here, so I just want to be clear on that up front.
I’ll try and explain my reasoning. This is one of those things that’s not necessarily obvious even in some ways to me, but it’s been honed into me over years of experience, and it feels instinctively very natural to update at the beginning and much less natural to update afterwards. Reading it back afterwards, really this is the first time I’ve ever thought about a lot of this.
I’m going to be more technical than I would be at this stage with the general cohort, but as you’ve coded a bit before, I hope what I says makes sense.
Firstly, I’m a huge believer in encapsulation and small functional units of code. Most functions I write are 1-5 lines of code (I almost never write more than 10 lines in a function). I think the key to making manageable maintainable software is everything having a very tight purpose. One of the main reasons for that is that the smaller the bits of functionality you’re dealing with, the less you have to hold in your head at once. And the less context you’re loading and unloading, the quicker you can move between things, and then less mentally bogged down you get.
So when I code, generally my first consideration is how to break things into very readable functional chunks, where each chunk in isolation makes sense.
I write code in a very functional manner, but the same principles apply to other code blocks (loops, conditionals, etc). I don’t care too much about having an extra iteration or being maximally efficient. I care most that if someone gives me a piece of code, I can very quickly read it and make sense of it.
So when I’m coding the spouting flower for example, I very much look at a single iteration as its own thing. I mentally remove everything before and after the block, and just load that single iteration into my mind. And then I play out that code mentally. And for me, the process of setting everything to the correct values then drawing works perfectly for that single iteration. All I’m caring about is what is happening right there and then in between that do and that end on this one occasion. If something doesn’t work, the answer is in that iteration.
Now imagine the other way, where I draw first then change variables. I’m now no-longer able to think in terms of one iteration. I firstly have to think about what happened in the previous iteration to be able to work where things will draw. Then I need to think about the next iteration to work out where things will go next. So mentally, I’m loading 3 times as much data into my mind, even though the lines of code are the same. That feels exhausting to me and makes debugging much harder. If I change something now in that code, it changes the past, the present, and the future. Whereas before it only really changed the present.
Now, I’m sure another developer might find this all very fuzzy and weak. But in my experience, I’m very very fast at debugging code. And I think that is largely down to these small design decisions that massively reduce my cognitive load as I’m problem-solving. i always optimise to enjoy the code I’m writing and reading, and to make things as simple as possible. And these small things add up to achieve that.
In my experience, it’s really rare in reality to ever go through this process of setting some variables then changing them straight away, so the process is a little artificial I think (I can’t remember a time doing something like this recently as once you move into more advanced techniques and have more encapsulation, you’re not really passing loads of variables around). So the slight annoyance of doing it here is something I’m ok with. Especially because the “setting all the variables” is another single codeblock that I can hold in my mind in relative isolation.
I hope that makes sense and is some way useful 
