Write ugly code. Use two-char variable names like
xy, ignore retain cycles, block the main thread.
Let that sink in for a minute.
Code is not an end to itself. I write code to make software, and that software in turn usually solves some more or less urgent problem(s). It seems counterintuitive but the quality of the code I write usually does not make a difference as long as it contributes to solving the problem. Allowing myself to treat code as work in progress, not as something that is ever really finished, has made me both more effectiv and productive.
When Kent Beck formally defined Test Driven Development he made the same statement I made above, although implicitly and with less profanity. In pure TDD, the first phase is to write a new test and make it fail. The second step is to write just enough code to make it pass. Up to this point, shitty code is perfectly acceptable. Step three is what he calls refactoring or the removal of duplication – I just call it cleanup. That's where, after you've clearly grasped the scope of a problem and your way to solve it, you should clean up the mess you made. Apply patterns, give meaningful names to stuff. Of course, the test should continue to pass after your code is cleaned up.
Yes, writing shitty code implies that you have solid tests to make sure your ugly code is doing what it's supposed to. It does not imply using strict TDD. There's no way this is working without tests. There's no way even beautiful code can work without tests.
The desire to write clean, readable, well-documented code right from the start is understandable. I've just noticed that it keeps me from staying focused on the right target. Writing shitty code that contains duplications, hard coded strings etc. allows me to focus 100% on the problem at hand. Everything can and must be fixed and, well, beautified later. It's just not a good first step to start with beauty. Draft, play, explore, undo, delete,
git reset. And write shitty code.
Kudos to @mau888 for suggesting 'ugly' instead of 'shitty' code ;)