Five Dimensions of Competency, redux

I have written in the past about the Five Dimensions of Competency as defined by Workforce Skills Qualification (WSQ). At the time, I was learning about WSQ and was about to be tested on my knowledge, so writing about it seemed a good way to really drive home the knowledge.

This theory seemed sound, until I found a better teacher - a real, living example.

This guy was a colleague, a fellow software developer who lasted exactly one year in the organization. And when you're a contractor, serving your first contract with the company to completion isn't that big a deal. In fact, if it's a renewable contract which doesn't get renewed, it's almost akin to a termination of services.

Now, I'm not saying this guy was lousy. He was young, energetic and possibly technically better than me. But as mentioned, competency is measured in five dimensions. Today, we're going to take a look at dimensions of competency where he did and didn't make the grade.

I'd like to say that this guy wasn't a bad guy. He was easy to get along with. Not terribly mature, but at the age of thirty there's plenty of room for growth.

1. Task Skills

Individually, this is where he shone. His technical knowledge was solid enough. He was certainly able to code. But of course, it has to be said that if software devs were judged solely on their ability to code, a huge portion of us would pass quite easily. The other stuff matters just as much, if not more.

The ability to write code.

Unfortunately, while his code worked, he had this tendency to be slipshod where code formatting was concerned. He didn't indent or space out his code properly, and even remarked to me on more than one occasion that these things were not important. He left rubbish comments all over the place - comments that made sense to him alone.

You know the kind of guy who writes "fixbug" in commit remarks? He was that guy.

Not only did he do all this, he didn't seem to understand why it was such a big deal. Not that I don't make mistakes, but when they're pointed out to me, I tend to know why they matter.

Knowledge: Pass
Skill: Pass
Attitude: Fail

2. Task Management Skills

Task Management Skills are mostly about prioritization, and here there's not much to say because as far as I can tell, he was never assigned anything substantial and therefore never had the need to prioritize.

Working overtime.

A plus point: he had no issues working overtime to get shit done - what was suspect was the need to put in that much overtime in the first place. Diligence wasn't the issue; how much of that diligence was productive, was the issue. I recognize this because I've had the same problem in the past.

Knowledge: ?
Skill: ?
Attitude: Pass

3. Contingency Management Skills

Most of our work was implementing new features, and fixing bugs. This guy could code, but sometimes his bug fixes didn't solve the problem, and even resulted in new bugs. He seemed to have an aversion to testing his code.

Bad patches and fixes.

I mean, we're talking about the really simple stuff here. If the bug is in a formula which is supposed to produce a result, isn't it reasonable to expect that if you applied a fix, you would test for the correct output?

Nope, he didn't do it. One of my strongest memories was asking the QA to reassign a bug fix to this guy because I was being swamped with work, saying "it's so simple, there's no way he can screw this up". The QA didn't look so sure, and after the "fix", I realized just why. The output was still wrong.

Now, at this point, this wasn't a matter of aptitude. His heart just wasn't in it.

Knowledge: Pass
Skill: Pass
Attitude: Fail

4. Job Management Skills

Now, this is where he really tanked. Where writing code was concerned, we had to ensure that our work was maintainable, and as mentioned earlier, he just didn't think stuff like appropriate comments, proper indentation and spacing, was all that important.

But that's just one thing.

You see, as professionals, we have obligations other than writing and testing code. As contractors, we also had to fill in our timesheets and clock our hours. He received multiple warnings for failing to do so.

Locking your workstation.

The most important area where he dropped the ball, was security. Not coding security, but basic security such as locking his screen when he went for a smoke break, or even leaving his docking station unlocked the entire damn day. None of these had anything to do with programming; it was just good old-fashioned sloppiness.

Knowledge: Fail
Skill: Fail
Attitude: Fail

5. Transfer Skills

Just like me, his coding skills were applied to different contexts. There were various parts of our work that required us to pivot to vastly different tasks. One day we could be working on the back-end, and another day we could be writing Stored Procedures and generating reports.

Using different tools.

The tasks I was assigned to eventually turned out even more different - APIs and DevOps as opposed to just front and back end programming - but that wasn't really his fault because those were assigned after he had departed.

Knowledge: Pass
Skill: Pass
Attitude: Pass

Conclusion

This entire exercise isn't about denigrating an ex-colleague just to look good. No, I was actually thankful for his presence. If it wasn't for a negative example to take reference from, I might have made some of these mistakes as well.

I know I've said it before, but this bears repeating - being a dev is not just about coding, and competency is not just about knowing how to code.

I have a lot to learn, and hopefully with more people making mistakes for me to observe, I'll learn a lot faster.

Competent regards,
T___T