

Do below average developers ever turn into average developers? - asbestoshft

Have you ever hired a developer and after a couple of months thought they were below average and perhaps they should be terminated but you kept them on and a year or two later they had really become a star developer?<p>I&#x27;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 &quot;this person isn&#x27;t doing as well as I thought they would.  They aren&#x27;t totally incompetent and they show an occasional flash of insight but over all, if I had it to do over I wouldn&#x27;t hire this person.&quot;  Should I fire this person? HR and others say &quot;you need to work with them and try harder to train them and get them up to speed&quot;.  I don&#x27;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.<p>Full disclosure.  I fully admit that I suck at hiring but it isn&#x27;t from lack of effort.  I&#x27;ve read a lot and I&#x27;ve tried many different approaches and it is the single hardest professional task I&#x27;ve ever had.
======
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.

------
sharemywin
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.

~~~
asbestoshft
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?

------
User9821
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.

~~~
asbestoshft
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?

------
baxter001
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.

~~~
asbestoshft
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 ).

~~~
baxter001
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.

