Humans are idea machines. Some of these are good, others bad, but we're constantly in a state of ideation.
Software engineering requires constant iteration. It's safe to assume the first implementation won't be the last, and that's normal. It's a results-driven field where often times we don't see the solution until it's complete, tested, QAed, and deployed.
This can get in our heads - it's difficult to see peers shipping code while we're struggling to solve a problem.
I've grappled with this a lot in the past, and the way I adjusted my minset was to allow myself to create junk.
Start your task in draft mode
Can you remember a time your first attempt to solve a problem actually worked?
Neither can I.
Writers often talk about their creative process in two phases. They first start a piece of work as a draft, focusing on maximum output with little to no thought on grammar, structure, flow. Once there's enough content they change to edit mode and clean up their work.
Applying this workflow to software engineering works surprisingly well. In this lens there is no way to fail or not solve a problem.
You're simply iterating on an idea with no weight on the outcome.
Get into a rhythm
The best way to start is just to start.
This is so simple that it's actually quite difficult.
Before I started putting myself into draft mode, I would only commit to going deep on a solution if I saw a path to success. This is a losing mindset. You're not allowing yourself to get into a state of flow.
Write that first test, function, line of documentation.
Our best work comes when we're running on auto-pilot, allowing intuition to guide execution.