Do below average developers ever turn into average developers?
5 comments
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.
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.
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?
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.
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.
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.
Of course, no one here started off as an average or expert developer, we were all beginners writing awful code at one point in our lives.
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.
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.
I agree with you on points one and two but how do you figure that out in a interview over a couple of hours? I can figure out how skilled they are technically, I can figure out if they have decent communication skills which are also important and then I get to the points you mention and these are softer, harder to quantify skills. How do you go about finding answers to these questions and do you make it quantitative in some way?
[deleted]
Putting aside the fact you're considering firing perfectly competent devs because they're not solving the halting problem for you, hiring is in practice a random process and what you have is probably a better outcome than most, consider what skills your team missing and look to make a 'star' team rather wishing for single points of key failure, even to the extent of going out of a pure dev role to look at BAs and architecture hires.
I agree that hiring is random and the focus should be on making a star team. That is what I have done and I'm pretty happy with how it has turned out. Have you ever seen a big change in the level of productivity of a given programmer that isn't related to longer term general experience ( an average programmer with 10 years of experience should be more productive than an average programmer with 1 year of experience ).
I'm not sure it scales like that for that long, sure there are benefits of familiarity with a language or system, the major changes in productivity I've seen come about through cross-skilling you can only expect the majority of devs or BAs or whatever to reach a certain level of competence when constrained to their core roles, encourage them to develop skills outside their usual BAU activities and the mutants you get back are an asset both in individual productivity and team redundancy.
"Putting aside the fact you're considering firing perfectly competent devs because they're not solving the halting problem for you..."
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).
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).
Admit to a slight use of rhetorical effect there, I completely agree the vast amount of developers aren't working on even slightly tricky code, or at least if they are it's a minor portion of their time, a good dev should be abstracting over that sort of complexity so that they don't need to think that hard in the future.
So, using your logic shouldn't your boss fire you for being mediocre at hiring? Usually a team with all A players doesn't really work out anyway. They spend all their time pissing on each other and avoiding doing the boring grunt code. For every leader you need some followers that don't mind doing the crap code.
Interesting points. I do suck at hiring but I also think I'm better than average at it. Its just a really hard problem where if you are really bad at it in some absolute sense you are actually pretty good at it in a relative sense. But yes if I was significantly worse than the average of my peers then my boss should fire me. I'm not trying to get all A players and I agree with your comments regarding that. I also edited my question as I see "very mediocre" isn't what I meant. Have you ever seen a below average developer turn into a better than average developer?
I'm a software developer and I have been managing developers for 20 years. There have been many cases where I hire someone and after a couple of months I think "this person isn't doing as well as I thought they would. They aren't totally incompetent and they show an occasional flash of insight but over all, if I had it to do over I wouldn't hire this person." Should I fire this person? HR and others say "you need to work with them and try harder to train them and get them up to speed". I don't think mediocre and sub par developers grow up to become good or great developers. They do get more experienced but mediocre interns turn into mediocre young programmers who turn into mediocre middle aged programmers.
Full disclosure. I fully admit that I suck at hiring but it isn't from lack of effort. I've read a lot and I've tried many different approaches and it is the single hardest professional task I've ever had.