Remote Standup Meetings

We have a daily “standup” meeting where each person in the team says what they did yesterday and what they are going to do today. You can also highlight any “blockers” that will prevent you from completing your work.

Since we are all working remotely, we just do them using Microsoft Teams. At first we just nominated someone to speak next, but since we have around 10 people in the team, and people don’t really listen or pay attention, then we ended up with people asking: “has everyone been?” – when only half of the team has been.

When Microsoft Teams introduced the “Raise Hand” feature, we used it as a flag to show who still needs to talk. Still, Colin says “who is next? Matt have you been?”. Yes he has been, why don’t you choose one of the 6 people with their hands raised?

Another point which illustrates that people don’t listen, is when I say something like “I’ve sent a Pull Request for my work but no one has reviewed it yet, can someone review it?”. Then three hours later, no one has reviewed it.

I think the problem is often that people are so focussed on what they have to say, then they don’t listen. I was watching a video about it and the guy reckoned the “walking the board” method gains more attention. This method is where you look at your “Kanban board” which shows you all the work your team is doing. Then you can go through each item in turn, and the relevant people can then speak up. I still think you’ll have the same problem since you know that you will have to speak when it gets to your work.

There are a couple of people that seemed to nominate people without even looking at the attendees, so then they end up in embarrassing situations where they say “Rob can go next”, but Rob isn’t actually on the call. Sometimes it was well-known that they don’t actually work that day because they are part time.

We also have someone in our team that just deals with Test Environments so isn’t directly involved in our work. We did raise the point that it is stupid for him to attend the stand-up meetings but our manager said he wants it to continue so he feels part of the team and also gets to hear the team talk. I guess that is a good point – since we are at home, we don’t get to hear our colleagues speak much.

His updates are so boring, and he delivers them in a really bored tone. I often think he doesn’t have much work to do, so just says words to blag it:

had to restart some servers, and upgrade some RAM.
signed off some policies, and am looking at patching some security vulnerabilities.
I sat down with Dan for a bit and went through some tickets. Got some other tickets. Need to review some policies. Still need to complete some security vulnerability patches.
Busy doing environment stuff, mainly security updates which I’ve almost finished. Just need to do some Virtual Machines today. There’s about 40-50 clients so that’s going to take the full day, maybe tomorrow as well.
Catching up on comms, am currently resetting a password, and then gonna look at some more environment tickets.

How long does resetting a password take? Is any of that actually useful to the team anyway? He may as well just say “Environments stuff” then choose the next person.

Another thing that always happens is when you pick someone to go next and you are met with silence. So you say “you are on mute!”, then a few seconds later “oh yeah, sorry I was on mute”. Here are some classic “mute” scenarios that I wrote down:

Becky: “Good morning Colin”
*few seconds of silence*
Colin: *bland tone* “good morning”
Becky: “You sound down, Colin”
Colin: “I said ‘good morning’ but I was on mute, so that's my second attempt.”

James: "Can everyone see my screen ok?"
*silence*
Becky: "yeah, sorry I was on mute"
Colin: "yeah, sorry I was on mute"
Matt: "yeah, sorry I was on mute"

Matt: "Colin, have you been?"
*silence*
Matt: "You still have your hand up"
*silence*
Matt: "you are also on mute"
*silence*
Colin: "I'm on mute? how did that happen?

And a bonus scenario:

Becky: "this meeting has started early!"
Colin: "who started it?"
Matt: "it was you Colin"

U-Turns

On the back of “Testing and Developer Equality”, Colin highlighted some minor problems in the code base and made a statement of “Any Tester should be comfortable picking up these items and writing code to fix it”.

One of the Testers spoke up and said “Not all Testers are comfortable, I for one have no interest in coding. Please don’t ask me to code”.

Then Colin quickly u-turned and said “I never said all Testers can code, but the ones that are interested in learning can pick these up”.

That’s not what you said Colin.

U-Turn #2

A Tester asked for help diagnosing an issue he found, and asked who could debug the problem on the Test Environment. Colin replied, and made a statement about having to install some debugging tools and how it’s going to be difficult because it’s a server-side problem.

