I've been programming for about 17 years and here's what I tell my students:
Every program has 2 goals: To explain to the computer what you want it to do, and to explain to people what you want the computer to do. Good code is readable and correct.
The first time you encounter a problem, your first idea of how to solve it will be awful. This is true no matter how long you spend thinking about it, no matter how much experience you have. The best workflow involves thinking, then coding, then thinking, then throwing away most of your code and doing it better. You can't find the flaws in an implementation while its in your head - you need to see it on the screen before you can fix it. Your second implementation will generally be better. The best code I've written I've iterated on 3-4 times until it looks simple and obvious.
Unit tests will help you iterate - write them before / just after your first attempt at the code. Then when you rewrite the code you'll have confidence that you haven't broken it.
You're not writing poetry. Sometimes your code is hard to read because you're doing a simple thing in a complex way. Other times your code is hard to read because its algorithmically complicated. In the second case, spreading the algorithm out over lots of places will make it almost impossible to understand. So, don't stress out when you can't make your code into a haiku. Sometimes you can't - but you should try anyway.
The best way to learn what good and bad code looks like is to read code. At first, reading code will be harder than writing it. You should do it anyway. Your own code is ok, but other people's code is better. Pick an opensource library you use and try and figure out how you would write it. Then read the code and see how they did it. Their method might be worse than yours. - But remember, their project is successful anyway.