Lately, I have been deliberating on quality vs. speed. Throughout my career, I have worked with developers who basically consider quality to be a programmer's vice, an extravagance only for the navel-gazing idealists. I have also worked with developers who consider all time spent on quality to be of the utmost importance, and that programming for speed is for those lazy and slapdash realists. I recently read Yegge's post Done, and Get's Things Smart, and I think I agree with Yegge on this point, that it is possible to perform fast and with high quality, and like a wandering samurai, that is the path I seek.
There are many facets to this, of course, but I have been playing with this mental model. Specifically, my insight here is a new definition of quality: quality is future speed. In my mind, quality that is not for future speed is an extravagance, something programmers do to entertain themselves, and it is worse than cutting corners in the present, because it sacrifices current work for no future gain. Lately, my personal projects have taken a certain theme: I want more practice tuning my programming to be as fast as possible both for today and for the future. And to be perfectly honest, usually there is a lot more "future" in most systems than just "today". So, how have I been doing this? I set arbitrarily short deadlines for myself, so I am forced to practice dropping anything that is not directly related to speed. I then try to rotate projects every month, so I am forced to return to old work, to learn better where I made bad choices that cost me future speed. Doing this with the right mindset is very humbling, and very insightful. Honestly, this may happen at work accidentally from time to time as well, but rarely at work am I able to carefully reflect on the mistakes of the past. At home, the pain I feel is my own, no one suffers at home other than me, and there is no one to blame but myself. If an architecture is brittle, or the test coverage is low, or the design is resistant to change, (all of which have happened) I am able to take those lessons to heart because I directly caused those problems. I encourage anyone who, like me, seeks to be a more excellent developer, to give this a try: start a couple of side projects (and don't worry, it took me a year to get the ones I have), and set yourself some crazy tight "delivery dates". Heck, make real products and try to make some money off them, maybe you will be able to get some side-cash! But then, after you have "delivered", take some time to rest, maybe read a book or two, tinker with some other projects, and after a break, return to analyze your past work. Set yourself another strict deadline, try to make a second version, or add some more features. You will find some incredibly valuable lessons there.
