When I first studied programming (C/C++, many years ago) I would be proud when I managed to finally get a working solution built with all sorts of conditionals, nested loops, and Byzantine expressions in the code.
Look at how mind-boggling complex it is!
Look at how hard it is to understand!
Look at all those unintuitive named variables, nested conditionals and recursive functions!
Look at how clever I must be to have written such a complex, hard-to-understand code!
Now, I see this code and recoil in horror.
Look at how mind-boggling complex it is!
Look at how hard it is to understand!
Look at how foolish I must be to have written such a complex, hard-to-understand code, full of unintuitive named variables, nested conditionals and recursive functions! This will be impossible to read, understand and work with.
The first question you should constantly be asking yourself to keep your work on track is:
Is this thing as simple as possible?
Imagine being asked to make a film that's a thriller.
Christopher Nolan makes "Tenet".
The Protagonist is going all over the planet, backwards and forwards in time, meeting himself but himself going backwards in time, cars going backwards and forwards in time on the same road, bullets flying back out of walls, etc.
Nolan, and about 2 other people on Earth understand what Tenet's about.
Someone else makes... "No Time To Die".
James Bond's family are held hostage by a baddie.
Bond rescues his family and takes revenge on the baddie (contains spoilers).
Everyone understands No Time To Die.
Now you're asked to write a sequel. You've got 2 weeks to do it. AND the original writer is no longer on the team.
What film's screenplay would you rather work with?
No Time To Die, of course.
I still see this in other forms even with more experienced engineers. While they might not write esoteric deeply nested conditionals and recursive functions etc, they know the code should be as easy to understand as possible, but they still manage to add unnecessary complexity.
Why just have a single, regular class, when you can have:
an abstract class, an interface, the class that actually does something and dependency injection?
Why create one microservice that has a clear logical boundary and a single responsibility, when you can break it into two, or even three, microservices?
Do everyone a favour. Keep it as simple as possible.
The other question you should constantly be asking yourself can help you get out of a rabbit hole when you end up going so deep on a problem that you can't give up on.
Your head is spinning with wild optimism, "I am so close, if I can just nail this final bit issue, I will have found the solution." But often in these cases, you find yourself straying off course, way beyond what your team/ project manager wanted you do to. It's your responsibility to avoid wastefully going off piste and bring your focus back to what's important. You can do this by constantly asking yourself:
How does this benefit the end user?
This should be your guiding star. It will guide you out of spiralling rabbit holes, guide you to push back against non-valuable feature requests, and guide you through the noise of "look at this cool new tech!" distractions.
If you constantly ask yourself, and others in your team:
Is this thing as simple as possible? How does this benefit the end user?
You will find that you will be writing code that is easy for other engineers to read, understand and work with, code that creates features focused on the benefit of your end users.