Review Of The Performance Review

For context, it’s best to read my initial blog on this topic: Appraisals

Our review system basically involves us stating some salient things we have done, and we have to rate it against a few categories of values, and rate it 1-4, but we are only really allowed to score it a 3.

So my Performance Review is complete. To nobody’s surprise; I was scored a 3. My manager asked if I was surprised by the score, and I said I wasn’t because that is what everyone else would have got. She said that some people did get a 4. Not sure how; it doesn’t make sense to me.

I think if I went above my role, I’d expect push back from someone. Imagine waltzing into another department like Support with the aim of being “collaborative” – and start demanding changes. Then they are like “who the hell are you? Someone call security!”. If a development manager went in there and started demanding changes, then people would listen. In reality, they would organise a meeting, but their meeting would be accepted, and mine wouldn’t. The reason is that I’m just a developer and have no authority. Yet, if it did happen, I can then tick the boxes of Collaborative Working, Initiative, Innovation etc.

Even trying to take the lead on a project is a tough one. People’s job title’s give a natural hierarchy. When you have a designated Lead, then some Seniors, what chance does a Developer have at even running a meeting, never-mind designing some architecture? The only time it’s gonna happen if people are on annual leave for multiple days or have extended leave. Then you have to spot the opportunity, and take it.

In another meeting, I was talking to a different manager, and raised my concerns about the review process. He then told me that someone in the team got scored a 2.

How? If you read my previous blog on Appraisals, I mentioned how I tried to score myself a 2 for some areas, and I got rejected. If you talk about your score with your manager in your monthly 1-to-1 meetings, even if they did tell you that you have scored a 2 that month, then you will just step up your game, or write more justifications on the sheet to make sure it doesn’t happen again. Even if you did score 2 for 3 months or so, then are scored 3 for the final 9 months, surely your overall score would become 3 anyway? So how can you end up with a 2 unless you have consistently under-performed, done nothing to correct it, and even agreed with your manager that it is fine to be scored a 2? Surely no one in their right mind would do that.

The only reason I can think of is if the scoring hasn’t been consistently applied. Now if you read my previous blog on Appraisals, I mention that we have arrived at this current process with the aim that it is the fairest way of assessing someone, and would be consistently applied.

So let’s talk about the consistency.

Firstly, the goalposts were constantly moved during the year. We were told to fill out a basic spreadsheet, then a month later, new columns were added, then the criteria was changed, then we had to add a personal objective in addition to the default ones. Then there was an additional sheet to fill in. Then near the end of the year, someone told me the criteria had changed, but yet my line manager never told me that. So by the end of the year, some teams were using a different system.

Secondly, sometimes people with the same line manager as me told me extra tips, or about approaching deadlines, but my manager had somehow forgot to tell me about it.

Thirdly, we were initially told our final score mattered and there was no chance of promotion during the year. Then half-way in, an email comes in from HR saying how there is a Mid-Year mini review where some people will be promoted, and we had 3 weeks to submit our forms. However, that same day, we get an announcement from a manager in the department stating that 3 people had just been promoted…but yet they hadn’t completed their forms; the Mid-Year review hadn’t happened yet. For the Mid-Year review, I was struggling to finalise it, and my manager said I had till the end of the week, and she would submit what I had by Monday because it’s a hard deadline. On Monday, when the deadline had apparently passed, I overheard her say to someone else that they had until Wednesday.

Fourthly, even though I said we have monthly 1-to-1’s where we agree a monthly score for the items we submit, one member of my team said he hadn’t done that since the Mid-Year, and he had to cobble something together to submit for the End Of Year Review.

The thing is, because of the poor management of projects this year, there’s been many moments where I have been idle. When we have had requirements, they haven’t been clear and there hasn’t been great scope to actually shine. So if you compare my productivity to previous years, maybe you would give me a 2, rather than 3, but that’s not even really my fault.

I also think any metrics shouldn’t change people’s behaviour. However there was one time where I heard someone say something along the lines of “I have been investigating TechnologyX but it’s not really feasible.” Her colleague then said “so are you free to pick something else up?”, then she replied “no, I’m going to investigate it further so I can add more detail to my appraisal documents”.

In a similar fashion, there are plenty of times in the stand-ups where people say “today I am updating my documents” or “I am doing personal development”. The fact that people spend entire days updating a document instead of doing actual work – is a massive problem.

I also think people try and introduce ideas just so they can tick some boxes for innovation on their documents. I don’t see any reason why teams would switch from Code Build, to GitHub Actions, then Jenkins unless there is some extra personal incentive.

I think if the review system was consistently applied, was set-in-stone rather than constantly evolving, and we had no surprise deadlines spring up on us; then the review system would be acceptable. I feel like I can only give this system a 1 out of 4.

Hopefully it will be better next year.

GitHub Actions are Secure

In a previous blog on GitHub Actions, I have mentioned how some people love trendy technology and want to use technology when it may not be suitable.

Today, I was reading some documentation a team had put together which justified why they use GitHub Actions.

A standard team will have their code stored on GitHub, and when new code is ready to be checked in (via a “Pull Request”), a build is triggered on AWS (Amazon Web Services) CodeBuild. If successful, then you can use the built code to deploy to a test system, and to the live server.

The reason specified by Simon why to use GitHub Actions was that it is “self-contained, so is therefore more efficient and more secure”.

I know that GitHub actions use Microsoft’s Azure platform, and I assumed that GitHub store their code on their own servers. So with GitHub Actions, Azure will take the code from the GitHub server and build it, whereas CodeBuild takes the code from the GitHub server and builds it…no difference at all.

