In previous posts, I’ve talked about the idea of focusing on an area and going deep rather than wide. This is personal preference, of course, but it’s mine, nonetheless.
Over the last year, though, one of the byproducts that I’ve found is the longer you stay in a given industry, the more common certain problems become. (This shouldn’t come as a surprise as this is precisely why we have design patterns.)
But the thing about doing this is that you develop a sort of tunnel vision for ways to solve problems.
Case in point: Recently, I was tasked with needing to develop some functionality that was going to parse markup and convert it into a slightly different format.
Development Tunnel Vision
I’ve done this time and time again and I’ve often found DOMDocument to be one of the most helpful utilities at doing this. But there’s a problem: I’d gotten so used to using this that I was neglecting alternative solutions that were not built into WordPress, but into PHP.
Rather than needing to load the entire document into an instance of DOMDocument, I could to string replacements using – no, not regular expressions (though that was tempting) – but strip_tags and str_replace.
Taking this a step further, this is something that was pointed out by a well-respected colleague during a code review.
On Code Reviews, Again
I’ve also spent previous posts talking about code reviews, why I think they are important, how to handle them, and how to avoid staying attached to them.
But it was a nice reminder to find to find that even when you think you’re used to solving a common problem in a given situation, there still may be a different, a cleaner, and/or a better way to do it.
My point being is that no matter which side of the code review you’re on and no matter how long you’ve been doing whatever it is that you’re doing, don’t dismiss a critique because it’s different.
If anything, it keeps you from developing development tunnel vision; it keeps your mind wired to think more broadly about a problem no matter how often you’ve solved it.
