Working On The Wrong Project

This post, How do I tell my boss I’ve accidentally been working halftime on the wrong project for the past year?, appeared on Stack Exchanges Hot Network Questions, and it is an interesting story. Is it true though? It’s definitely hard to believe.

Even though the process and management where I work is a bit slack sometimes, I just can’t imagine this scenario could possibly happen. There’s too many failures that have to happen for it to get to that stage.

A tester starts a new remote-based job and is assigned to 2 projects. 11 months later, he realises that he was only supposed to be assigned to 1 project, and was wrongly invited to the initial meeting because he shares the same name as another staff member.

When he has one-to-one meetings with his manager, he has somehow talked about work in a way that the manager didn’t realise he was working on the wrong project.

He eventually meets his team in person, and it seems some people knew the other staff member with the same name, but not enough to realise this person wasn’t the same.

I have no idea how this can actually happen.

There’s definitely going to be situations when you realise two people have the same name in your company, and especially if it is you that shares the same name. Someone emailing you by mistake; receiving an email from the other person; seeing a post on whatever chat app they use eg Slack/Teams.

Surely you have daily stand-up meetings where you talk to your team. Someone would surely realise you aren’t the person they expect, unless they all accepted it was a different person, but then they wouldn’t act like you were the other person when you physically met up.

If they really did believe it was their original colleague on the project, and there were no meetings, surely one of the team members would have communicated to the other person to ask them how they are getting on.

If the organisation only assigned a Tester to 1 project, surely there would be a point where you say you were too busy with “the other project” and would be challenged. They must be assigned to a couple of projects as standard, but then that means this person should have been assigned to a third project. It makes me wonder what the other guy was doing. The original poster says they were “focusing on other work”. Probably chilling for a year then 😀

If you have to log your time, surely a manager would realise something isn’t right when they look at the overall figures, or just your own..

If this Tester was comfortable doing both these projects, doesn’t that indicate Testers are actually underutilised and are only working at 50% capacity? I do think Testers could easily get assigned more work but they always seem to claim they are really busy.

It’s a mystery.

The Changes #3 – Tech Stack

Recently, we have a new CTO and a new Head Of Development. Like all new managers with power, they want to make their own changes.

In The Changes #1, I explained changes to job titles of Testers. In Changes #2 I explain that Developers are also affected.

Our previous management decided our upcoming software would specifically use the cloud service AWS, whereas the new managers want a “cloud-agnostic” approach (work with all the clouds!). So they want us to have the possibility of using one, or a combination of: Azure, Google or AWS – although the emphasis seems to be moving to Microsoft’s Azure.

Currently, I don’t think there is much rationale for this. Everyone specifically learned how to use AWS, so will need some time to adapt to the differences. When people started learning about Cloud Technologies, the problem of “Vendor Tie-in” was raised and instantly dismissed by the previous management. It makes sense to ensure you have that flexibility, because if your provider increases their costs, then you can easily migrate if you had the architecture for it.

Another change is that they want every product to have their source code in GitHub. Maybe it does make sense to have all our products in the same place. The reason we have them scattered is mainly because our products were acquired by a series of acquisitions, so the original companies had chosen their own languages and technologies. However, our core, flagship product is already in Azure DevOps, and given that the main cloud provider is going to be Azure, surely it makes sense to keep it all in one place?

These changes to jobs, processes and technologies seem to have solely been decided by the CTO and Head Of Development. I feel like they haven’t discussed these ideas with the Development staff at all. I’m intrigued by what other arbitrary changes will be forced on us. With any change, I think you always have to ask yourself “what is the problem we are trying to solve?”. If you can’t explain the problem, then it shows you are making changes just for the sake of it.

Recently, I have been reading Sir Alex Ferguson’s “Leading” book and came across a great quote:

“There is no point suddenly changing routines that players are comfortable with. It is counterproductive, saps morale and immediately provokes players to question the new man’s motives. A leader who arrives in a new setting, or inherits a big role, needs to curb the impulse to display his manhood.”
Sir Alex Ferguson (ex Manchester United football manager)

I thought it was a very relevant and appropriate quote for this situation.

The Changes #2: Demotions

