Once upon a time, I studied chemistry. When you mix clear liquids that all look like each other and their exact temperature and precise quantity directly impacts results, you quickly learn the value of laboratory notes. So that's what I do with programming now: I do my thinking on paper.

I write what I want do to, why I want to do it and my hypothesis on how I want to solve it. I call each of these my "experiments". I then chronologically describe what I am doing, referring to the sections mentioned above to keep myself on track. If new ideas come, I write them down but pursue them only if they are aligned enough with the goal, otherwise they are postponed.

Sometimes, you discover that your goal is bad or that some prerequisite is necessary. I then stop or cancel the experiment and start a new one. By doing so, I get a lot of structure in the way I do things. The produced programs usually reflect that.

Writing down the encountered problems and having proof black on white of what I already have tried and if it was successful is worth its digital weight in gold as well. If only for the emotional relief of venting on a page along with the problem's description.

Also later on, when an issue with the program pops up, I can usually go back to why things are the way they are. The notes read mostly like the ramblings of a crazy person, but they prove terribly useful to me nonetheless. Especially now with LLMs able to summarize and link to them in a couple seconds. I don't know if it's for everyone, but I recommend trying it out. It made my life much simpler.

I may not be the best reference, but I've found a good approach with programming: always have one to three problematic areas until the program is finished.

Trying to improve your code before writing it makes you inefficient, and often you have to remove that work anyway when something about the design inevitably changes. However, if you're constantly growing in code debt then you'll need to go back anyway, so that's also inefficient.

When your areas of gross-ness are in the single digits, you're iterating quickly but keeping the mess at a managable scale. I hope that makes sense haha

I try not think too much. Observing is the important factor for me. And when doing things, not only on computer, but also building stuff... I try to go with the flow, use what is available and at hand. Getting relaxed and focused, then inspiration kicks in.

What i noticed with computers: in last period some people asked me for help with the computer or the phone... And i saw that i cant help a lot if were working on for example windows (didnt use windows for years...) and also smart phones (i just started regularly using it). I keep away from g**gle and faceb**k. So im not a good help to people that are caught in this tools.

What i try is, to subtly present them the gemini and free options available... but when i make web pages, i try to think as the user, think of what client he uses, which tools are available to us?

~bartender black tea for me pleas.

Then is the question also if im working in a team or on my own. Depends of the team members how quick we can do stuff and how much we are able simultaneously do things without a big plan... But more people are involved usually more planing is needed.

Don't think. Just do it. And do it properly!