Do you plan the application, on which you will be working, before you actually begin to write code?

I do web development and usually begin with something rough or look at designs of other developers. Like an dashboard example, when I see an image on google search that I like, I try to make something simmilar and when I have the surface I can add the functionality and improve the design.

Sometimes I have to make changes in half of the development because at the beginning there was no assumption that there will be a need for a certain functionality or I change a implemented feature to work properly, so I have to refactor something I made as a ground on which other parts will rely, although if I had planed the application in detail, maybe it wouldn't come to such refactoring.

In school we did prototypes, used to draw flowcharts and hold on a precedence diagrams that we made, but now at work when I receive an projekt I just begin to code :-D maybe this should change, how do you do it? If you plan your project, how do you do it?

i generally dont start working until i have a visual/ux design

Let the code do talking for you - even remind you of something you forgot.
Take the most fitting approach: components for separation of concerns, or start with sketch in Figma and extend upon it (not free).
If you've got a business process to describe, best bet is BPMN diagramming (using any bpmn.io-based editors).

Also, one could start with TDD because of the same struggles as yours. It isn't fast at starters, but it's worth it when your application's development jumps into agility.

I list out requirements and functional arrangements, until I like how the backend looks. That's the part that gets my attention. Making it pretty is not my farm.

I put my fingers on the keyboard, get comfortable, take a nap, and my muscle memory writes the code while I sleep.

I started thinking about it just now, and two things popped to my mind right away: I really couldn't say, and it depends.

I think you're wokflow is going to be very different it you're a freelancer, or developing solutions for external clients to being a developer in a company mainly maintaining and improving upon existing products. In the latter case you're definitely bound to certain company policies, e.g. a common UI/UX design framework/palette across products and whatnot, or even just being tied to a certain cloud provider... whereas side projects, again, are a completely different animal.

At work we do kanban, so I basically just pick an issue that's either assigned to me or free for grabs and start working on. I know our products pretty well, so it'd pretty straightforward all in all... with side projects the design phase gets easier project by project. Nowadays I like to draw a picture clear as possible in my head and jot down the specs and reqs as clearly and precisely as possible, so that I can just basically start wherever I need to. I usually write the necessary boilerplate first if I know I need it and then start writing tests and proceed from there. I usually like to go backend first, and work from there, but it depends.

It seems it doesn't really matter how well the app has been planned, however, as brainfarts happen and some things may work differently than anticipated or some specs change or whatever - refactoring seems to me a necessary phase of development. And in the end, I like to clean up any mess that I may have left behind and optimize as much as I can.

@100110111 I have a dedicated cleanupmymess phase that is very refreshing

In the end, there will always be a phase of polishing and fixing up things.

Project planning shouldn't be fixed, as in "only do that and be done".

It's valid to collect things that should be changed / must be changed.

But - finish first if possible.

Stick to the plan - when you realise that some "unknowns" or critical things make the plan unrealistic, it's fine.

Redo the planning based on your new knowledge, communicate that to everyone and it's fine.

TLDR - A plan can be wrong, announcing a new plan is always a last resort.

Otherwise - finish first, collect and fix later, so you don't run in the trap If never finishing

Have to have a plan, otherwise I can’t find the confidence to go on

I design core principles first and that has to be good.