The YouTube Channel

A colleague promoted his YouTube channel which is the result of an amazing idea he had during the Coronavirus lockdown.

He thought it was clear that “people who didn’t have access to the internet, or lacked the basic digital skills would find this situation an immense struggle”.

So his solution is to create a YouTube channel where he makes videos on basic stuff like “how to use a mouse”, “how to use a touchscreen”, “how to navigate a website”.

There’s a major flaw in his idea.

How do people watch YouTube? Does someone print it out for them? No? So they have to go on the internet and use basic skills to navigate to YouTube, in order to watch a video telling them how to do so.

Even though he promoted it at work and many colleagues would have watched the content just to see what it is like – he only has 350 views and 12 subscribers in nearly 3 months. Don’t quit your day job.

Hoaxes and campaigns

There’s been a lot of hoaxes/campaigns/fake news in recent years, and sometimes a small Google search can easily disprove them.

I’m not even sure if there was an outcome to the campaign against the communication app House Party; which was accused of hacking into people’s bank accounts. Even one of my colleagues shared that one, and actively encouraged people to uninstall the app. I pointed out it was probably just a cause of reusing passwords, which also was the opinion of security expert Troy Hunt.

Another recent example is 5G causing Coronavirus.

Troy Hunt’s blog on Let’s Stop the 5G Hysteria: Understanding Hoaxes and Disinformation Campaigns is brilliant, so go and read his blog instead of mine.

Here is a summary of the headers:

Insight 1: You can tell a lot about the credibility of a claim by observing those attracted to it.

Insight 2: Understand the difference between people who have formed their own opinion versus those who are qualified enough to influence your opinion.

I enjoyed Zombieland, but not once did I stop and think “here’s a guy who looks like he’d know a thing or two about voltage-gated calcium channel activation exacerbating viral replication”. Yet here he is, broadcasting it to 2M Instagram followers. Fortunately, he’s since deleted the post.
Troy Hunt on Woody Harrelson’s level of expertise

Insight 3: Consider whether you believe a claim because the evidence supports it, or simply because you want to believe it.

Insight 4: When faced with alternative theories, consider which one is the simplest and therefore most likely to be true.

Insight 5: Question why you’re being encouraged to influence others and if you’re sufficiently informed to do so.

A New/Old Adventure

I received an ad-hoc meeting request with two managers. I wasn’t sure if the fact my line manager isn’t involved is a good thing or a bad thing.

One manager, Chris, explains that the business has acknowledged that our new software (currently in development) hasn’t really gone to plan. It’s nowhere near complete and Chris reckons our current software still has a good few years left in it and needs supporting.

The problem is; over the last few years, more developers have gradually switched over to work on the new product and now there’s a bit of panic that we don’t have the resources to adequately support the current product.

He plans to create a new team and lead it, and he wants me to be involved. Together, both managers explain that my ability and knowledge are a good fit for this team, and they could easily see me progressing and would be promoted quickly. They expect me to lead a sub team.

I am really tempted by this suggestion of promotion. It’s what I need, and probably should have had years ago. However, it ain’t in writing and is probably just a false promise. However, my current project does suck and I have lost motivation.

Also, I’m not impressed with my new line manager. Switching to this new team would mean Chris will be my manager and he does give me a really good impression. He seems passionate and organised, and doesn’t throw business jargon around to make everything sound important.

I still had reservations. The other manager detects the uncertainty in my responses. “What’s on your mind?” he says.

“Well, the good developers will want to work on the new, exciting product with all the new technology. Who would go back to work on our “old” product? Surely it’s going to be a team full of failures? People who can’t handle the ‘new world’.”

He laughs. “Oh, no, there’s some great people that have signed up already. Many are seniors.”

Now, I’m beginning to uncover their lies here. How can I lead a team if there are already loads of seniors involved?

Either:

There’s no seniors, and I can lead them
There’s seniors, but they are failed seniors. They know they can’t handle seniority, and will let me lead them
There are seniors, and it was a lie about me leading anything

