I thought this followup to the software development philosophy link I recently provided was particularly good.
Like the author, I was also exposed fairly early to "Worse is Better", and although I never really took a strong stance on it either way (probably consistent with my moderate stances), it deeply affected how I framed the issue in my head. I also read and enjoyed 「The Unix Hater's Handbook」, reading it mainly as a semi-affectionate parody of Unix and its culture rather than a serious criticism.
I don't consistently believe in neatness or design to their fullest extent; my interests in programming are expressiveness and helpful tools to do what seems best at the time, and while I don't like being forced to be neat, I generally like to be as neat as it makes sense to be given immediate needs. As for Unix, I like it. It's not the best OS imaginable (and if Plan9 had caught on and been a bit less dorky, I would be a Plan9 user today), and there are things I like better about other OS's, but given all my preferences/needs, Linux and other traditional Unices make the best home for me by far. I might even accept most of the criticisms of Hater's as valid, but remain unconvinced. There is a reasonable chance that in the future I will become a FreeBSD user if the mainstream Linux distros keep moving in bad directions (like ditching X). I'm ok with that.
What I pull out of both essays is a distinction between pragmatism and idealism. I believe in both evolution and planning when it comes to programming; I'll think about the software design to get a feel for what the hard bits are, implement part of it, and design other bits as I go, feeling out the problem. And sometimes if I foresee problems I'll stop and think for a bit. If I dive right in I'll still stub things out and try to start on either the most toplevel bit of code or the most structure-defining part (not always the same thing). I'll also change my design while coding it if that seems to make sense. This way of programming isn't described well as an opposition or fetishisation of planning, and I would be happiest developing with people who share this view, rather than either the person who plans everything before writing a bit of code or the person who is deeply opposed to dealing with problems until they have to. And depending on the project I might plan more or less beforehand.