My standard for writing "good' code is...
- can my team read & understand it now
- would my team likely be able to read & understand it later
Earlier I wasted a lot of time trying to impress people with clean code, only to later learn those people were never going to care. Now I'm more in the camp of getting it done, which is a heck of a lot easier when you work on a team, and at a company, that shares enough of my values. Getting hung up on "what is good?" is a waste of time, because everyone cares about different things. When you ship stuff, the people who don't care don't speak up don't, and the people who do care do. When the people who care speak up, that's when you have an opportunity to learn what is important to them.
Don't write complete crap, and don't try to make everything. Just try to be productive and not ridiculous, what that means will vary from project to project.
Your polished diamond is someone else's stinky turd, and vice versa. For example, I initially learned to write code while hanging out with people who really valued testing everything and aggressive decomposition (e.g. a line of code should only do one thing). I wrote code like that on a new job, and the team hated the number of classes and functions I was asking them to read in a code review.