There's a lot of discussions about what exactly is good code.
Some might say that good code is code that gets the job done, and they would be right. Others might say that the code is good when it is simple and expressive, and they too, would be right. But no matter what good code really is, they all come from a single place:
One problem that concerns all of us when we're coding, being us juniors or samurai-viking-ninjas, is if what we're writting "is good". It is a good thing to think, but we have to keep a clear focus on what it must be done first before all else:
Make it work.
Sometimes, in the ferverish desire to write code so good that we would hang it in our walls, we struggle and feel overwhelmed by the difficulty of the task before us, and more often then not, we give up. We forget that what we're ultimately writing is software. Code is just our tool. It doesn't matter how good my little piece of text looks: if the sofware doesn't work, it's crap.
Now, bear with me for a moment. I'm not saying that we shouldn't focus on quality or anything like that. What I'm trying to say is that we have to have in mind that we should approach our code just as we approach our software, through small iterations of value delivering work.
Hell, the whole proccess of TDD revolves around that:
Just keep in mind that everyone writtes crappy code, even your programmer hero. And we should, anyways. Writing a working software demands it's fair share of crappy code once in a while, and it's part of our growth as programmers to learn how to find them and make them better. How to make them good.
But first, it will be bad. Don't mind it, you can make it better. You will make it better. But first of all, do it.