I was also sceptical of my ability to learn new things. At least with my current project I was learning new programming languages. Going back to the old product is just working with stuff I already know. Chris did say there’s some cool projects coming up, and has the potential of using exciting tools/languages; but I remain sceptical.

I thought about it, and even though this Team/idea probably contains at least one big lie – I accepted the challenge. Hopefully if I get a promotion, then at least I can take the hit of the team sucking.

I fully expect I will be working with failures. I expect Colin and Beavis to be there as Developers, alongside some of the worst testers. There will be more idiots to pad out the numbers I’m sure. But if that’s true, then that’s brilliant news for the blog. There will be plenty of stories in this new team.

Discovering the Programming Process

An automated tester posts a blog which got loads of “likes” and comments from Managers. One example comment was “what a well-written and informative blog”.

I read it, then read it again, then read it again. I’m so confused.

He begins by explaining how they are testing an API using Postman and have a collection of tests that they need to check-in to source control. Fair enough.

Then they say how it’s a tedious process where each team member needs to download the files, try them out, then mail the developer/tester who wrote the tests with their comments, then the process repeats.

I’m thinking “what sort of crazy process is this? This is what Source Control and the Code Review process were invented for”. You have side-by-side comparisons (“current file” to “changed file”) so you can see what they have changed. You can write comments directly alongside the code for them to read and make changes.

I must be missing something.

Then he explains that they needed to decide where to save their files. The Postman software encouraged them to store the files in Postman’s cloud service. “No, we aren’t gonna do that!” he writes as if it is some kind of security risk to save your files online. Instead, he is gonna save them online in GitHub. I send him a message about it, and he admits that I’m right, it’s just that he felt Github was more secure.

My loyal readers will be thinking “Hang on, haven’t you come across this scenario before?”. Oh yeah, here it is: GitHub Actions Are Secure. Yet another staff member chatting nonsense to sound good to the Managers and hype up GitHub. “We are taking security seriously with our decisions! This software is more secure because I said it is”. Has GitHub hypnotised everyone or something? They must have some propaganda machine. I’m not saying it isn’t secure, but claiming everything else isn’t as secure without evidence is just weird.

He then says how they wrote their own test library in Javascript which slowed them down because you don’t get great autocomplete support in the IDE. I’m thinking “maybe use Typescript”. He then explains that after writing their own library, they discover Jest; the most popular Javascript testing library. Hang on, how did you overlook the most popular testing library?

He then concludes that it is best to:

Use GitHub for source control
Take advantage of side-by-side diffs, and publish feedback in this code review process
Use Jest for Javascript Testing
Use Typescript to give type-safety and autocomplete support in the IDE

Tell me something I don’t know.

Then managers are drooling over these revelations, even though this is common practice to Javascript developers and probably has been for several years.

I want to know how much time his team has wasted messing about. Surely they didn’t start the project pretending software development had just been invented?

Blinded by Job Titles

Earlier in the project, a Junior Developer switched teams to go work with William. I think the Junior saw it as a prestigious switch because the other team has a cooler name, and instead of myself educating him, he would be educated by William who has the Senior Developer title.

Obviously, I felt William would be a bad influence. One day William came over and moaned about how pointless one of our repositories was. To be fair, I did think it was a bit pointless, but the idea came from a Software Architect.

When this Junior Developer was in my team, he followed the Architect’s wishes and created the repository. He even did the initial implementation of the small library, and even made the changes when we needed to update a schema. At that point, I did challenge if we needed this code in a separate repository given that it is used in only one place. I said we should consolidate it. The Junior didn’t think much of this suggestion.

A few days after William had moaned about it, I was talking to the same Junior Developer about it, and he states “I don’t know why you guys even have that repository; it is rather pointless”.

I was annoyed, because all he had done was just copy William’s point of view. I think it comes down to the fact that I’m not a Senior so my concerns were dismissed, but since William has a Senior role, then his opinion is valid. Even though William mainly talks absolute nonsense, his job title seems to give him much more credibility in the eyes of a Junior.