Well, there could be a speed difference if Azure is better than AWS or vice-versa, but the claims of “self-contained”, “efficient” and “more secure” is all conjecture.

I did contact Simon and he used some interesting phrasing along the lines of “No idea if it is better or worse, the statement was meant to address the concerns at the time.”

What? He wrote it just to please his colleagues/managers even though it was pure fabrication?

“hey Simon, we need to set up a build process”

“OK, I’ll set up GitHub Actions”

“One thing we forgot to add, security is the utmost priority. We want the most secure tech available”

“Yeah, you cannot get more secure than GitHub Actions, I’ll show you it in this documentation that I wrote”.

“Oh wow, it is really secure”

Fictional dialogue exchange

I did try to research if my claims of GitHub having their own servers is true. This blog is quite old, but back in 2015, they did use their own servers.

“At GitHub we place an emphasis on stability, availability, and performance. A large component of ensuring we excel in these areas is deploying services on bare-metal hardware. This allows us to tailor hardware configurations to our specific needs, guarantee a certain performance profile, and own the availability of our systems from end to end.

Of course, operating our own data centers and managing the hardware that’s deployed there introduces its own set of complications.”

https://github.blog/2015-12-01-githubs-metal-cloud/

The Problematic Button

William had a problem where his form controls could not be focussed; so you couldn’t click a button. He blamed me for breaking this functionality:

“You added a button which is clickable but you disabled everything else”

I told him it was a simple HTML button with an onClick handler; there was nothing fancy, not even CSS applied to it. I hadn’t changed any other component.

I asked him how he knew it was me that broke it. I asked him if he has verified his outlandish claims by removing the button and seeing if the problem persists.

Of course he hasn’t, he just looked at who had made a change last. I asked him if he had seen it working before – since this was a new page he was adding. He didn’t even seem sure.

Turns out it was some CSS that broke the functionality, but this code had been there a while. No idea why he didn’t notice it before, but it definitely wasn’t my button.

Obsoleting Your Codebase

William sure has a knack for saying the wrong thing, leading to lots of wasted time.

His team had been using our repository to check in their example code. Our repository’s purpose is example code, so it fits nicely in there in my opinion.

He comes over to my desk and claims that developers will wonder where they need to go to find the example code, so he wants them to go to a new repository he has just created.

How are people going to find his repository if they somehow can’t find our repository?

Well, his idea is that his repository will also deploy a website with instructions on.

How are people going to find his website?

Well, he hasn’t thought of that point. He also stated that when he moves the code to the new repository, it will make our codebase “obsolete”.

I was really annoyed by this. Firstly, if you create a new repository and move all the code from an existing repository, all you have essentially done is renamed the repository (and wasted a lot of time). Secondly, why does he think his repository is more important than ours? Surely it should be agreed with the team, rather than just pulling rank and forcing his ludicrous ideas through.

I firmly put my point across and then he replies:

“I’m not making your codebase obsolete, I’m just moving my code out of it. None of your code is going anywhere”.

WHY DIDN’T HE JUST SAY THAT THEN!?

I still think it is dumb creating another repository, because now there will be two repositories to check for example code, and all the example code is currently in the same location. If a website is actually helpful, then it can be added to our repository.

Your Code Is Unstable

William sure has a knack for saying the wrong thing, leading to lots of wasted time.

William joined the stand-up and said that he needs a “stable” build of our code, so specifically wanted the Lead Developer to merge our latest changes into our “master” branch. He kept on saying our “master” branch was “unstable”.

Later on, he comes over to my desk, and I ask him what he means by “unstable” – since that implies there is some kind of crash and we didn’t know of any. He then replies:

“it doesn’t work”.

“what doesn’t work?”

“eeeeeeeer”.

He then asks another team member to explain, and his colleague ended up saying “the branch doesn’t build”.

Weird I thought, since it is a “gated build”; we can’t check in unless the build completes. Turns out the Lead Developer had bypassed the gated check and broke the build.

So we have gone from “It’s not stable”, to “it doesn’t work” to “it doesn’t build”. I don’t get how you can be that bad at communicating such a simple development concept.

Additionally, on the stand-up call, I felt it was very patronising to specifically ask for the Lead Developer to do a basic merge. As it turns out, he meant that the Lead Developer should sort it out because he broke it, but he never stated that was the cause of the issue. It would have been good to open the conversation with that fact. You know; give some context and background to what the problem was.

Indian English

I always knew there was English (UK) and English (USA) which has minor differences in spelling e.g. localize instead of localise, and words/phrases like “sidewalk” instead of “pavement”. UK folk can understand it fine, although we often joke about it not being “proper English”. In recent years, I’ve sometimes worked with Indian staff and quickly came across some strange words and phrases.

So it turns out there should be a English (India) too. Here are some classics:

  1. Today morning” instead of “this morning”
  2. Have some doubts” instead of “have a query/question”
  3. Prepone the meeting” instead of “bring the meeting forward”. Prepone is the opposite of postpone. I actually really like that one. It’s incredibly logical and is easier to say.
  4. to do the needful”. This one often throws me off. I think it’s like “please action this”, or “do whatever is required”.
  5. Kindly revert”. Indians love prefixing sentences with kindly. Apparently “revert” means “respond” which is just weird. This causes confusion when they leave this as a code comment on a Pull Request/Code Review. You think they are telling you to roll back your changes, but they just want you to respond with a reply.
  6. The same”. They use this instead of “it”, sometimes it sounds fine, other times it is really jarring. “Can you fix the bug and update the documentation for the same”.

Bonus one: Some people pronounce GitHub as “JitHub”. This probably is in the same category as the pronunciation of the Gif image format.