I usually dont. The design allows me to foresee its code well enough.
In case I do, I'd stop, go back and make changes to the design on paper, and then get back to writing code.
It's easier to iterate and reason over designs, user journey maps, event storming boards, etc. than over code that has not yet been (or is still being) written. It's very unlikely to think of a significant change after you've started writing code, because by this time you'd have thought through every possibility and narrowed your goal. If you're thinking of changes while you write code, you're probably trying to do too much at once.
There's a lot of acquired intuition involved. If you're new to writing code, know that you too will develop an intuition over time. Don't stop practicing!
The goal however is to get something working, and then iterate.
Nothing can be perfect while it's still incomplete.
So like at least complete one feature first, and then iterate over it.
Do you ever think of changing that design during the coding part? If yes, how do you proceed?
I usually dont. The design allows me to foresee its code well enough.
In case I do, I'd stop, go back and make changes to the design on paper, and then get back to writing code.
It's easier to iterate and reason over designs, user journey maps, event storming boards, etc. than over code that has not yet been (or is still being) written. It's very unlikely to think of a significant change after you've started writing code, because by this time you'd have thought through every possibility and narrowed your goal. If you're thinking of changes while you write code, you're probably trying to do too much at once.
There's a lot of acquired intuition involved. If you're new to writing code, know that you too will develop an intuition over time. Don't stop practicing!
The goal however is to get something working, and then iterate.
Nothing can be perfect while it's still incomplete.
So like at least complete one feature first, and then iterate over it.
Thank you Galdin Raphael 🤩