Recently, we have a new CTO and a new Head Of Development. Like all new managers with power, they want to make their own changes.

In The Changes #1, I explained changes to job titles of Testers. Some Developers are also affected.

Currently, the hierarchy is basically Junior, Developer, Senior, Principal, Architect. With the new changes, we planned on removing the Principals so they will become Senior.

When I think about it, there aren’t that many Principals, and their job is really the same responsibilities of a Senior. To be honest, there isn’t actually any difference in responsibility between the standard Developer role as well.

I actually like these titles though. If implemented correctly, it gives you a clear indication of people’s skill level. With the new titles, if managers created 2 teams consisting of 1 Senior, 3 Developers and a Junior in a team. If one team’s Senior is a standard Senior, and the other team’s Senior is the former Principal, then this second team has a massive advantage because they have a leader that is at a significant skill level. I know it’s not a competition, but developers will want to be in successful teams.

With job titles, if you manage to persuade a promotion, then your wage should jump up to that band. If you remove the level, then it puts the power towards the employer to suppress your wages. It’s much harder to justify an increase if you don’t accept more responsibility (or have a title that implies responsibility, even if there actually is none).

I can’t speak for everyone, but a better job title is a massive motivator for me. I have been suffering low motivation for a while because my team members see me as a Senior but I have just had the Developer title. It hasn’t happened many times, but there’s definitely been a few occasions where I felt people haven’t accepted my idea because someone with a Senior job title suggested something else – so they automatically sided with them. So I think you automatically gain respect among certain colleagues.

If I had earned a fancy job title and my employer took that away from me, I would be very angry. If it took people a long time to gain that title, it would be devastating. I guess that means that Colin should have moved back down to Senior which is a much more appropriate job title for him.

However, after about a week, this idea was silently squashed. I found out because I asked a Principal Developer what he thought of the demotion, and he said it wasn’t happening due to the amount of negative feedback the managers received.

The thing is though, surely anyone with common sense would know that people weren’t going to react positively. If the managers were willing to back down that quickly, then how did the idea even get to the stage where managers agreed to announce it to the department?

The Changes #1: Attempt To Replace Manual Testing

When it comes to Testers, we have hired some fairly non-technical people as “Manual” Testers, but then on certain recruitment drives, we have hired “Technical” Testers which performed manual testing but also have the scope for Automation testing.

When we announced that we would soon be starting projects that will build our next product, managers stressed the importance of defining new processes and upskilling with new programming languages. Moving into the “new world” where you expect things to be automated; there isn’t much need for non-technical people.

I did warn one of my Tester friends about this – that his days could be numbered, but he didn’t listen. He waited for several months, and then seemed to think “damn, I’d better get learning because there is literally no work otherwise“. Meanwhile a few people requested a promotion so they can be a manager, which is unfair really; but there’s always people that benefit from restructuring.

Anyway, another year has gone by and the projects have been a disaster. I don’t think they really went through with their “no need for manual testing” approach, although some people did move back to support the existing product to do manual testing on a familiar product.

In comes a new CTO and a new Head Of Development, and now, yet again, their new idea seems to be 100% Automation.

I expressed my concern to my manager. It didn’t go to plan last time, and you may find that some manual Testers simply leave the business since they have no plans/desire, or might not have the ability – to do automation.

Earlier in my career, I used to do manual testing and it soon became a tedious and boring job. If you actually find people that do it for a career, then they are probably worth keeping around. In my opinion, you always need manual testers.

Another thing is that you are assigning an inappropriate job title to those people. The automation testers have the weird job title of “Developer In Test”. If you are currently a non-technical, manual “Senior Tester”, how can you suddenly be a “Senior Developer In Test”? This implies that you not only have technical skills, but you have achieved Senior level in it. It’s a joke. Demoting the Senior to the basic “Developer In Test” would make sense but would probably cause them to be disgruntled and leave.

When I previously wrote about job titles, I used Colin as an example. I’d say he was an underperforming Developer, but got promoted to Senior. Simply calling him a Senior doesn’t mean he has better skills. Then another couple of years pass, and somehow he gets promoted again to Principal Developer. I wasn’t happy about that, and questioned my manager. He could only explain it as “we had a vacancy and a strong need for a Principal in the team”. But if Colin was already in the team, what good does promoting him to Principal do? He doesn’t level-up like a computer game character and gain extra productivity, coding skills, code reviewing skills and leadership. We needed to recruit externally to add another person to the team, but also increase the skill level.

