How I Write Code. And debugging. Sigh.

So, there are tons of things talking about all of the different kinds of code writers out there. I'm not sure what kind I am, but I'll take you on a brief overview of how I do stuff:

1) Identify the problem.

• This one is a rather obvious step. If you don't know what the problem is, then you can't figure out how to fix it.

2) Write down what I think might fix the problem.

• This can be as simple as a formula or as complex as...well....me writing a whole bunch of stuff. This step is important though, because it allows me to think through the problem. I usually don't identify everything that is going to be a problem during this step, but it helps avoid a bunch of simple stuff.

3) Rough draft of the program.

• I just start writing. It's messy, ugly, and inefficient. But it lets me actually do some work on it. I can see what's going to work, what isn't, and what I need to rethink. 

4) Rethinking

• Generally the longest step. This step includes going through my rough draft and figuring out how to fix problems, redesigning the program based off of my new ideas, and then trying to make it better.
• This step is where the majority of the work should be put in, unless you're just good enough to not need the rough draft. If you're able to predict all of the problems and optimize your code without the rough draft step, then step two is where the majority of your work needs to go. If you're a mortal and need a rough draft though, you'll need to rethink. If you rethink it well enough, you shouldn't have a problem with making the program "pretty."

5) Pretty Code!

• This is where you do the final draft of your program. This means that the code is as good as you can get it. Everything is neat, clean, and well put together.

6) Debugging

• Even if you put a week's worth of thought into your program, if it's anything bigger than "Hello World" then you're probably going to have a couple of errors. They'll be fixed in this step.
• Up in step four, I said "generally the longest step." The generally is there because debugging can take a LONG time. It doesn't always take a long time, and really well designed code doesn't take much at all, but it can take weeks. To fix one problem.
• PRO TIP: Someone else who is competent with coding will catch the errors a whole lot better than you. Your eyes know what they're looking at and believe everything is right. A friend's eyes don't know why the heck you declared a function as void and are trying to return an integer.

That's just how I do it. It might not be the best way, but it generally works.