As another startup in Atlanta trying to hire good PHP developers, I can sympathize entirely with MailChimp on this one. I have been searching for months for local PHP developers with experience doing TDD or other agile/modern practices and it is extremely difficult. If you are one, please feel free to contact me.
I think good TDD/agile/architecture cultures are more prevalent in ruby/python but as those languages have become more mainstream the quality of the average dev in those environments has dropped quickly. A few years ago only really good devs ventured into ruby stuff. Now everyone is trying it as the tools have made the language much more accessible for the average developer. I am seeing more and more programming mistakes in the ruby code I dive into than I used to.
Language choice doesn't matter too much from a technical perspective. It matters from a practical perspective. Consider the jQuery/prototypejs war. Prototypejs was technically superior for a long time, yet due to jQuery's more accessible plugin culture and prettier web site they were over time able to build a more robust community and took the mindshare lead in the js space. I still think one of the core reasons ruby/rails and python/django got big is that for a long time there was only one major framework available for the language and this caused a better community than the php landscape, which pre-dated frameworks by a long time (this happened to perl as well). So there wasn't "one true way" in php to build apps quickly, and this hurt the php community when rails got big. I think as a community we lost a lot of talent to ruby/rails in the last few years.
Bottom line is that accessibility, pervasiveness and low-learning-curve are critical to the initial and continued success of any platform, whether it's a language (ruby > php > perl), OS (ios > android > rim), etc.
Language advances in PHP (circular gc, traits, closures, etc) have brought php's language capabilities forward enough that it's a respectable platform for sticking with. However, you can't fix the community really since it's so fragmented. Fortunately some frameworks are getting enough traction to have rich ecosystems, and that's definitely a great thing for the language and the community.
Have you tried hiring good devs and then let them learn php, rather than narrowing your pool of candidates by only considering good devs who know php well? I mean, the latter may be preferable, but the former will often do.
I have not yet resorted to that. My concern (which is possibly unfounded) is that it would take significant investment before the productivity gain made it worth it. Then you have the risk that a newly trained person would leave the company as well. Also, I am not sure that a good developer from another language (like ruby/python) would consider using PHP on a day-to-day basis due to the perception of php as a crappy language.
I'd argue it's completely unfounded. PHP is the easiest language in the world for someone who is reasonable at other scripting languages, because there aren't very many new or weird paradigms that it forces on you. I last touched PHP in high school but haven't had any problems readjusting to it here at Facebook. In fact, I'd wager that very few of the people in Facebook's bootcamp program right now came with any of the experience you're looking for.
PHP is very easy to read, very easy to pick up. However, it is full of bizarre edge cases. It seems like every function definition is followed by at least 3 comments saying "Just so you know, you will try to do this - > PHP actually does this."
Alternately there are 5 comments showing boilerplate for the most common use case, and none of them are quite what I'm looking for.
Compare to Python, 9 times out of 10, the boilerplate 4-line example (in the primary documentation) is exactly what I'm looking for.
I think PHP might actually have a good language lurking inside of it, but someone would need to rewrite most of the standard functions and classes by going through the comments on their documentation and asking "Why doesn't this function solve the problem this bit of boilerplate solves?"
Thanks for your thoughts! I can see your point. I think mainly I was trying to get away without having to do training, but clearly that isn't working out so well.
Can I ask you what your language of choice was before FB and would you have taken a php job somewhere that wasn't FB?
When you say "having to do training".. A great programmer don't need "you" to do the training. Just give him/her a couple of days to read your codebase and learn the language. Anyway, even if it was the best PHP programmer, you'd still have to walk through your architecture and important design decision. So, at this high level, it's not important at all whether the guy/girl understand the inner details of PHP.
And, might I add, PHP is so easy to understand and read.. You don't even have to know PHP to read the majority of code written in it ;-) Compare that to, say, haskell or scheme, where it's a whole new paradigm.
This is a crucial blunder from all no-tech people I know who are trying to hire great programmers. Seek Great Programmers, not Great "insert a language" Programmer! A good programmer will be good in any languages; a bad one will be bad in all languages.
If I had to choose I'd probably say C or Python, but language wasn't a very strong influence on my job choice (other than knowing that I wanted to avoid Java). That Fog Creek has done well with Wasabi [1] says to me that language is not the most important thing for most candidates.
I think you are correct that any good programmer could learn PHP (or any language, really) to be productive in a reasonably amount of time. All the startups I've been involved with hire talent over language experience. However, I think the hirer was correct in noting that a PHP job would not be the most attractive job in this period of high demand for engineers.
I've struggled with it and given up almost entirely because it's so hard to memorize. Surmountable with full time use, I suspect. Very inconsistent function names led me to either living from a reference book or constant Googling even when I thought I knew the name of the function I needed.
Please don't hire based on knowledge of a language or a framework. It's a bad habit, because the best software engineers span languages and frameworks.
I am not a super-dev, but I can write code in an unfamiliar language in a day or two (non-idiomatic, of course). Better people than I can do better, I am sure.
I am sure you will be able to find great engineers if you open up your playing field.
You may be able to write code, but can you understand code that was already written by someone who knows all of the idiosyncrasies of a language you're not familiar with?
I would actually say that the developer who has experience in a handful of languages/framework and is willing to learn php for the sake of a cool project/team/company is potentially a better developer than one that has just mastered php (note: not saying php dev == bad, but that multi-langage/framework dev that values problems over tools more typically == good). So by limiting your offering to just good php devs you may actually be driving away some of the best devs interested in working for you.
It's really not a bad way to go. You may still get reactions like you've come to expect from developers, but a sign of a good developer is whether after having that knee jerk reaction, they start asking about your technology choices and how you've implemented things. Essentially you want a generalist who is technology agnostic and is willing to roll up their sleeves and get to work in any codebase. PHP isn't that different from other languages and after a week spent learning the nuances with a little training help they should be able to be productive.
I'd love to chat. Please reach out to me - not sure the most proper way to do that in an HN thread. I am apinstein on GitHub or check out tourbuzz.net contact page.
I was at php|works Atlanta, but I didn't present. I have presented it at ATLPHP before. I've presented on other topics as well though and usually at least mention that I created phocoa during my bio.
Our position isn't just PHP actually, but that is our primary back-end language. Probably makes the other commenters' posts about multi-language experience all the more relevant. We do a lot of front-end work in Javascript and we use ruby a decent amount as well (rake, chef, capistrano).
Even developers that know PHP inside out have to learn your framework first. I guess a good developer would pick up PHP along the way.
As a side note, I never understand when someone says learning Objective-C makes iOS programming harder for someone who does not know the language in contrast to Java developers which can directly jump into Android development. The hard part is to learn the framework (Cocoa Touch vs. Android API), not the language.
I am amused by the perception that a pro software engineer is assumed to only be proficient in the programming language they used in their last job. If an engineer is applying for your job, talk to them and make sure they are a good personality fit for your team. They are probably going to take more time understanding your dev tools and procedures than boning up on PHP.
The motive behind that wasn't about people not being skilled outside their current language (which I agree would be amusing), but that I wasn't sure trying to pitch a PHP job to ruby/python/java developers was going to be successful.
I guess seeing all the PHP-bashing that happens in the world (especially on HN) made me a little gunshy about approaching high-level devs to work on our project.
Fortunately thanks to some very well-made points and stories shared on this thread, I am now optimistic that I should be able to convince devs used to "better" languages that working on a PHP project could still be cool and a good learning experience.
This thread has been really great for me. Thanks, HN!
My concern (which is possibly unfounded) is that it would take significant investment before the productivity gain made it worth it.
Anecdotally, I took a job as Rails developer some years back. I had zero experience with it before starting (Having worked mainly with PHP before), but because the environments are so similar (http is the same, gnu/linux is the same, mysql is the same, architecture and oop is the same etc. etc.), I was creating value after about three weeks and I would say that I was fully up to speed after something like 3 months. Consider that it can easily take the same time to get the business, the problem domain and your new colleagues to know, I'd say that the cost for my employer was close to nothing.
Now, I'm not saying that anybody can do this - I consider myself a fairly good developer and beside PHP, I have tinkered with a broad spectrum of languages, which surely helped my transition. And the point isn't that Ruby is such an easy language that it can be learned in 3 weeks either (In fact, I think it is a rather complex language). What I take from my experience is that a good (and diverse) developer, with a motivation can jump from related technologies with relative ease.
I do agree with your sentiment that it might be easier to sell a jump from php than to, but that is a different problem. If your project is interesting in it self, I'm sure you can find good developers who don't fret too much over what particular language they write in.
Every change of job I've made in the last 8 years has involved at least one change of language. In my mind a professional developer can pick up Perl or PHP or Cobol or Scala or whatever.
If somebody's got the attitude that 'Java sucks, I only want to code Ruby', that person's not a pro in my book.
The funny part is that when Rails and Django were rising to fame, it was argued that PHP was the better choice because finding developers to maintain the code in the future will be easier. Now that we are here, it seems it didn't turn out that way at all. Goes to show you should choose technology for technical reasons and technical reasons alone.
In addition to the functional programming techniques it offered (which are now handled by underscore in the jQuery landscape) its selector was much more performant than jQuery's for a long time.
The enumerables prototype took from ruby were really nice. I always liked being able to do things foo.map(function(p) { return p.length; }); jQuery's $.map felt clunky in comparison.
(this is all with the understanding that prototype adding methods to standard objects was dangerous...)
〉 I have been searching for months for local PHP developers with experience doing TDD or other agile/modern practices and it is extremely difficult. If you are one, please feel free to contact me.
I believe I meet your criteria but can only work remotely. I am currently looking so if remote is an option please let me know and I can send you more details.
Please reach out to me, I'd love to chat. I'm not sure what is the most proper way to do that in an HN thread. I am apinstein on GitHub or check out tourbuzz.net contact page (feel free to call).
I think good TDD/agile/architecture cultures are more prevalent in ruby/python but as those languages have become more mainstream the quality of the average dev in those environments has dropped quickly. A few years ago only really good devs ventured into ruby stuff. Now everyone is trying it as the tools have made the language much more accessible for the average developer. I am seeing more and more programming mistakes in the ruby code I dive into than I used to.
Language choice doesn't matter too much from a technical perspective. It matters from a practical perspective. Consider the jQuery/prototypejs war. Prototypejs was technically superior for a long time, yet due to jQuery's more accessible plugin culture and prettier web site they were over time able to build a more robust community and took the mindshare lead in the js space. I still think one of the core reasons ruby/rails and python/django got big is that for a long time there was only one major framework available for the language and this caused a better community than the php landscape, which pre-dated frameworks by a long time (this happened to perl as well). So there wasn't "one true way" in php to build apps quickly, and this hurt the php community when rails got big. I think as a community we lost a lot of talent to ruby/rails in the last few years.
Bottom line is that accessibility, pervasiveness and low-learning-curve are critical to the initial and continued success of any platform, whether it's a language (ruby > php > perl), OS (ios > android > rim), etc.
Language advances in PHP (circular gc, traits, closures, etc) have brought php's language capabilities forward enough that it's a respectable platform for sticking with. However, you can't fix the community really since it's so fragmented. Fortunately some frameworks are getting enough traction to have rich ecosystems, and that's definitely a great thing for the language and the community.