On Reddit.com there's a good discussion going on to answer the question "What non-PHP stuff should a PHP developer know?"

I was looking at job description for a web developer, and one of the big responsibilities was database maintenance. [...] And along those lines, what other skills would be useful for a PHP developer to have that aren't directly PHP-based?

Suggestions so far include things like:

• Linux command-line skills
• some Python
• Virtualization (making and administering VMs)
• Version control systems (svn or git)
• Database architecture
• HTML/CSS/Javascript

In this recent post to his blog, Chris Hartjes answers his request for a "rant topic" by responding to a question about "how to not suck at PHP" (from Travis Northcutt).

I thought about this question for a while and have some thoughts on what it really means to know how to not suck at building things using PHP. In my never even remotely humble opinion I think the key is to understand what PHP is really good at.

He talks about how PHP had the early-adoption advantage at first with Apache, but how things have changed so much since then. Now, he proposes, PHP's popularity and usefulness is based on what it can do as a language without messing with frameworks at all. He's worried that, once someone picks up a framework, it'll become so ingrained that they won't know what "plain old PHP" can do (or how to work with it).

So my advice to Travis is that he should worry about learning to use PHP like glue and correctly identify the problems he is trying to solve NOW instead of worrying about the problems he might have to solve later. There will be time to fix your problems. Some of those will be solved by using tools that are not written in PHP, but PHP can still glue them together.

In this new post to reddit.com the question is posed, "is it better to be an expert or all-arounder in web development?"

Is it better to be an Expert in a framework like Zend (a certified Zend Developer) or know a little bit about everything. [...] In sum, it's just taking too much time for me to master Drupal, Magento, and other popular CMS/Frameworks. So I'm wondering if I should just specialize is one framework/CMS.

Most of the comments follow along the same idea - it's good to be an "all-arounder" and know several different technologies, but it's also good to be an expert (or as close as you can) in one or more technologies. As one comment puts it:

In my experience, it's best to have a specialty, but not have a too narrow focus. There's a lot going into a web site - programming, design, usability, marketing, economy, etc. Understanding a number of those fields makes it easier to work with other people.

On the Erskine Labs blog today there's a new post from Wil Linssen with a suggestion to PHP developers who specialize in the language - take the time to learn another language and broaden your skills.

So many languages share fundamental principles, and indeed many are even derived from the same concepts, but because they differ in their approach there's something new to understand in each. It's these differences that will frequently bolster your understanding of your primary language, or indeed of programming as a whole.

He notes that it's not just PHP developers that pigeon hole themselves into one language - developers on other languages do to. He recommends they lift their heads up and branch out and stop attacking other languages with "language X is best" articles.

It's stepping outside of your comfort zone and engaging with the underlying concepts of the languages and tools you are using that will enable you to grow as a developer.

Chris Roane has put together a list of things that he wishes someone would have told him back when he was starting out as a web programmer ten years ago, helpful hints that could have made things easier in the long run.

When I reflect on my past experience as a web programmer, there are many things that I know now that I didn't know ten years ago. The learning process was valuable, but I could have been at a different spot today as a PHP web programmer if I knew these things earlier. Sometimes you don't have the info when it would benefit you the most, but my hope is that this list will give you something to reflect on.

Most of the tips a more of the general tech nature with a few non-tech ones thrown in. Here's a few examples:

• Over Estimate Your Time
• Don't Assume that Where You are Working is the Best Opportunity
• Learn How to Use and Work with SVN
• Master Organization
• Learn Outside of Work

Read the full post for more great tips.

In a recent post to his blog Davey Shafik proposes that you take a look from another angle when considering what to use for a project (PHP, .NET, Java, etc) - think people, not so much technology.

One of the biggest decisions you can make for any project is the environment it which the project will be written. Most developers mistake the word environment for the word "technology" or "software". [...] With this in mind, I then would say that the language capabilities themselves, are the least important factor in choosing your environment. This then brings me neatly to what else that environment encompasses. These, to me, fall into three categories. People, knowledge and penetration.

By breaking it out into these three categories you can better understand what the project needs and which direction it might need to go: can you find skilled people to write the code? do they have access to good resources during development? what kind of market penetration does the technology have?

He evaluates each of these from a PHP perspective with the result of PHP having "the trifecta" - filling all of the requirements to their fullest.

Stefan Koopmanschap has posted a few reasons why he thinks you should attend and participate in your local TestFest event.

As I wrote earlier, several TestFest events will be held soon with the biggest one being the European TestFest initiative of quite a big bunch of European usergroups. But why should you attend such a TestFest?

Here's his four reasons:

• To improve PHP
• Improve your own knowledge
• To expand your network
• Because you're friggin cool!

You can find out more about TestFests in your area at this page on PHP's QA website.

A new article has been posted on the Ibuildings techPortal site today from Stefan Koopmanschap The article looks at refactoring applications: what it is, how it can help you and a few requirements for doing it successfully.

If you read articles, visit websites, read tech books or visit conferences you will undoubtedly have heard about the term refactoring. There is a good chance you've been refactoring yourself already, whether you knew it or not. In this article you will be introduced to the practice of refactoring. The basic definition will be discussed, as well as reasons for refactoring and how to actually refactor your code. The difference between refactoring your code and rewriting your code will also be explained.

After explaining what refactoring is, he gets into how it can help your applications and some of the key things it will help you with like the creation of a more structured API, development of unit tests and a larger knowledge of the code base. A code example of refactoring is also included.

Brandon Savage has made a few suggestions that can help you with one of the most important parts of any development project - picking the right tool for the job.

You'd never dig a drainage ditch with a pitchfork, or plug a drywall hole with chewing gum. Instead, you'd pick an appropriate tool and you'd use it to accomplish the job (a shovel, or some spackle, for example). So why do software engineers often spend so much time fixing problems with the wrong tools at hand?

He includes three common issues and ways you can overcome/stay away from them:

• Lack of knowledge regarding available tools.
• Inability to implement solutions due to lack of resources.
• Unwillingness to implement a solution.

Of the three, the last one is possibly the most scary - don't let personal feelings or your dedication to Tool X be your undoing and hurt your application in the long run.

Dave Marshall, a developer from Hull, England, has posted a few recommendations he thinks could help you land that next PHP job.

After reading this thread, I thought I'd spend some time writing about what I feel are some measures you can take to landing a job in PHP. This first part is going to concentrate on the kind of technical matters I think any PHP developer should at least have knowledge of, if not some kind of experience.

He suggests: as much programming experience as possible, experience with the full development lifecycle, knowing how to work with external libraries and frameworks, being able to adapt to development tools, knowing web application security, and some work with web services and a touch of system administration. He's not saying that you have to have all of these - just that the more you know, the better off you could be.