I read this article by Addy Osmani a while back that was in response to the "How It Feels to Learn JavaScript in 2016" post. For those who haven't read it, the essence of the article boiled down to this:
First do it, then do it right, then do it better.
Sounds like a great motto to follow by yes? Well, while I agreed with it whole-heartedly when I read it, recent events have shown me that I clearly hadn't put it into practice yet. In fact, for whatever reason, I took it as great advice for people starting out in the field while completely missing the fact that it was a commentary on learning as a whole.
I don't know about the rest of you, but I often find myself getting lost in my head whenever I try to build things. If we were to use the analogy of the dreaded whiteboard exercise during a job interview, it's the equivalent of me staring silently as I try to devise the "perfect" solution to the question I'm provided. And as most of you know, this is one of the worst things you can do.
Now, there are probably numerous things for why this keeps happening to me (e.g., some degree of perfectionism combined with a subconscious desire to be more clever than necessary). However, the core issue boils down to this: I keep trying to do things as elegantly as possible the first time around. It's as if I was playing a game of go and I'm trying to figure out the best move possible because there are no undos in a proper game of go.
Of course, this is utterly ridiculous because there are plenty of opportunities to change your mind when coding. And returning to the whiteboard exercise analogy, the correct strategy is to start out by sketching out a basic solution and then talk your way through it as you change / improve it as you go. After all, it's not as if we're writing our code with typewriters and can never get a chance to try again.
The reality is that your initial solution is going to be flawed and ugly (i.e., not the most concise or elegant way the code could be written). Yes, I know, that sounds horrifying; but I assure you that it is perfectly fine. The key thing to focus on here is to get something working. Once the MVP is up and running, you can happily iterate to your hearts content knowing that your solution is getting better with each cycle.
At the end of day, I can assure you this much: no matter how clunky your prototype is, it beats going home empty-handed because you got stuck in your head.