That’s why it annoys me, because the Junior is just judging by rank instead of judging information based on the validity of the statement.

The Junior didn’t think it was pointless when he created the repository. He didn’t think it was pointless when updating the repository. Then all of a sudden – it is pointless.What I want you to take away from this blog post is that: You get good Seniors, you get bad Seniors. Rate them by their actions, and not by the job title. Don’t automatically accept what the bad ones say. Show respect to low ranking Developers when they say credible things.

Deliberately Deferring Work

The team was looking like it had failed to fix the bugs they had promised to do. With only a couple of days before the planned release, the managers need to make a decision. They talk about Seth, a Senior Developer who is regarded as one of the best in the company.

“Shall Seth jump in and fix loads of bugs?”

“No, because that will give a false impression of what the team can handle, then we will get too much work in the coming months.”
Team Manager

It’s like when it gets to the end of the tax year, and departments blow their money so that next year, they will get the same amount of budget allocation. If they underspend, then the finance department will likely reduce their budget since it seems they overestimated before.

In this case, we are reducing our commitment so we can keep our commitment low in future months. It might make it easier for everyone to manage, but is terrible for the end-user who has to wait longer for their bug fixes. It’s a really bad attitude to have. We should put quality first. If there are staff available, then use them to improve the quality.

The Code Location War

There’s a repository that contains basic UI controls owned by Team A.

Team B have some specialised controls and suggested that the more complex controls in Team A’s repository are moved over to Team B’s repository instead. Both teams were happy and agreed on when to do this.

However, a Manager from Team C stated that he didn’t believe this was the right thing to do. So much so; that he has then had a meeting with some other Managers who also agree with his viewpoint.

So let’s recap here. Numerous developers in two teams have agreed who should own some code. A Manager from a completely different team, and has no reason to care where this code is located; only that it works – is unhappy. Not only that, but he has also gone out of his way to drum up support from two higher-ranking Managers who have even less reason to care.

Why is this even a thing?

So an hour long debate was arranged and the decision was that the code should be owned by the original creators; Team A. I didn’t know the outcome of the meeting at this time. However, no one actually did anything after the meeting. There again, it wasn’t even handed over properly in the first place.

I found this out when I heard one of the members of Team A talk about how they are gonna address one of the Bugs in one of these controls. If this was handed over properly, those Bugs would have transferred over to Team B. I pointed out that Team B should be doing this work, and one of the members of Team A agreed with me. However, the manager of Team A, who was on the debate and should know the outcome of the meeting – was confused why Team B had “moved” (well, duplicated) the code into their repository. (The code was moved after Team A and Team B had agreed to do so, and it was this that triggered the meeting to discuss it. The manager of Team A should have also known this).

She then had to ask the manager of Team C what the outcome of the meeting was, and he confirmed Team A should own the code, and he also seemed unaware that Team B had taken the code. He then said he is going to organise another meeting with Team B to discuss the outcome.

How many meetings do we need? Why wasn’t the outcome of the debate passed on to Team A and B? Why are two managers who were involved in the debate confused about the original situation?

Another meeting happened at the request of Team B. This meeting was hosted as a conference call on Slack, and as I always rant; there’s a 15 person limit. This shouldn’t be a problem, because why would 15 people be invited to this meeting? Well, we don’t live in a normal world. The funny thing is, the Team B member that requested the meeting couldn’t even join due to hitting the limit. Brilliant.

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/

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.

Mini Musing #6: Expenses Risk

I overheard a conversation between a Tester and his Manager. The tester explained that he had purchased an online course on a programming language and he asked if he could claim the money back on expenses. When his Manager expressed doubt that the company would cover it, he then said “well, never mind, I knew it was a risk.”

A risk!?

The way I see it, he should have bought the online materials to become more knowledgeable because he is interested in the subject, not because it’s simply something he could get for free. Describing the purchase as a “risk” shows the wrong attitude in my opinion.

I do wonder if he regrets the purchase and wanted to get his money back via any means necessary.