Though we can do so many things simultaneously - should we? Does it actually reduce effectiveness and productivity which are the antithesis of professional application development? [...] I had the thought, as is common in a western-based mentality, that to be busy, to be industrious, to try and multi-task a series of independent tasks and projects simultaneously was the right thing to do. It's meant to be a simple formula: "Greater productivity = Greater self-worth right?" Sounds almost like Thatcherism. I felt that this was not only right, but the sign of an intelligent and sophisticated developer, who truly had honed his craft. Perhaps you've felt the same at one time or another?

He points out that, while it's very easy for developers to fall into this trap and way of thinking, it's not sustainable. It leads to stress, bad code and even - possibly - an even higher bug count. Instead he suggests the good standby idea of "KISS" (essentially, simplicity).

Instead of trying to do everything at once - I stopped and decided to only do one thing at once. And that one thing, had my full attention and focus. When it was done, I then moved on to the next one. Not before and not after.

He includes some of his own experience trying to apply this in a Zend Framework 2 application.

If you are a first-time entrepreneur and likely someone with little experience with software development, the chances of you successfully directing the development of a product on your own, are slim. [...] In software development, too often vision holders hand off a "vision document", i.e. "The Specifications", to a developer and expect him to translate it to the finished product they have in their mind. Most software developers or graphic designers are simply not fit for that role - they do not have the experience, skills or vested interest in transforming your vision to an actual product.

His examples revolve around the idea of outsourcing the development to another group, but a lot of the concepts still apply to in-house development too. He talks some about the idea of "you get what you pay for" when it comes to quality and how much you're willing to pay. He then gets into one of the hardest questions when dealing with development - how to find good developers. He mentions several things that need to be a part of that relationship like trust and good communication.

Every developer knows the pain of banal mistakes. A wrong attribute here, a misspelled property there, an accidentally duplicated line of code which you missed because of the coffee-fueled 16 hour hackathon you've been on. [...] Code review is simply the act of having someone else look at your code to find the mistakes you missed.

The tutorial talks about the types of code reviews (three of them with varying levels of involvement) as well as some best practices to follow in your reviews like:

• Know your common mistakes and actively fight them.
• Peer code review means being reviewed by someone of equal or greater skill.
• Collect metrics.
• Be mindful of the social aspect - finding bugs is good, not bad!

The core of the PHP community is filled with a lot of really talented and smart developers doing some really amazing things. But on the fringes, there are a lot of people who are writing articles, tutorials, and posts designed to help beginners learn the language (and usually how to program). The problem with this is that the majority of those authors frankly don't have a clue what they are talking about.

He talks about why this is a problem (bad practices promoted, bad code) and what you, as a PHP developer, can do about it...and maybe help in creating a separate tutorials site with content "approved" to provide good practices and quality code.

Remember the immediate visceral reaction you had to the double-clawed hammer? That's exactly the reaction most sane programmers have to their first encounter with the web programming language PHP. This has been going on for years.

He talks about the the anti-PHP rants that have been happening (over and over) for years, his thoughts on it being the "worst designed mainstream 'language'" out there...and how the discussion doesn't need to be around these points anymore. It needs to be about how to get programmers to use better tooling (whether or not PHP is the right tool for the job).

Of course, there's no shortage of comments on a post like this, so be sure to go through them and see the various reactions to Jeff's thoughts.

No one has told me this and I don't need them too. I feel like one bug that has a negative impact on the user experience is too many bugs. I've been programming for over 5 years professionally and I still introduce bugs into my code. [...] I don't like the expectation that I (and maybe others have) that my code must be perfect when I am not perfect. I don't like the fact that it only takes one mistake to affect so many people. [...] I'm wondering if others on here have every felt this way. What have you done about it?

Suggestions in the comments talk about everything from dealing with the apparent burnout the developer is facing, a reminder that no code is bug free and some recommendations of testing and bug tracking to help make the quality of the code better (and give visibility into the level of work being done).

A study from Coverity claims that the source code of Open Source projects such as PHP has a low defect rate. Meanwhile, a few weeks ago, the security expert Stefan Esser claims that PHP source security bug prevention has a lot to be desired because PHP core developers do not have the habit of using source code auditing tools to prevent security bugs. The matter of the PHP source code quality and security bug prevention was one of the main topics discussed by Manuel Lemos and Ernani Joppert in episode 21 of the Lately in PHP podcast.

You can listen to this latest episode either via the in-page player or by downloading the mp3 directly. You can also subscribe to their feed to get this episode automatically (and past/future ones too).

From time to time I see bugs in the code and I start thinking "really? is it possible that no one noticed that bug before? am i the first person to see this code?". I thought it might be worth writing a little post on what helps me to deal with bugs and software quality in general and what are the common pitfalls in developer's thought process. Although it is not a very extensive post i hope it may inspire some developers to try new approaches.

Other topics he offers for consideration involve the fact that bugs will never fix themselves (they might disappear in a refactor though), that the bug is almost never in the language/data source's code and how automated (unit) testing can help to find new bugs before they're released to the users.

Anyone who has used PHP for a while knows that it has its ugly parts. Recently I've seen a whole swathe of PHP-bashing articles and that would fine if they were they are making a valid point, but some of it has just been - as I tweeted recently - "absolute drivel".

He directly refutes some of the points made in that article, points out a newer post from the same author (which misses some points as well) and finishes it off with a look at why he "still" uses PHP versus something like Closure or NodeJS for his development.

Despite known flaws and imperfections I continue to use PHP as my primary language because during all the time I spend worrying about which technology is the neatest, coolest or shiniest I could have built a new application to sell or finished another client site.

Be sure to check out the comments for some other thoughts about the language (and Phil's responses).

OpenSource is an amazing phenomena, but how safe open-source projects are? Would commercial project be safer over the community-supported project? Frameworks can't exist without their core team and In this article I look at how different PHP frameworks are supporting their core developers.

He talks briefly about the need for a good, solid group of core developers on a framework (or really any product) to provide a stable foundation if a product was created with it. Four projects are mentioned - Zend Framework, CodeIgniter, Symfony and Agile Toolkit - and why, because of the backing they have from a company and a large group of developers (and contributors) they're not "yet another framework" that'll disappear over time.

Making new frameworks is fun, however, if you share framework with others, be responsible about the support. Make realistic goals and try to have a plan for a next few years. If you are the author, think who will support the community when you decide to move on.