Rarely do I post what I would call "opinion pieces" (that is not to say my average post is not littered with opinionated statements), though I occasionally read some while trolling through tech and PHP related news and blogs. While doing so recently I came across an article with a title similar to "40 things bad PHP programmers do".  As I scanned the list I thought the ideas where all valid, if not a bit over zealously stated in an effort to make the point. This and a recent job interview (in which I did not get the job) got me thinking again about something I have pondered for a long time: How does a programmer balance practical limitations with best practices that can be difficult and time consuming to adhere to?

    During this recent job interview I was asked "do you know what unit testing is and do you use it in your projects?". My response was that yes I knew what it was and no I did no use it in my projects. From the look I got, sort of an "Ah I see, you are one of those programmers" look, I am guessing that was the wrong answer. It was almost as if I had crossed a personal belief of the interviewer, one he held to be very important while at the same time not allowing himself to emotionally react except for a strange twinkling in his eyes that said to me "you are a dolt". Ok, maybe thats crazy but that is the way it made me feel. Upon further exposure to unit testing my opinion remains unchanged. I see the point, I understand the process, and I still don't see it applying to the software I write in such a way as to decrease bugs or increase productivity. To me unit testing comes down to saying "this code works like the reference code" and I just can't seem to find that a compelling enough reason to use it. Maybe that makes me a bad programmer or an arrogant jackass. it was on the PHP no-no blog post as well, but of course not using the blog authors preferred IDE also made you a bad programmer, so take that for what it's worth.

    Best practices in the PHP space are always shifting. These days the word is "external templates are bad! Use PHP for templates!". This is a far cry from the best practice for presentation separation in the not so distant past in which the consensus was that you were stupid if you did not use Smarty or some other external template package. In my work as a contract programmer I am faced with a myriad of job requirements. Sometimes building massive sites from the ground up, sometimes adding functionality to an existing site, sometimes digging into an existing code base for a quick one line fixer-upper. My goal is to provide a quality service, and to do so I employ the best practices available when considering the clients needs and my own coding standards. Linus Torvalds once said in regard to software development "Perfect is the enemy of good".  Attempting to encompass all the trendy best practices in the PHP world into all the code you produce is impractical, and even software that does make coders drool over design patterns and MVC separation techniques can turn out to be utter crap. Good production quality software is a lot more useful than unreleased software stuck in perpetual development in search of perfection.

    By no means am I suggesting that one should not listen to and consider solid methodology or new ideas. Nor do I consider it appropriate to settle for "good enough". But I do think it's ok to build practical solutions that meet the job requirements even if you have to skip a few of this weeks best practices to do so. Being open minded regarding the advice of experts is common sense.  Blindly following and supporting the latest methodology simply because so-and-so said it on their blog is really just an excuse not to think for yourself. Pundits will surely continue to issue decrees from the ivory tower penthouse of software design to the teeming inexperienced masses below. Somewhere midway down the tower you can find me writing software in a makeshift porch of my own design.