Many developers have made comments in the past on how it’s basically impossible for us to debug server-side issues with our infrastructure (we can obviously run the client and server locally on our own computers, but sometimes problems are with specific data on the Test Environments).

Recently, I tried it to see what the problem actually is, and it worked perfectly fine. No idea where this myth came from, but it’s been passed on for years. You don’t actually need to debug the actual server. You can run the server locally as long as it is the same version. You just need to point towards the Test Environment’s databases rather than your own.

So after Colin’s statement, I described my findings about debugging the server and data.

Colin then responded “I never said that you cannot debug the server”.

I knew he was talking nonsense. He was definitely implying you cannot debug the server. I also remember he said it a few weeks prior. I searched Slack for his post history and I found it.

“If server side, then we have to try to recreate the issue in our own environment.”
Colin

I don’t get why people can’t just seem to admit they were wrong and be grateful for your information. I normally write something like “oops, I was mistaken” and then choose a funny emoji like 😖or 😜

Merging for 3 days

There was a project in a code branch that needed merging in for the release. Colin volunteers to do it. I expected that it would take him half a day, depending on if there are conflicts to resolve which can be quite tricky.

3 days later, he sends it for review. A couple of developers reviewed it and left him 17 comments of “is this your change?”

Colin responds to them “No I’ll remove it.”

How has this happened? How can he mess it up so bad?

There was a project that I worked on where we delivered it in two stages. We merged our changes in, but there was one feature where we discovered a problem so we reverted one file.

Another team had merged from the master branch into their project branch to take our original changes. When they merged their project branch into master, they wrongly resolved the conflict and reintroduced the problematic change in that one file.

No idea what Colin did though, it’s almost like he had merged a different branch into his branch then had merged it to master. I’m out of theories. It took him 3 days and he had clearly messed it up.

Testing found 4 bugs with the project (which may be original bugs missed in the original testing before it got merged in). How many have they not found? That’s what worries me.

Report Ideas

Our Team Lead had been hyping up how important it is to improve the statistics of our codebase. So we have a report that runs and gives you metrics about duplicated code, “code smells”, possible bugs, test coverage etc.

Our Team Lead said that Colin had some great points and would be presenting them in our meeting.

and Colin’s points were

Can we add rules?
Can we remove rules?
Should we document our changes?

Which are all basic questions and not any kind of guidance. Obviously, the answers are

obviously,
obviously,
and the majority of the time, no; that would be overkill

He also did a demo to illustrate what we can include in our documentation. The “code smell” was that there was the same assignment twice like:

somethingEnabled = whatever!=null && somethingElse!=null

otherFeatureEnabled = whatever!=null && somethingElse!=null

So the assignment logic is the same. Then he said the solution is to create a new variable. Yes, that is obvious…. but he has some timing tests to illustrate the performance difference of 0.00025 seconds. Since he has proven that this is the correct thing to do, we now must document that as the official solution.

Embarrassing. So cringey.

Then the next day, Colin was talking about his work item and said if he has permission, he would also fix the “code smells” that were declared by the reporting software. So the Team Lead asked him what the “code smells” were and Colin said “unused using statements”.

Since when did developers ever declare/ask for permission for something so trivial? We just did it because it’s obvious. Even Visual Studio tells you to do it. “Unused usings” are shown in a lighter font, and you have an icon in the side prompting you to remove them. It’s part of the Code Cleanup feature too, so you run it and it automatically removes them.

Any developer would just do these refactorings as standard.

There’s a general rule called DRY; Don’t Repeat Yourself that means you should avoid duplicated code. We don’t need to document that any further.

Other code smells like extra blank lines, spelling errors, unused methods; are all trivial. You don’t need to explain them. The reporting software actually has explanations and examples for all the rules anyway.

Meet The Team

So I’m in my new team now, and it’s pretty much like I expected. There’s one good Senior developer, some good testers, some bad testers, then a few bad developers. The ratio of developers to testers is a concern, because there’s way more testers than developers, and the standard of developers is poor.

