I’ve found that over time, my bad code gets better. It started with simple things like not naming my variables a or b. Then it became things like breaking out separate classes sooner and sooner. I could tell by my speed too. Those things that I always used to look up I started to write by memory. Those 3 line if statements became functions. I’m better at understanding how whole programs should be structured and I am better at managing things when they start getting really big.

I think most bad code is written because it’s easier. It’s easier to copy and paste something 3 times than it is to write a loop isn’t it? At least until I want to change it to happen more than 3 times. At that point the bad code isn’t easier any more. How am I supposed to know if the easier code is actually going to make things harder later on? Experience. I won’t know if that shortcut is going to slow me down until I actually try it.

I like to write bad code as a first step. It lets me get a feel for what I’m writing. It’ll show me where the tricky bits are going to be and let’s me get my ideas out quickly. As I find the hard parts, I can go back and rework my solution until it’s better. The less I need to change that quick and dirty code, the better I think I’m doing as a developer.

I’m not trying to say that you should always do things this way, but it seems to be a great way to measure how I’ve grown as a developer. Remember, code quality is highly subjective. What seems beautiful and elegant to me, might look complicated and stupid to you. I read something once that said something like “If you look back at your old code, it should always look bad. If it doesn’t you aren’t learning anything.”