Matthew Setter has posted five reasons why he thinks that making a coding standard is an essential part of your development process. He suggests that "pain avoidance" is one of the key factors, both for new members of the team and for those maintaining it in the future.

Whenever you’re working on a project, are you consistent? Are you consistent in your coding style, consistent in your documenting, consistent in your database naming conventions? Better yet, do you and your team have a coding standard which you consistently adhere to? If you don’t, you’re buying yourself and others a world of pain – which is painlessly simple to avoid. Today I’m banging the drum, shouting from the street corner, calling from the cathedral spire, imploring you to do one thing, above all else – pick a coding standard and then BE CONSISTENT!

His five reasons for implementing (and effectively using) a coding standard are:

• Poor, Inconsistent Code - Causes You Pain
• Your Code is Easier to Read
• Your Code is Easier to Understand
• Your Code is Easier to Maintain
• Your Code is Easier to Collaborate on

Check out the post for summaries of each point.

Chris Hartjes returns with another inside look at telecommuting in part three of his "So you want to telecommute?" series (parts one and two). This time the focus is on remote collaboration.

So now that you've gotten an environment created where you are being trusted to do your work as assigned (despite what people think, just doing a good job isn't always enough in the minds of those who manage programmers and designers), and you have a way to be held accountable for the stuff you are working on, we are on to the sticky issue of collaboration.

He suggests a few different ways to keep connected - immediate methods like IRC, a somewhat less real time tool like Campfire - and the most important point regardless of the technology: keeping the communication lines constantly open between you and your coworkers.

Stefan Koopmanschap has a suggestion for developers out there using frameworks - don't limit yourself to just one framework, think more cooperative.

Most developers seem to limit themselves to a single framework. Be it Zend Framework (more popular than I even thought), be it symfony, there's even still a huge amount of custom "we built it because we have our own needs" frameworks out there, even in companies doing things similar to any other web development company out there.

He recommends looking around at other frameworks (usually the component-based ones work best) to see if there's something that could help you out when your primary falls a bit flat. Don't force yourself to stick with one just because it's "the company standard" - branch out and pull pieces from other frameworks and avoid the "redundant rewrite syndrome" in your code.

Andi Gutmans has posted about a new feature that will be included in any new (or upgraded) IBM i system - a full "Zend web stack" of their products and services.

The relationship with the IBM i team started in 2005. I was deeply involved in forming the partnership and at the time did a lot of the research to better understand the opportunity. [...] There were several solutions at the time which enabled IBM i customers to Web-enable their applications. However, PHP was of biggest interest to the community for many reasons.

PHP was a good fit because of the large pool of PHP developers already on hand, its cross-platform nature, low entry (learning) level and that it provides easy access (through frameworks and the like) to more advanced web technologies.

I am very much looking forward to continuing our close collaboration with the team at IBM who had the foresight of really pushing this hard over the past few years and, with that, not only making PHP on the IBM i a reality but a first-class citizen.