Guess who the bad developers are? The Colins are here, and so is Beavis. Completely called it (see A New/Old Adventure).

The good thing is that I can definitely look good compared to everyone else. I did say there is one good Senior, although I don’t know much about him. He does have a good reputation in the company, so I expect him to be much better than me. He is part-time though.

The more I explain about this team the worse it gets doesn’t it? Part-time staff, incompetent developers (Colin), a developer that doesn’t show up (Beavis), too many testers.

It’s good for the blog, if nothing else.

Mini Musing #5: It Doesn’t Compile

I was having a nosey at the latest Pull Requests and there was one from Colin. Usually, there’s a good few mistakes in his code. The Lead Developer comments:

“Does this even compile”

To which Colin responds:

“No, lol”

He never learns. How many times does he have to make these mistakes to realise that: if you make a change, then test your changes? When there are unit tests, it’s a simple as clicking a button, then waiting a few seconds.

Ignoring Instructions

I was about to leave work when Colin asked me if I knew how to set up a messaging system. I said I couldn’t remember the exact details but I’ll have a quick check because I was sure I had written a guide on how to do it.

Anyway, I emailed him some details. I attached a security certificate to the email but explained it was probably expired, but he could grab a current one from the test servers. I also added a SQL script to modify his database settings to match the certificate.

The next day he never told me he had problems, but I heard him talking to the Lead Developer about his issues around 11:30. The Lead Developer told him that he hadn’t updated his settings. When Colin showed him what he had changed on his database, the Lead Developer told him he had updated the wrong table.

How could he have updated the wrong table? I had sent him the script.

Anyway, 10 minutes later he got it working with the Lead Developer’s help. Another developer comes over and asks Colin what he did to fix it. Colin says “my certificate had expired, and I had updated the wrong table”.

So the two things I told Colin to do, he didn’t bother doing. If he had followed my instructions he could have saved around 2.5 hours.

Code Amnesia

On Monday, Colin was struggling to recreate a bug even though he had recreated it on Friday. I knew he had been struggling for a few hours, so I decided to go over and talk to him. I always love a challenge of recreating obscure bugs.

He gave me a quick demo of what he was doing, and gave me a quick glimpse of the code.

I went back to my desk, and within minutes, I had successfully recreated it. Then I asked him what the difference was between my version, the version he recreated on, and the version he was struggling to recreate on. I knew my version was a version or so behind. The test environment he had previously recreated it on could have been updated Monday morning. So it seemed the simplest explanation is that someone had already checked in a fix sometime on Friday.

Then I remembered part of the code he had showed me, and thought that one of the methods sounds like it takes this scenario into account. So I ask Colin to show me the code again. I read the code.

Timeinints: “That code should stop this issue from happening. “Who wrote it?”.

So Colin annotates it. The annotation states “Local”

Timeinints: “Colin, you wrote that code”

Colin: “Did I? I don’t remember.” He stares at it for a few seconds. “Oh actually, I did write that as a speculative fix, but then I couldn’t test it out at the time”.

So he had spent most of Monday trying to recreate an issue he had already fixed on the Friday. He just didn’t remember fixing it.

Shirking Responsibility #2 – Email

We had an email from the Product Owner asking who could pick up a bug. It was sent to Adam, Bruce, Colin, Dave, (all of which are Seniors) and myself.

Colin responds quickly, stating that he thinks Adam or Bruce would be suitable. Adam then responds with more questions about it. After a few days, the Product Owner chases it up, to which Adam then states that he doesn’t think it was his responsibility and it would be better if Bruce or Dave looks at it. Bruce then replies stating that Timeinints would be the best person, but maybe Dave.

I couldn’t believe all the Senior developers had just basically played the blame game, deferring it to each other until the last person has no one to palm it off to.

Anyway, I went to the team lead to tell him to pick someone, knowing full-well he would just ask me since I was the one talking to him. I didn’t mind doing it, but wanted to basically say “look at these losers trying to avoid work; you need someone dedicated who will accept responsibility”.

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.