Time for a little humor. :-) I thought I was the only one, but apparently there are more like me. As its not just me, I'm defining a new disease that is rare, but does effect some PHP programmers. Cranky Ol' PHP'er Syndrome, or COPS.
Symptoms include consistently throwing out all but fringe tools when you start a new project. I consider Phing, SimpleTest, and PHPT to be "fringe" because hardly anyone uses them within the community. Generally, sufferers have been in the PHP community for awhile, but have ample exposure to other languages. Exposure to the other languages seems to be a trigger for this disease, but its not yet known if it is the cause.
General symptoms include heckling of "experts" in public places; general dislike of any code written by "monkeys" (i.e., code not written by yourself or someone who shares your disease); or a lot of unfinished projects since every one you start requires you writing all of the tools around it from scratch.
Two other common early warning signs are purchases of books or perusal of websites of other languages. As stated above, exposure to other programming languages appears to be a trigger. If you've been programming longer than PHP has been around, you may have be a carrier for COPS and not even realize it. Avoiding use of languages used prior to starting PHP may be enough to manage your disease. If you started programming with PHP, be careful when exposing yourself to new languages. Exposure to 1.2 - 1.4 new languages per 12 month rolling period is generally acceptable, but exposure any higher than 1.5 new languages puts you at severe risk. Exposure to other dynamic languages should be avoided at all costs as it leads to feature-lust, a retrovirus that has been linked to COPS.
Unfortunately, there is no known cure. Sufferers of COPS have been known to start other projects to try to rid themselves of excessive crankiness. Forking existing projects is generally not advised, as legacy code is a known contributor to COPS. Unsubscribing from mailing lists has also been known to help. For those, such as myself, who can't bring themselves to do that, liberal use of "mark all as read" has also helped in some studies.
In the some cases, using Java for extended periods (also known as Java-therapy) has helped, but in the most severe cases, using Java can cause even further COPS symptoms. If you feel you are suffering from COPS, avoid Jython and JRuby at all costs, as exposure to them may make the symptoms worse.
Avoid using fully integrated development environments as well, and revert to a plain text editor. If this does not work, using command scripts such as echo, cat, and sed may be necessary to help reconnect you with your primal programmer.
In the most severe cases, using a red marker to desecrate books such as Design Patterns, Patterns of Enterprise Application Architecture, and Refactoring have helped. (Note: please avoid libraries while undergoing this treatment)
This disease, though chronic, is not fatal. Many have sought treatment, while some have embraced it as a new way of life. A select few have gone so far as to join religious sects and try to convert fellow PHP programmers. Others who have chosen not to seek treatment and instead taken up the roll of "fool on the hill", silently observing the community.
I'm coining a new phrase. Expertise Syndrome.
expertise syndrome (n):
- becoming so skilled in a given topic, methodology, etc., that you can't discuss it with someone who is lesser skilled than yourself as you leave out significant parts by deeming them "common knowledge".
- when knowledge within a community becomes "common knowledge" and is no longer discussed at which point new comers often find it hard to find basic information.
The seeds of this started last summer when Paul M. Jones posted TDD, Test-First, and Ravioli Code. Paul is a really smart guy, but somehow he missed (and he still does) the point of TDD. The only explanation I can come up with for this is that we, the TDD community inside PHP, haven't properly conveyed our message of peace, harmony, and code with fewer bugs and programmers with fewer white hairs since they we're validating our work as we go in the form of executable specifications.
We had apparently left out a key part of our case: namely that unit tests provide us with a way to manage the inevitable change that comes with software by ensuring that the entire system is properly exercised in a repeatable way. Write a test, make it pass, then move on to the next task. Then, once you start to see how things interact, you start refactoring. You already have your expected outcome being verified by the tests. Now all that's left to do is incrementally add new tests to verify the new functionality you add in and refactor the existing code. Your tests serve as the stutter bumps on the side of the highway, giving you an early warning by failing if things aren't going correctly. On the flip side, they can also be used to track down all of the places in your code that are affected by the change you're making providing the true lazy man's methodology: "oh I'll just change my code for the better and my tests will tell me what I need to fix".
But I digress... I ran into another case of my own expertise syndrome few weeks ago with a colleague of mine. We've started a concerted effort at work to get unit tests implemented around our product and since I'm the resident TDD guru, I got tapped to give a presentation on unit testing. I put together about an hours worth of slides on the basic concepts, determined not to do the standard 2 + 2 test case and show some "real-world" use cases mixed in with a few of the test cases that we already have in our test suite along side the basic syntax and theory someone would need to get started writing test cases.
I gave the presentation I would have loved to have been privy to some 4 or 5 years ago when I started down the TDD path. These guys left the presentation having at least heard of "four phase tests" and "intent revealing names". Based on the feedback I've received and the number of people who are now committing tests, I think it went over well enough and that everyone felt like it was a good use of their time.
A few weeks after the presentation, a new test was committed that broke another, unrelated test. An undefined index error or something similar. I started investigating and within just a few minutes found that one of the super-globals had been set explicitly to an array in the new test case's setup() method. The new value didn't contain the value that should always be there, so the next test case that relied on it failed. Classic case of an interacting test and something I just took for granted and a concept I completely ignored in my presentation.
I found myself doing this again a few months ago when I was working on an article for php|architect on PHPT. I was 3/4th of the way through the article before I realized that I had never explained how to actually run the software. Seriously. I had covered installing it, both from its channel and SVN, how to write the tests, and had started writing how to extend the testing framework before it dawned on me that I'd missed the most crucial part: how to run it.
I experienced this syndrome from the opposite side when I made the switch to Git. There's tons of information, but most people inside that community have apparently been using it long enough that they didn't realize that saying "type git init" wasn't enough to convey that doing so created the repository and stored it in the ".git" directory and that you didn't have to checkout a copy of your repository. I spent an afternoon trying to figure it out. I consider myself a pretty intelligent guy, so heaven help the guy who's only exposure to version control thus far has been TortoiseSVN.
Today I had even further confirmation that this is a real syndrome that we, both individually and collectively contribute to it. I received a message from Paul Greenberg in response to notes on his keynote at SugarCon. He specifically addressed my criticism that his slides had too much information on them. He said it I might be right, but that he wanted to include it so he could provide all of the information and context whenever he sent his slides to someone. Fair enough, but I would have never thought to do this since I use S5 and it has the concept of a "handout" section that you can stuff in that narrative or contextual information that's normally in your presentation. My guess—and I might be wrong—is that Paul's never heard of S5 and that the ability to provide contextual information along side the slides that is hidden unless you're "reading" the slides (either by printing or turning the slide show off) is something new to him. And I'll bet this isn't the only tool that I take for granted that others might find useful, if only they knew it existed or how to use it.
Battling this disease
There isn't a cure, but I think its symptoms can be managed allowing its sufferers to effectively interact with the plebeians. ... removing tongue from cheek ... As a programmer, one way to hone your "novice thinking skills" is to constantly add new languages to your repertoire. There's no need to become an expert in them, but learn their methods for approaching problems. Try to think in that language. You'll be amazed at how the shift in paradigms will force you to rethink your assumptions. I recently picked up Erlang and the shift to functional from imperative programming was—no, still is disorienting.
Another suggestion is to explore new tools. See if they fit with how you work by committing to using them for a week or two. It doesn't matter what they are. Could be a new version control system, IDE, or finally putting all of your tasks in some sort of task manager. The point is to try to mix it up and keep from getting into a rut. Note that a rhythm and a rut are two completely different things. The former is great and can make you much more productive, the latter will cause you to stagnate.
Constantly approaching something new with curiosity should help keep you in a novice mindset. The next time I'm writing an article or preparing a presentation I'll make sure to keep "why?" close by. Why is this the best practice? Why should I use this pattern over that one? You've gotta love those three little letters.
