[EnderMB]

The first company I worked at hired a fairly poor developer, who eventually turned into a quite talented programmer.

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.

[asbestoshft]

Since you say that code reviews helped him the most can you give some details on how that was done, who was involved, how much time was devoted to it, etc?

[EnderMB]

I tried to make it as casual as possible. We got some nice coffee from the coffee shop down the road, brought it into a meeting room and spent about 45-60 mins going through the commit history on some of our projects.

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.

[asbestoshft]

That is a really great suggestion. I'm going to try that next time I find myself in this situation. Thanks for your time and input on this.