So with these new changes, I asked my manager, “why are we changing job titles?” and he said “we are following a new Agile framework that the CTO is implementing”. Surely we can still follow the framework without copying job titles word for word? All it does is cause some staff to be disgruntled.

When another manager was explaining the team structures, he said

“there’s a thin line between “Software Engineers” and “Developer In Test”
Manager

He said that means that Developers can help Testers but then seemed to struggle how to justify how Testers can help Developers – because it turns out they aren’t actually the same.

Conclusion

New managers like Heads of Departments or CTO’s love making changes.
100% Automation is a dream. I think you always need Manual Testers.
Changing job titles can cause people to become disgruntled.
1. It could feel like a demotion.
2. It could feel like more responsibility for the same pay.
Assigning a job title to someone automatically doesn’t give people those new skills.
Testers don’t have the same skills as Developers.

Crying At Work

I saw this statement posted online by a software developer (I won’t name them as to not call them out directly, although you could probably find it if you searched hard enough) and thought it was rather odd:

“Crying at work is normal and it happens to everyone”
Sad developer

As expected, people responded, telling her this isn’t normal. I would have thought it would be due to

Toxic working environment
Bad/bullying managers (maybe ties into point A)
Personal issues; not work related
Maybe hypersensitive person

The thing is, if the job is that bad that it makes you cry, then you probably need to leave. Personal issues are understandable to cry, and it can easily happen in work-hours, but then it’s not “normal”; as in an everyday occurrence. If it’s a personality trait of such an individual to easily cry, then again, it is not “normal” because the average person wouldn’t react that way.

I asked one of my colleagues what he thought about it:

“if your work makes you cry, that’s quite a clear indication you should move on”
colleague

So he has the same line of thinking as me.

The original poster tries to clarify, ruling out that it’s a problem with the company culture or particular members of staff.

“If your job is making you feel upset or unsafe, that’s a different problem. But I often feel overwhelmed with coding and cry it out.”
Sad developer

This makes me think it is more related to point D, or maybe there’s not enough team support. If it gets to the point where you have been defeated, there should be other developers that can help you solve the problem.

She then posts a response to all the people that are still telling her it isn’t normal:

All the people saying “this isn’t normal, you shouldn’t cry at work“: there was the pandemic, many people are isolated and struggling. If I want to cry at work, I will. To anyone who thinks otherwise, I wouldn’t want to work with someone of that mentality.
Sad developer

For me, this ties into the personal issue scenario. This one is understandable but it’s not really work related. I’d say that can be partially solved by supporting team members and managers.

The thing is, I thought they were backpedalling a bit here, and rather than retracting the word “normal”, they were still trying to justify their statement. Additionally, the theme did sound familiar, and I did some more searching to see if I could find a previous quote from them. I was correct, I had read this before. This was from a time people worked in the office:

“I wish I could go back 5 years and tell myself that there would come a day when I wouldn’t cry at work each week and I would feel confident in my programming skills. It takes a long time but at some point you’ll realize how far you’ve come.”
Sad developer

Each…week. Damn.

So they were definitely trying their best to justify their statement rather than retracting it. It wasn’t about the pandemic at all, they just cry when their code doesn’t work, but they won’t accept that it’s not a normal reaction.

I think telling people it is normal is bad advice. I’m still going to stick with my opinion that it’s either a terrible place to work, or you have issues. Advising people to not leave the toxic job, or to not seek help for whatever problems they have – is definitely bad advice.

However, to play devil’s advocate and argue with myself, I did a quick Google search and found a few articles that quote the job site Monster who (apparently) performed a survey with 3,000 respondents. Apparently 8 out of 10 people have cried at work. Of those:

45% stated it was because of their bosses or co-workers.
19% stated personal, non-work issues.
15% stated workload,
13% said they were upset over workplace bullying.
I assume 8% were other reasons.

