I got such a great response from my previous “worst practices” post (thanks for all the great feedback!) I thought I’d forge on ahead with a few more to add to the list. A few pointed out that most of the recommendations from the first post could apply to just about any language out there – that’s great news to me. That tells me that PHP developers are just like any other developer out there, regardless of the language they “speak”.

On to the next round! Here’s four more “worst practices” that, if you care about being any sort of good developer you’ll avoid like the plague.

Speed is King (except when it’s not)

Everyone wants their applications to perform well. It’s a well known fact that customers are wanting more and more each second and putting up with delays in a web app is almost unacceptable. They want it all and they want it now. Easy, right? All you have to do is make your apps work the best they can and do it as fast as possible. But which way is the fastest? We’re talking speed here, and you should do all you can to get those load times down and the customer satisfaction up. Optimize the hell out of those methods and cache whatever you can. Good planning (see “Unplanification“) from the start can make these kinds of decisions easy and smooth out the wrinkles that might pop up. Be careful, though…keep optimization in mind from the start, but don’t make every decision about shaving those seconds off. This can lead to some pretty bad code if you’re not careful. Good structure and standards should never be ousted by over-optimization. While I’m on the topic, there’s also another so called “silver bullet” that a lot of blogs, tutorials and books set up as a good option for making your site run faster: micro-optimizations. I’m sorry, but most of the things they suggest are really only doing one thing – giving you a false sense that your application will get a huge speed jump from using them. Granted, there are special cases where shaving one billionth of a second off the execution time can be helpful, but in most applications, that’s just not that helpful. If you’re serious about optimizing your applications, look into things like memcache or other caching tools so you don’t have to go all the way out to those databases/resources and pull down that data each time. Your application will thank you for it.

Be a Hermit

Want a quick way to lose interest in a language? Don’t talk to anyone else that uses it. I know, I know – there’s lots of developers out there that have gotten very good at their language of choice, but there comes a point when they come across something even they don’t know. They get stuck on it for hours trying to figure out why changing the value of this one variable is breaking everything. What’re is options? He could keep trying, working for hours, even days on the issue before figuring it out. He could also take a look at the manual and see it shines any light on the problem – but that’s pretty limited. What’s the next step? Something that, sadly, a lot of developers just don’t do – ask! I’m not even talking about real-time communication here, this can even be just hopping on a forum and posting your question. Remember, as much as you’d like to think it, you don’t know everything. There’s going to be issues you come across (sometimes even bugs in PHP itself) that someone else out there has come across in the past. The collective knowledge of the PHP community is so vast that, given the right place and time, I’d dare say that just about any question could be answered. There’s even people out there that are happy to help you figure out the answer even if they haven’t come across it before (bless them)! Trust me, you can only benefit from having more than one developer poking and prodding your code into submission. Forums are just one teeny tiny slice of the pie when it comes to resources for help. There’s even *gasp* “face-to-face” things like IRC, local user groups and conferences where you can hit up other developers for ideas and suggestions. Don’t limit yourself! Use the mass brain power of the community to your advantage….after all, they’ll do the same!

Slight the Newb

When was the last time you talked with someone just starting out with PHP? Last week? Last month? How did you treat them? Were you helpful and did you take the time to look at their application before slapping them with a big, fat RTFM about their problem. Don’t forget – you were a newbie once too. Have I made you feel a little guilty yet? If not, then you’re a better person than I. I’m guilty of this just as much as a lot of developers out there are. We forget that there was a point in time when we didn’t understand PHP’s object model or some of us even know how to use an array (yup, they’re out there). Some of us have come a long way since those early days of the endless “hack, reload, hack, reload, hack, reload” cycle spent learning the inner workings of that latest bit of code we grabbed from freshmeat. Those long sessions tend to blur together into one big fading memory of our early times with PHP and that’s where we get in trouble. We forget how much hard work and how many lines of code we’ve put in to know what we know. It doesn’t matter how far along you are in the process of learning PHP, I’m willing to bet there’s someone that knows less (“I just finished my first ‘hello world’ script!). I’m begging with you – pleading to you – that you don’t forget your early days. Remember how hard it was for you to wrap our head around that one feature, and be willing to help when someone comes looking for help. Give help when you can – a language is only as good as the people that make up the lifeblood of its workings and providing a well-lit path to the answer someone needs is an excellent start. This is the other side of “Be a Hermit” – you can be the one that’s there to provide the exact answer someone needs if you just take the time and work with them. Trust me, they (and the community) will thank you for making their code a better place for data to live.