Part VII: Final Projects

The final part of the book is where you step up to more advanced projects and try to nail down your personal process. These projects are a mix of difficulties, but they should help you formalize your process and figure out what is working well for you. The most important thing is that you should be on the path to analyzing how you work and what is best for you. Maybe you didn't do everything I suggest in this book regarding personal development, but I hope you continue to pick this book apart and find ways to analyze yourself. Doing this will give you an effective way to grow and improve as a programmer.

We should review what you've learned so far since you'll be asked to apply as much of it as you can:

• Part II you learned how to get hacking and how to make your start as smooth as possible.

• Part III you learned about data structures and algorithms, but also learned how to focus on quality and write good tests.

• Part IV you applied your testing and quality skills to projects focusing on Test Driven Development and auditing.

• Part V you learned about parsing, but also about measuring your quality as you work and writing effective tests.

• Part VI you studied SQL databases and learned a new process for analyzing data and structuring it well.

Part VII you will apply everything to a set of projects, making sure to focus on the three areas of improvement:

• Process by attempting to define your process and sticking to it.

• Quality by focusing on automated testing, testing tools, and tracking your quality progress.

• Creativity by trying to solve that are not too well defined and starting off with some loose fun hacking.

What Is Your Process?

For this entire book I have dictated to you what process tools I want you to use. Each section I gave you a different challenge that focused on process, quality, or creativity and then gave you exercises to work on them. You've been tracking your quality and looking at graphs of what's working for you and what isn't. Now it's time for you to develop your own process for completing a project and then apply it to the projects in this section of the book.

Take the time to come up with your process theme. Is it hacking then TDD? Is it straight TDD all the time and lots of auditing? Is it just hacking and auditing? I don't mean to pick just 2 things, but you should think out your theme. Think of it as your personal style choice. I happen to like hats and red shirts. Don't ask me why, I just like them. That's what this process description is for you. It's your polka dot dresses and yellow shoes on a summer day. In programming I generally follow the theme of, "hack, refine, test, break".

Once you have your simple theme statement, it's time to work out your steps for this theme. Write them down on a card so you can follow along with them, and I'll warn you that simpler is much better than complex. Complex processes are difficult to work on. Your process should also hit creativity and quality. My process is different for different projects, but I've taught you all of them throughout this book. Use what I've taught you so far to come up with your own.

Once you have your process laid out, go back through your notes and see if you can find metrics to justify what you've chosen. Maybe you've chosen TDD because it made you feel like you were writing more solid code, but then your quality metrics in Part V weren't really all that good. There's something to be said for using a process you like, but if the process you like isn't working it's time to toss it in the recycle bin.

With your process figured out, it's time to work on some projects to test it out. Don't be afraid to be wrong. Sometimes we think something we've decided is the best thing ever, and then the heat of battle melts it like an atom bomb. This is a science experiment for you, so if something is a total disaster then use your tracking and metrics to find out why and simply regroup to try again.