Programming language hierarchy
#279 Henry, Tuesday, 15 September 2015 3:27 PM (Category: Programming)
(Tags: programming hierarchy pyramid)

We recently hired and lost a programmer. I'll call him Bill.

When we interviewed him, I tested him with the FizzBuzz test, and the countdown test. He needed prodding to get these out. I assumed he knew what he was doing and he was just nervous. In future, when I give these tests, I will give no prodding and any applicant who can't whip out an answer immediately will not be considered.

So Bill started with us. I gave him a series of Unix tasks to get him up to speed with our network topology, where things are located, and the tools we generally use. It was a series of exercises that should take an afternoon.

Bill went into the dark. Took a week. And the result was a PDF where he had copied the output of tools. I would ask "look through the logfile and tell me what time this error occurred". He would paste the output of a grep into a PDF and give that to me. The first thing I noticed was that he would not follow instructions. He would follow what he thought were instructions.

We got through all of that, and I gave him a programming task. It was C. Change an if statement to include an extra clause. We're into minimal changes here. Make the least amount of code change to achieve the desired result. It was a clean task, should have taken an afternoon at most. Simple logic test. His first version had two lines changed. Both changes were wrong and introduced serious errors. How can 15 characters cause so many problems? I persevered and got him to try again several times, and every time he would come up with seriously wrong changes. He would either introduce errors, not address the new cases, or leave gaps in logic. He could not get anything that would work. After two weeks, we needed to go live with it. I tossed his stuff out, knocked out the changes in an hour (including testing, version control and documentation), and we went live with it.

He had been with us for about seven weeks, so it was time for a performance review. I told him that he was very slow, and I wasn't happy with his programming abilities. I suggested ways to improve this. He was shocked at this. Shocked that I wasn't considering him to be a first-rate programmer, a rockstar programmer, a guru. That was his experience so far in his other jobs. I confess that I blurted out "You've got to be fucking kidding" and that did not go down well either.

Next task was another C task, a bit more complex. Still, should have taken an afternoon. Three weeks later, he was still floundering. We had gone through multiple iterations, and he just wasn't getting it. He didn't have to write much new code. He just had to reorganise some code. He wasn't able to focus on parts, break things into parts. He would fiddle with this part down here, then fiddle with that bit over there, and just diddle around without demonstrating any clarity. It was obvious he didn't know what he was doing. We needed to go live, so I tossed his work and knocked it out in an hour and we went live with it.

Time for another review. This did not go well, and I suppose I should have expected it after telling him that I didn't think he was a programmer and he should look for a new career. He insisted that I was wrong and he would prove me wrong.

I didn't want to work with him after this. It took so much of my time working with him that I was falling behind. I handed him to my co-worker, who refused to spend any time with Bill. I think my co-worker did not want to be responsible for making a decision that might get Bill sacked. So it came back to me. I gave him another task. A Python web service. I detailed what it would do, what inputs, what outputs, how it worked, what testing, what tables, everything. By the time I had detailed all this stuff, I could have written the damned thing. Once I did that, my co-worker got involved as the support guy, to answer questions. After two days, my co-worker came to me and said he agreed with me that Bill was not a programmer. His code was awful, his understanding was awful, he couldn't look at a task and break it down, even if I had already broken it down for him. He was not a programmer. We approached management about getting rid of him.

In the meantime, Bill was so unhappy with my assessment of him at our last meeting, that he decided not to wait. He went looking for another job, found one, accepted it, and resigned. He gave a scathing exit interview to my boss's boss, and I was blasted for my intolerance and unhelpfulness, and all blame was placed on me for him leaving. He didn't have to stay the week out, so he left on the spot. He said goodbye to no-one, just packed and left.

Whew. We dodged that one, and we didn't have to fire him. He jumped before he was pushed.

My boss has a theory about hierarchy of programmers. I've drawn it by hand so the diagram looks really crappy.

Programmer hierarchy pyramid

Programmers can move up the pyramid, but they cannot move down. So if you get a programmer started with Python or Ruby, that's about all they can do. Someone who started with Java can move up to Python or Ruby, but they can't do lower level stuff.

Most of us here started at Assembly or machine code (not shown in the pyramid). We can function at all these levels. The knowledge we have of the lowlevel stuff helps us with the high level stuff. Programmers who come in at the top have no idea of lowlevel concerns and write terribly inefficient and stupid code.

And the Dunning-Kruger effect applies here too.

That's my boss's theory, and I think there's some truth in it.

0 comments