Member-only story
Why You Should Make Your Code as Simple as Possible
You’ll program faster if you try to make your code simple, even repetitive, when you first write it
Programming is a lot like writing — you should start with a “bad first draft” that solves the problem, then immediately edit it two or three times before you move on to the next problem.
Engineers scoff at being compared to measly “writers” — but who wrote the documentation that you used earlier today? And don’t you “write code?”
Software developers have the luxury of working in the most creative type of engineering. After all, software engineers get to call a lot more shots when building an app than civil engineers do when building a bridge.
Working in a creative profession means that you can learn a great deal from writers whose words will never execute. And one of the best pieces of writing advice is something typically recommended to solve writer’s block.
Let me introduce you to the “bad first draft” — because it will make you a much faster coder than ever before.
The “Bad First Draft” Method
The idea of a “bad first draft” is so commonplace that you’ve probably heard about it at some point in an English class even if you’ve never gone down the rabbit hole of internet bloggers offering tips about writer’s block.
The idea of a “bad first draft” is that you just need to finish the first draft even if it completely sucks — because any first draft is better than a blank page.
Editing your own work is easier than writing from scratch, so you need to try to write something (anything!), right now. Just make the code work.
To put it another way, would you rather have written 100 lines of bad code (that works) or zero lines of perfect code by lunch today?
Sure, at the end of the day, you may still end up with 50 lines of perfect code either way. But there’s a psychological advantage to writing a “bad first draft:” you’ll feel more successful with less stress.
You’ll write code and have fun doing it! What beats that?
