Anthony Ferrara has a new post today on his blog with some things he think you can do to become a better overall developer (and not just in PHP). He shares six things from his own experience to help answer this question.

One of the most frequent questions that I get asked is "How can I become a better developer?" I think that it's a very good question to ask that deserves a good response. But how can you respond to something like that? Becoming a better developer depends so heavily on past experience (where to grow), interests and rationale (why do you want to grow), that it's really hard to answer without a fair bit of discussion. This post reflects my experiences from both my own growth and the growth that I've seen in others.

The things on his list are pretty simple, but they're easy to forget in your day to day development life. Things like being motivated to better yourself, gaining confidence in your abilities, sharing your knowledge and/or becoming a mentor to developers with less experience than you. Interestingly enough, this last one can sometimes teach you a little something about you and your processes too.

Kevin Schroeder has posted about an idea he recently came across (in this article) called the "Curve of Talent". Kevin's post expands on the idea and makes it a bit more relevant to the "how can I be a better developer" question asked quite often.

I get asked, quite frequently, about how people can be better programmers. Why they're asking me, I have no idea. But what I usually tell them is to be curious and be creative. Waste time. Now, I don't mean "wasting time" by playing Quake (one of the best adrenaline-based games of all time), I mean taking time to learn new things and try new things... sometimes without permission and sometimes before or after normal work hours. (Though not ALL the time. If you always are working you have priority issues).

He recommends working on side projects - ones where you can be free to explore new technologies and ideas that might not fit in the confines of your day to day work. The article from Eric Paley talks about "C level performers", people who may or may not have the experience, but just can't seem to make things happen. Kevin's recommendations can help you break out of this "C" mold and get on the path to not only better yourself as a developer but also make you more equipped for future projects.

Cal Evans has posted the eighth tip in his six-tip series (but who's counting) about how a client can coordinate better with a developer and make a better relationship for the project. In this new tip, he suggests that the client "own it".

No, I'm not talking about own it as in Point 7 - "Do your part", I mean make sure that at the end of the project, you own the project, not your developer.

He mentions two of the aspects you, the client, will need to worry about once the last line of bug free code has been committed and delivered. Be sure that you own the domain name for the project and have a clear understanding of any intellectual property concerns that might come up (what codebase is it built on, who owns the code - client or developer, etc).

Indra Dutta has shared some of his thoughts about which language(s) are best suited for web development work in his latest post - that PHP is a better choice over things like Java and .NET for building most of the functionality out there.

I have worked on java web frameworks like JSF, Echo2, Vaadin, Grails and recently Play. Similarly I have worked on Silverlight, ASP.NET and ASP.NET MVC. My conclusion is that, in overall, PHP frameworks beat both java and .NET frameworks in terms of ease of development, deployment and even maintenance- for creating web sites with moderate complexity. Of course, I do not expect you to take my words for granted.

He lists his "top five" reasons why PHP is the better choice over some of the other frameworks mentioned:

• PHP web hosting options are superior
• PHP provides rapid development and instant gratification to developers
• PHP web frameworks provide a complete stack sufficient to develop a great many web sites
• PHP frameworks provide a low barrier of entry for web developers
• No DLL or jar hell

Of course, no article like this is complete without a load of comments from both sides of the fence, so be sure to read up on those for different perspectives.

On SixRevisions.com there's a recent article aimed at the new to mid-ranged PHP developers out there (with some good refreshers for the seasoned developers) about ten things you can do to become a better PHP developer.

In this article, I'll share with you ten things I wish I was told when I was just getting started with PHP development, and I'm hoping you'll be able to learn a thing or two if you're just taking your first steps into this awesome web development language.

Suggestions that made their list include:

• Use PHP Core Functions and Classes
• Create a Configuration File
• Always Sanitize Data That Will Go into Your Database
• Don't Over-Comment Your Code
• Use a Good Source Editor to Save You Time
• Connect with Other PHP Developers

Be sure to check out the comments for more great suggestions from other developers.

If you're one of the developers that have the basics of the language down and want to improve your skills to the next level, you'd do well to check out this post from Webgeekly.com packed with little helpful hints you can use to make your life easier.

PHP is a very versatile programming language that can achieve the same objective in multiple ways. You can read more about that in my 'The Art of Programming' post. Below are a few tips I've picked up from past projects that can improve your code readability and maintainability and make you a neater, more organized PHP programmer.

There's lots of useful hints included - most of them are relatively basic, but they can even be helpful as reminders for those seasoned developers:

• Separate Configuration Files
• Use Indentation and Spacing
• Give your Variables Meaningful Names
• Use Ternary Operators
• Use Assignment Operators
• Use Objects instead of Functions
• Aim for Loose Coupling, Strong Cohesion

Kevin Schroeder has posted his second part of his thoughts on building better PHP programmers - things developers can do to move from the average to exceptional in their skills.

I have no "findings", no "conclusions", but I have some thoughts on my continuing goal to help bad/nominal PHP programmers become better PHP programmers.

He talks about the questions he asked in his previous post (like "is there a shortage of good programmers" and the requirements on memorizing) and some of the responses both for and against them. He stands by several of them, noting that, which a developer may not know the whole story, they should at least know enough.

One of the things I've also found a little interesting is that there is some resistance to standards. The argument goes; developers get better by different means and so having something set in stone to evaluate them is difficult, nigh impossible, to do

Jani Hartikainen offers a simple suggestion for making your code better - stop adding more parameters.

You need to add some new functionality to your function or class. Let's say you need to remove all objects stored, but optionally also call a method on them. It's pretty simple, isn't it? Let's just add a parameter to removeAllObjects! If you make it true, the additional method is called, otherwise not. Except it's not really such a good idea at all...

He points out that there's nothing wrong with parameters, it's their overuse that can cause the issues - if, in using them, it's unclear what they're doing, don't use them. He includes a few rules for making good use of parameters: less is good, relationship to the function, parameter order importance and using the language's parameter handling to your advantage.

Want to be a better programmer? Robert Stackhouse suggests fighting your natural instincts:

I was watching a video of the Google I/O conference. In it, one of the speakers said that, "It's our natural instinct to try to be a genius, but we need to try to fight that." [...] In this video, they touched on a whole host of natural tendencies: getting defensive, hiding your code away from the world, trying to exert ownership, and trying to do it all ourselves. All of these actions have very real very negative consequences for the team.

Opening yourself and your code up to review by your peers can sometimes be a scary thing but, in the long run, transparency is necessary for good team-based development. He also recommends bringing up issues to other developers in a more one-on-one setting rather than a group.

Jani Hartikainen has a suggestions of a way to "send files better" in his latest post by using the mod_xsendfile module for Apache and a bit of PHP.

I have previously written a quick post on making files downloadable through PHP scripts. The example in the post reads the file itself into a variable, and as pointed out in the comments, it's not necessarily a very good idea especially if you deal with large files. Recently at work, we needed a reliable way to send files to users' browser, and I decided to take a look at mod_xsendfile, as suggested by Tom Graham.

He starts with some of the benefits of using the xsendfile method over other, more traditional ways. Moving on, he gets to the good stuff - download, installation and a code example of how to use the module (via a X-Sendfile header).