Blog
Ibuildings Blog
 |
Ibuildings |
Friday, September 11. 2009Oh Be Careful Little Eyes What You See
The children's Bible song starts off with the line "Oh be careful little eyes what you see". Regardless of whether you agree with the religious doctrine behind the song, the advice from the first line is, none-the-less, applicable to the PHP community these days.
The web has made it easy for anyone to become an instant pundit, regardless of their background. The tools exist so that anyone can quickly and easily publish anything and call it a fact. Nowhere is this problem more visible than in the software development community at large and the PHP community in specific. A quick google or bing these days will show you millions of blogs, tutorials and advice columns purporting to show you the best way to write PHP. Unfortunately, much of the advice offered falls somewhere between misleading and flat out wrong. I won't link to any specific blogs or tutorials but recently I've read no less than 3 tutorials that have left me scratching my head thinking "really?" It's not that the author specifically set out to deceive (at least in these three cases) but that they offered up advice they were clearly unqualified to offer. In the not too distant past, we've seen these play out publicly and as painful as it is to watch, it is necessary.
However, more times than not, technical articles go unchallenged. We as a community must do two things to help not only ourselves but also to improve the quality of the on-line help available. First, we must help vet technical articles and take the time to post a comment when they are wrong. I was only half joking when I tweeted a few months ago: "Blogging about programming is like playing Clue; you say something and wait for someone to prove you wrong." We can all give each other the benefit of the doubt when something is technically inaccurate. In most cases, a polite comment explaining the error in a friendly manner is all that is needed. When companies or individuals who should know better or research their subjects better post such errors, a stronger but still polite note is usually all that is needed. Most of the time, it is not necessary to resort to hyperbole or name calling. The second thing we can do is make sure we only pass along quality advice. Just because it's from a popular source does not mean it's technically sound. When you are passing on a link, whether on twitter, irc, email or your own blog, make sure that you have read it, understand it, and can vouch that it's technically sound. No one wins when bad advice propagates throughout the community. Help others and yourself by promoting quality technical content. Don't pass along a URL just because someone passed it to you. Read it, make sure you understand it, and most importantly, make sure it is technically sound advice that adheres to current best practices. You don't get points for passing on a technically inaccurate article just because someone cool tweeted it first. Share         Comments
Display comments as
(Linear | Threaded)
How many of us will take the time to review every URL you pass around? I doubt not many. But yes, when you spot articles wrong, a polite and positive feedback comment helps everyone.
i totally agree there is a lot of noise that does more harm than good so i try to stick to books. At least you know someone put some real effort to it :- )
But on the other hand its still good to be able to find stuff online for free. Like myself ... if i ever find time to write some lousy post on my site its never really good as i have no time to polish it up  Unfortunately, you have ruined the article with your last sentence! Does everything online have to evolve around tweeter?! heheh Tweeter is whack!!! : -)
Yes, but...
We've all seen a lot of books, even from long-published authors, that have been (at best) hurriedly thrown together. Although I am working on a book myself, I much prefer non-dead-tree media - blogs, Wikis, IRC, mailing lists (generally in that order). They offer something that no printed book really can - the functional equivalent of a conversation. But that in itself depends on active participation - if a blogger writes a hundred posts, is read by a couple of thousand people, but gets only a handful of comments on what he has written, then nobody benefits. For a blog or a Wiki to only have a single author defeats the entire purpose. The writer is not perfect, he makes mistakes, but he never gets them pointed out, so never learns to improve his craft. His positive points never receive any reinforcement; never is there the bright exchange of ideas that perhaps leads off in a different direction entirely, but generates illumination and interest all the same. The promise of the Web, and later of blogs, was to make "every thinker a writer, every thinker a teacher"; by allowing the media to become passive rather than collaborative, we are doing ourselves and the societies in which we live, off-line and on, a grave disservice. I challenge everyone reading this to make a commitment to themselves: to read a wider variety of sources, and to thoughtfully engage in comment and conversation regularly. If everyone made one such comment or post for every five, every three, that they read, the Net would be a much more vibrant and interesting place. "If not us, who? If not now, when?"
One might also add that being combative in replies as step one (insulting the author, for example) isn't the best way to get your point across. I was in a position earlier this year where I posted a question and was a bit sarcastic in my post. I received a number of insulting replies, few of which actually had any substance or response to my original question, and most of which simply wanted to join on the bandwagon of insulting me. This furthered my view (and the view of some of my colleagues) that many in the PHP community don't really know what they're talking about. A great deal do, but given the size of the PHP community itself, even a small percentage of trash talkers turns out to be a very large number.
On a separate note, I was at the bookstore the other day and thumbed through a couple of the newer PHP books (one was a PHP6 book - heh). These books are still demonstrating stuff like $conn = mysql_connect() or die("can't connect"); With no mention in the book's examples of PDO or abstraction layers. It's 2009 and the majority of the printed publications out there are churning out 1997-level code examples when it comes to the database. Why is this? This lack of progress from traditional publishing houses perpetuates bad practices which infect current and future generations of developers.
Cal,
I agree wholeheartedly with your article. I have seen many PHP articles that have incorrect, contradictory or outdated content even from authors who are supposed to (based on their 'background') know better. It would be just lovely if more learned members of the PHP community took the time out to comment on and offer up corrections to flawed PHP related content they come across on the web. Don't look at it as 'not being your problem' but rather as a duty to play your part (tiny though it may be) in ensuring the correct dissemination of information. On another note, one of the hallmarks of our field is perpetual change. This makes it a little more difficult to have information stay accurate for a very long time. For arguments sake, a best practice article published maybe 3 months ago may no longer contain 'best' practices as PHP 5.3 has been released and possesses certain features (namespace support, etc) that will essentially change the way we write code. In essence then, similarly to how we refactor our code, authors of technical articles and blog posts should consider 'refactoring' their articles from time to time. - Sam
I couldn't agree more with the sentiments expressed here.
How many times have we all come across mistakes or made our own, whether the unintentionally, or from ill-informed information and then seen a torrent of abuse ensue. This sort of behaviour doesn't help anyone and simply wastes time. Unfortunately, it has been going on for too many years and is not unique to the PHP community. Having said that, to see it continue in the community, is agreeably not a good thing, nor is it in any way productive or conducive to further community growth and reputation. There should be active encouragement of constructive feedback and criticism. Additionally, if the author, time-allowing can revisit the article(s) from time to time and make updates if required, will help to further build reliable and truly informative content (Samuel Folkes). What about the possibility of having a PHP-verified stamp/logo? I'm not sure of the logistics of it, but something that clearly conveys quality and expert content that the community and the wider world can come to know means that this is a trusted source of information. Suggestions? |
