Those who know me or are familiar with this blog will know I often bemoan (aka: rant about) the lack of good PHP software engineers, or the mass of "junior" ones.
But it might be worth thinking about why this lack arises. I said, in my recent "Getting started in PHP" post:
If you're not interested in becoming great, please don't start.
While probably a touch harsh, I feel it's a valid sentiment. But how do you become great anyway? How long does it take?
To be honest, I don't know. I've only been doing this for 10 years professionally.
So, am I slow, or does it really take over a decade?
Well, at the risk of a "piece of string" answer, it depends on two things:
- How much you need to learn
- How fast you can learn it
My feeling at the moment is that there's a great deal to learn, and it's not often well, or coherently, taught. Even finding out what you need to learn can be really tricky.
However, I'm going to try and throw together a partial list, to try and get some idea of just what you have to know to be good in this game - and what that means in terms of how long it takes a developer to "mature".
As per the previous post, you'll need to start off with some basic coding principles and grammar; statements, variables, and functions. Then, wrapping those into classes.
You'll need a coherent idea of how to properly manage your code library and file inclusions (ideally with a class autoloader), which tends to lead to a coherent naming strategy.
Then, I'd strongly recommend learning TDD (recommendations on good sources for learning it gratefully received!). Not only does this help you write stable code, in a way that's useful in commercial environments, it also helps you learn the importance of good code encapsulation, and of dependency management. It's often considered a fairly advanced topic, but my feeling is that it should be learned as early as possible. TDDing your early code will also greatly increase its lifespan.
If you want your code to stick around and evolve, you *must* learn version control. Personally my recommendation is for Subversion, but there are many people who prefer Git. (You're advised to google these terms liberally). Your code's no use if it's scattered all over the place and not backed up, and a repository will help keep your code together and safe.
At some point very early on, and as mentioned previously, you need to learn about security. However, you can reduce your exposure to risk by using good practices, and data access layers such as prepared statements, PDO and Zend_DB. But be aware that there's a lot more to it than that!
Once you start looking at this sort of library or abstraction it's worth taking more time to look at frameworks and application structure. The MVC model is one key design you should learn, but it's only one of a wide range of Design Patterns which form an advanced vocabulary of development.
Design Patterns form the advanced building blocks of developments, but you should also advance your development practices - your tools, effectively. The techniques you should learn are collectively known as "Pragmatic Programming", and are neatly encapsulated in the book "The Pragmatic Programmer", which you might as well buy and read now, because you'll be a better developer afterwards.
These formalised approaches and skills mark a transition in your approach to creating code and applications, from "mere" development to software engineering. A hobbyist can certainly be a developer, but engineers are skilled professionals and experts. Much as it takes 3-4 years at a University (in the UK at least, more elsewhere) to become an engineer, it can take that long, plus a few years of practice, to truly grasp the skills of software engineering. And, as things stand, I'm personally dubious that university courses exist that give you a broad and modern enough skillset.
And there are also auxiliary skills that don't directly relate to development; configuration of servers, estimation skills, Scrum development practices, code reviewing; you'll need many of these to work in a team.
So, there's plenty to learn and, as said before, you won't stop learning. But, given some idea of your syllabus, a few pointers to resources, and plenty of interest and support, you can certainly build a very strong skillset in a few years. One of the problems I've felt over the years while learning is that it's very hard to know what I should be studying, which costs you time and direction. Hopefully the above list will be of some use; for more, just keep reading, attend conferences, and consult your local user group.