Note I stressed the word “apparently”. Weirdly, all of the articles I found didn’t link to Monster, and I searched Monster’s website and also tried to use Google to find the source. I saw evidence of a survey for that time, but no statistics on crying. There’s also an article about crying, but then it links to one of the news articles I found! Why would Monster quote a news article that says Monster did the survey when they could just quote themselves.

So what are we concluding? I’m one of the emotionless 20%, or crying isn’t normal and there’s some weird conspiracy.

Skype Isn’t Outlook

Our software has some integration with Microsoft Word and Outlook. I needed to test compatibility with the Word and Outlook desktop apps for Office 365. I posted on Slack to ask if anyone in the department had access. We all have o365 online access but not the licence to the desktop apps. However, I knew some software Testers had done a project to do with Office integration, so thought they may have it.

A Tester, Rob messages me, stating that if I go to office.com, there should be a download link for the apps. I told him I had already clicked it and only have Skype for Business.

He said he had options for all the apps. So I told him to install Outlook. A few minutes later, he says:

“When I click install, it takes me to a screen and only shows ‘install Skype’, but then complains I already have a version of it. I’ll try the 32 bit version instead”.

So let’s reiterate this situation. I have told him to install Outlook. He has seen a box labelled “Skype for Business”, has clicked a button labelled “Install Skype”, a message box has told him he already has Skype installed…then I have to tell him that it’s not what I want. Only at that point does he realise he has exactly the same licence as me.

I don’t understand why we seem to have so many people working in a technology company that struggle with basic concepts. I don’t see how Microsoft could make that webpage clearer that the section is for Skype; it says Skype 3 times, then the installer says Skype.

Absolute wind-up.

The PS4 controller

Years ago, my team was in a meeting room and the presenter was struggling to get his laptop connected to the TV display. There’s normally a HD cable on the desk which goes under the carpet and into the TV. Although there’s often multiple cables, some go to other devices like the projector.

There was also a Playstation 4 next to the TV. I don’t think anyone actually ever played it since it was in a meeting room, but I think it was added because another one of our offices had a “breakout” room with a PS4, and someone complained about how unfair it was.

There were a few technical people trying to decipher the problem, then a manager (who often seemed a bit clueless) picked up a PS4 controller and started pressing buttons whilst declaring “is this doing anything?”.

I think the situation was so absurd that it then became unfunny. That situation should have caused me to howl in laughter, but instead, I actually felt concerned…

Why would pressing buttons on a PS4 controller help connect a laptop to a TV?

A similar situation happened with another old and clueless member of staff called Ron. Ron wanted to dial Steve in on the standup, so he was supposed to open Skype For Business. However, he went to Google Chrome and randomly clicked one of the shortcuts on the bookmark toolbar, and was like “where is it?” and Paul was like “wut? you need to click the Start button and open the application”.

It’s strange when you work in the Tech Industry and some colleagues aren’t comfortable using hardware and software.

Test Coverage

The “Test Governance Lead” announced that all developers will need to report on Unit Test Coverage. We explored similar demands several years back, but we soon realised it was a rubbish metric. How do you measure Unit Test coverage? There’s a few ways and they all have limitations on their accuracy and usefulness. Teams were also adding “attributes” to the code (ExcludeFromTestCoverage) which also manipulated the figures.

My opinion is that it’s okay to report on as long as you just look at the overall trends and don’t overreact to the actual figures. If a figure says 50% and there’s never any problems with the code, and the figure is still 50% in 3 months time; then it is all good. The problem is that managers just look at the figure then start putting pressure on developers to do something about it because they want the number to be higher.

An experienced developer responded to the “Test Governance Lead” with a blog post which opens with the line

“Let me use one of my son’s toys to explain…”.
https://danashby.co.uk/…/code-coverage-vs-test-coverage/

What a great opening line for a blog. It’s like a passive aggressive statement from the developer there. He didnt directly insult the “Test Governance Lead”, but indirectly called her naive/dumb by using the blog.

Years ago, on multiple occasions, I witnessed a developer talking to one of the high-ranking managers, boasting about his 100% test coverage. He was obviously trying to manipulate the manager’s impression of him to increase the chance of promotions.

Not so long ago, there was a team that kept on boasting about their 100% test coverage, yet developers using their code library were telling them that major functionality was broken.