I've got a few pieces of advice for you to consider. I'm not sure what will work for you so I'll hit a few broad areas.
One thing is to make FIXMEs, TODO lists, and otherwise write down the areas that might need improvement, so that you can mentally dismiss them and focus on your immediate needs.
When I'm making something new I do "modal programming". Turn off the IDE's auto-compilation (so that you aren't distracted by syntax errors) and write large chunks of code in a single go. If you don't know the API for something, make it up. This is the creative mode.
Once the code is written, switch to the debugging mode. This is where you try and get the code to actually run. I've found that by separating the two activities I don't need as much mental effort and it reduces the total amount of time spent or research required.
Back when I participated in collegiate programming contests we'd prepare for weeks by drilling on very similar problems so that I/O and syntax wouldn't trip us up and we could focus on what made the problem unique.
To apply that approach to hackathons, I'd practice the zero-to-prototype step beforehand until you don't have to do a lot of research in order to get a minimal working program. For example, if you normally create android apps, make sure you can get from nothing to a working tic-tac-toe in an hour.
One thing is to make FIXMEs, TODO lists, and otherwise write down the areas that might need improvement, so that you can mentally dismiss them and focus on your immediate needs.
When I'm making something new I do "modal programming". Turn off the IDE's auto-compilation (so that you aren't distracted by syntax errors) and write large chunks of code in a single go. If you don't know the API for something, make it up. This is the creative mode.
Once the code is written, switch to the debugging mode. This is where you try and get the code to actually run. I've found that by separating the two activities I don't need as much mental effort and it reduces the total amount of time spent or research required.
Back when I participated in collegiate programming contests we'd prepare for weeks by drilling on very similar problems so that I/O and syntax wouldn't trip us up and we could focus on what made the problem unique.
To apply that approach to hackathons, I'd practice the zero-to-prototype step beforehand until you don't have to do a lot of research in order to get a minimal working program. For example, if you normally create android apps, make sure you can get from nothing to a working tic-tac-toe in an hour.