Colin doing a Derek

It was a nice surprise when former team member Colin sent me a review. There was some existing code that basically used an ID to look up some data from a local cache. It was written in a way that implied that one result should always be returned. The ID number does not come from the user, it will (originally) come from the database if you trace the code back far enough.

Anyway, Colin had changed the code to allow for 0 results. Just like the story I told about Derek in https://strangercodingtings.home.blog/2019/02/07/derek-origins/, Colin is basically hiding an error from the user. So began an argument in the review:

timeinints:“if we have an ID, how is it possible that this doesn’t find a result”

Colin: “I don’t know, this is a question for Paul” <link to Paul’s original change>

timeinints:“this is clearly a data issue. Paul’s code works as intended.”

Colin: “My change prevents the crash. I don’t care about it finding a result, the information it retrieves from there isn’t applicable in my case.”

timeinints: “A crash signifies to the user that there is a problem. Preventing the crash hides the problem, and the user will miss potentially key information. Just because your scenario doesn’t use the extra data doesn’t mean you can change it; all the other scenarios require it.

Colin: “Just to explain this problem: The user has a task which they can Accept or Reject. This problem happens if the user Rejects it.”

timeinints: “If they Reject it, should it clear out the ID because it no longer exists then?

Colin: “On further investigation, there are other scenarios where this can occurs. It’s a bigger problem than I anticipated”.

<facepalm> I think it’s quite disheartening that I can spend less than a minute looking at an issue and can categorise a problem better than Senior Colin. Not much thought had gone into finding out the root cause of the issue. He has gone straight to the “paper over the cracks” approach. That mentality is deserving of a demotion to Junior Developer.

Bye Derek?

Recently, Derek has been “Working” From Home due to not being able to drive to work. After we finished the development of our project, the developers needed to chip in with Regression testing. We had a chart to track our progress, and I thought that would motivate Derek to work; but that wasn’t the case.

After 3 days, I looked at the chart. I had ran 35 tests, and Derek had run 3. What has he being doing? Obviously not working. Anyway, days later, he announces he is leaving the company. OK, that makes sense, he was out doing job interviews in company time.

Our company has many employees that have left and then come back at some point. So even though it is sad that Derek is leaving, I believe he will be back. I’ll give him 3 months. I assume he will be on a probation period, and I’m sure if a company thinks they are getting a Senior and then Derek turns up, they will be backing out of that deal. Then Derek will come crawling back.

The two main inspirations for the Colin character have moved teams, so in that regard; the blog has taken a massive hit this month.

On the positive side, I’ll be starting a new project soon and will most likely be working with new people with new technologies.

It’s quite possible the blog will be a bit quiet for the time being. But hopefully it’s not the end.

Small Project: Complete

So after we finish our long-lasting project, myself, Derek and the Junior Developer were assigned to a small project. This involved adding a few fairly simple extra features. Derek was assigned to lead this small team.

I thought it would be interesting how Derek takes on the challenge, since in a smaller team, his incompetence would be more obvious. Sadly for the blog, he did pretty well. As a side note, since I wasn’t working with the main inspiration for Colin, and he is moving teams; there’s a lack of Colin ideas for the blog too. For whatever reason, external teams stopped sending me code to review too; so I have been a lot focused on my own work.

Anyway, as we neared completion for the final development work, we were relying on a third party to provide us with an API call. It was a simple true/false value we needed, and if it was true, we would display an icon next to the data items. As a temporary solution until we got the new API call, we chose a property which would roughly give us a 50/50 split of true/false values. That way we could check in our changes and see the icons next to a decent amount of data; a representation of the final product.

Anyway, by the time we got the new API call, Derek had booked a week off. That wasn’t a problem since all I needed to do was switch out everywhere we used the temporary property and use the correct one. Easy task. However, I changed all the places and one feature wasn’t working. Just so happens to be the only place where Derek didn’t use the agreed temporary solution, and chose a property that was always true, so always showed the icon.

In all the other places where we use it, once the data is there, it is never changed. However, this particular control, you can select a data item, then change it for a new one. Therefore the image should show/not show depending on your new selection. Of course, we couldn’t see that this feature didn’t work because all the items were always showing the icon.

Did he use the wrong property to intentionally cover the fact it didn’t work? Of course he did. I thought it would be easy to change, but the control had all kinds of dependencies and it wasn’t designed to refresh the image on a new selection. Took me the whole day to sort out. Massive twat.

Understanding Key Points of a Project

(I had this blog drafted up last month, but didn’t finish it. Anyway, here it is.)

In this blog post, let’s say one of the main features of our Project (that has lasted over 1 Year) was Identification Numbers. These Identification Numbers have a certain format so some are easy to identify as invalid.

Derek posted on our team forum if anyone knows if some Identification Numbers were invalid or not. Our Lead Developer saw me looking at the post and he goes “It’s not like he has been on the project a year or so, is it?” and he shakes his head in disgust. I joked “shall we tell him to ask a developer?”, and he said “he should ask a Senior”. Banter.

Recently, I was looking at some Test Cases that Derek had run. Derek is the kind of person to be oblivious to a lot of things, and I’m the opposite. So I know that he has no idea that the testing software has a keylogger. If you run the Test Case in a certain way, the software will create a text file and attaches it to the test results. That way, if you come across a bug whilst running the Test Case, you have some reproduction steps of what you clicked and typed. Anyway, in I go, snooping for lols.

“I know this sounds dumb since I have been on this project a year or so, but I don’t know a lot about Identification Numbers”

Derek in an Instant Messaging conversation to a Tester.

Classic Derek. He is incompetent and he definitely knows it.