When he joined his front-end knowledge was shocking, and he was entering a mainly .NET office with knowledge of PHP, so he spent most of his time on our smaller sites that run PHP. He struggled with many of the basics, and even though I was a good friend of his I was asked by the Managing Director if he was capable enough to stay with the company. I said yes, solely because I didn't want to see a friend sacked on the opinion of a dev with only a few years experience.

As a bit of back-story, the dev process when I first joined was shocking. The "Technical Manager" would help with phone lines and was my direct boss. As he didn't trust me with files I had to give any files I wanted FTPed to a server to him. There was no source control, and we were running from free versions of the Microsoft dev tools. When other people needed Photoshop for basic designs the company abused the 30 day trial across different VM's.

After the above conversation I had become Lead Developer after the Technical Manager left. With this new responsibility I had set up Continuous Integration, automated delivery to the servers, and had bought Visual Studio licenses for the devs. Amazingly, the Managing Director was fine with this, and had no idea that we didn't have the tools we needed. Now that the .NET side was sorted I had to move onto what we'd do with the PHP dev, who had basically spent six months modifying basic WordPress sites with forms.

Since we were looking to move some of our smaller PHP sites to larger sites, I decided to try and steer the development of his projects towards tools that would make him a better developer, and would ultimately force him to adapt. Instead of WordPress for these soon-to-be complex sites I suggested he find a framework (he chose CakePHP after we looked through them). From there, I decided to integrate him more with the .NET developers so that he would have to look at how we do things and then think about how he'd implement things for his tool set. We introduced weekly code reviews for all devs, and I think that helped him out the most.

It took a while, and carried on after I had left, but he moved from Windows to a Mac, managed to set up TeamCity for use with his PHP projects, moved some of the sites to PostgreSQL during the new build phases, and over time his code has improved significantly. It's been a number of years since we worked together now, but he's gone from someone that could barely work without WordPress to someone that writes good code and can deliver. Ultimately, it makes me believe that a bad developer is just a developer that needs direction.

We kinda lucked out with the idea. Some of the managers were adamant that all teams have a team meeting, with one of the "managers" sitting in, mainly because our technical manager had left and we were kinda self-governing in what we needed as developers. The regular meetings were a waste of time so we turned it into a code review meeting. Since it was a small company it was just developers and one of these managers, and the second the code talk started they couldn't wait to get out of the room.

Initially, I tried to steep the code review, but it worked best when we'd just go through our commit history, pull down some code and run it there and then from our "QA server" (a VM running off of one of the company file servers). I was very keen to make sure that it was a light-hearted meeting, so we'd demo the code, explain our thinking behind our implementation and just generally talk about whether we'd do things differently. Having a PHP guy involved was actually quite fun, because we were keen to treat it as if we'd learn something new by how "the other half" do things. We'd pick up on the differences between the code structure and talk about how we'd apply SOLID principles to that PHP code. One of the big breakthroughs in that meeting was getting this guy to adhere to the Single Responsibility principle in his code. Once the structure started to break down he'd be working extremely hard to better his code.

It'll need adjusting for your environment, for sure. This office was really stuffy, and aside from the odd manager and the MD many of the managers tried their hardest to be assholes. The process worked quite well, but I think the best part about it was that for an hour you could talk about code, have a nice coffee, and not be bitched at by managers that weren't even responsible for your area.

I think you need to consider two main attributes when hiring...

1. Does this person have the right mindset and intelligence to excel as a programmer? Are they a good problem solver? If they run into an issue, do they get frustrated and toss their hands in the air asking for help, or do they start debugging their code, using logic to find their errors, search out answers online, etc. You can see this at any level of experience. If you're teaching someone to write their first few lines of code and they miss a semi-colon, or declare a variable wrong, how do they react, and how do they move forward? Anyone can learn the correct syntax, but can they grasp the concepts of programming?

2. How much passion do they have for programming? Do they work on projects of their own? Are they learning more than you ask of them, for their own enjoyment? Does their day end at 5pm, or do they show up the next morning with a plan to tackle challenges they faced the previous afternoon?

If you're hiring more experienced staff, you need to look at things a little differently. However, when it comes to new talent, I think those are the two most important factors - do they have the mind of a programmer, and a passion for programming.

Why do you imply that he's asking his developers to do impossible things? He doesn't say that the developers are working on particularly difficult code (and the vast majority of developers aren't).