Since this blog is primarily about the LAMP environment (php) being the key language I thought I would address a problem thats pretty common among a good percentage of php coders – and that is the tendency to be hackers.
I don’t mean you are a hacker if you are a PHP developer. Not at all.
I mean that a good percentage of folks who LEARNED the fine art of programming by becoming LAMP developers often lack the high level structural thinking that some folks from other backgrounds have.
The reason for this is, PHP is / was the biggest “web programming” language that was easy to learn for a beginner, with ample webhosting, mountains of documentation and help on the web, and therefore drew in a bunch of beginning programmers. Nothing wrong with that. Another reason would be that PHP was not always an OOP language – this was introduced later on, so all the old PHP guys either had to learn it, or just didn’t.
Myself, having come from a C, C++, perl background, was always trained out of necessity to think something through before going into the code.
But in hiring, interviewing, and eventually working with php developers, I consistently am surprised how many of them who’s first reaction is to hack their way to a solution instead of coming up with a graceful end product.
They often lack knowledge of architecture types, frameworks, and object oriented theory.
I shouldn’t be surprised though. A lot of them learned themselves through trial and error, and never had a mentor who had been there before, or their mentor if they had one, learned the same way they had – trial and error.
And PHP is SO forgiving, it really doesn’t force you to learn a framework, or a structure, or even one way to do things. On one hand this is a wonderful thing about PHP – the fact that its easy to learn and you can knock out an application fairly easily – many great minds – and their applications saw the light of day with PHP – people who had wonderful ideas, but didn’t have the time to become “application developers” first.
So lets quit dinging these guys for their style (or lack of…) and help them out.
So lets say you have 3 employees, of course not counting yourself.
Sammy is a junior developer. He knows php, decent with MySQL but not great. He can write functions, but OOP confuses him. No framework knowledge at all.
Johnny is a mid level guy. He’s good with classes, MySQL, and he’s played around with Cake PHP and he thinks its really cool but he keeps breaking the rules because he’s not used to MVC or a framework, and – well – because he can , and sometimes its the easiest way to the solution for him.
Tony is a skilled guy, he’s all about objects, classes, frameworks, he’s more of a high level thinker and he’s the best guy you have. If you died in a bizarre gardening accident tomorrow, Tony would get your job.
Sammy and Johnny need to be willing to learn, and Tony needs to be willing to help you teach. You might have 10 Sammys, 5 Johnnys, and 3 Tonys – it doesn’t matter. The first step is to identify which of your employees can help you teach, and which ones need to learn.
Requirements:
1 – The developers must be willing to learn and change.
Sell them on the benefits. Sell them on the ease and time saving factors. Sell them of convention over configuration. The biggest resistance you will meet in a developer is the fear of the unknown – the fear of not having the answer in a critical moment. Make them realize that what you are teaching them isn’t as far as it sounds from what they are already doing. Its organizing their code – encapsulating it, making it more modular, eliminating drama, stress, and spaghetti code.
2 – Your company must be behind you in the fact that learning is paramount.
First off – don’t take too much of the company time for your teaching sessions. Keep it to the bare minimum, and leave some of the details for on-the-job learning. The minute you propose a two week hiatus in the production schedule or a 3 hour per day training class for all the developers, the management will jump ship on the idea, leaving you right back where you started. Companies vary, and so do managers, hopefully your company understands the value of education, (especially – and sell them on this – a free one) for their employees.
The selling points are many – much less time for development. MVC makes development very fast! Much less time for maintenance. With the convention over configuration, even a developer who has never been in a particular piece of code should be able to adjust very quickly to his new environment – because its not a new environment after all! Sell them on all this, it’s all true. It is true that a smaller investment in training and education will pay off handsomely, and not in a few years – more like a few weeks or months!
Step One: Introduce MVC, The Cake framework, and some project planning basics
For this part, don’t worry about objects and classes – that will come – do a quick overview of OOP so they understand, but don’t stall here. Your junior developers can work closer to the framework, and your more advanced ones can work with the objects and classes. Have a weekly class where you first introduce MVC, and then do some examples in Cake. This keeps them in their comfort zone with the code, freeing up mental space for the higher concepts.
I would see it something like this:
Class One: MVC Overview
Class Two: OOP Overview, the very basics
Class Three: Introduce Cake and Tie it all together
Class Four: Introduce project planning charts like model and class diagrams, but don’t go full blown UML – they will die of boredom.
Class Five: Plan out a sample sample application, which will be done in Cake, using what they learned in Class Four.
Class Six: As a team, get the application framed out in Cake, show them how easy it is.
We are now only six weeks into this – six one hour courses. Adjust this as you need. You might find that some of them try to break Cake’s rules and go back to procedural coding, as this is possible with Cake. If this happens and becomes a problem, try Step Two:
Step Two: Force them by introducing another language – Ruby – with Ruby on Rails.
a – this forces your Johnnys to learn the system – all their dirty little tricks in php are gone, they have to play by the rules.
a – this also keeps them learning together, Johnny is now no better than Sammy, they can help each other out. You might see Sammy surpass Johnny here.
b – develop a simple simple app with them to show them the ropes
Be careful with Step Two – you might end up convincing everyone to stick with Rails!
I have to thank my friend Russ for getting me thinking about this stuff again!