Part III: Data Structures

You're well on your way to building a personal process that gets you started quickly and with limited friction. Having a good starting process and developing an ability to simply let go and hack is the foundation of creativity. The creative mindset is one of fluidity and relaxation. If you have friction and frustration getting started, then it's difficult to get into the flow. Learning to "click" your brain into creative loose hacking mode helps you solve problems creatively and be more productive.

There is no point being creative if what you make is junk. At first, yes, obviously, the vast majority of what you make will be junk, but you don't want to make terrible software for the rest of your life. You need to balance the creative hacking mentality with a rigorous quality mentality. I advocate that people switch between modes of creative expression and critical thinking. You get your ideas out and realized by being loose and creative, but then you make them tight and high quality by being critical of your own work.

In Part II you actually did this when you tracked the number of features you could complete in 45 minutes and then tried to find places you could improve your starting process. However, you couldn't hack and analyze your process at the same time because the critical thinking mode is a killer to creativity. This advice spans nearly every creative discipline I know and helps you not get in your own way while you work.

NOTE: Criticism during creation kills your imagination. Creativity without criticism produces nothing but garbage. You need both but not at the same time.

In Part III you'll switch gears to focusing on quality and developing personal processes that increase your quality. To keep things simple I am only going to define quality as this:

A low defect rate and understandable code.

Most programmers are absolutely terrible at both of these. The vast majority of developers consider their work completed when the compiler finishes and that's it. They ran the test suite so it's done! I call this "programmer done," where there is no self-critical evaluation of their own work because they totally trust in their computer to find all the defects. They also seem to never care if anyone else can understand their code, focusing only on whether it worked well enough to satisfy the bare minimum. If you were ever to ask them what their daily defect rate is they'd just glare at you and say that's not important. Code coverage? Bah. Their test suite has 100k lines of code! It must test everything!

To become a better programmer you must begin the brutal work of looking at your own quality metrics and practices. I say this work is brutal because it demonstrates clearly and obviously exactly how bad you are, and that can be tragic for people who blissfully think they're awesome all the time. Those with impostor syndrome will find this quality analysis refreshing because it will give you a decent idea of how well you're doing and a plan to improve.