Promotion Special

One reason I thought writing a blog would be good is that it would document my software engineering story to become a Senior Developer. That was always my ambition when starting out as a Junior Developer – to become good enough to be recognised with a fancy title.

An industry standard for Senior is probably 5 years experience, but that’s just a rough guide. I mean, 5 years of consistently being bad shouldn’t get you promoted. I’ve written about Performance Reviews in the past, and stated how the process never seems to work, or not for me anyway. So I think it’s been more like 6.5 for me.

Recently, I reflected on my promotion from Junior Developer to Developer in the blog Comparing to Others, and that was to build up to this one. Obviously you can tell from the blog title and the words that I have written so far – I have been promoted. Senior Developer. So let’s reminisce and discuss the movements over the last year or so

A few years ago, I was working on our upcoming software, but I was asked to return to the previous software I worked on, with a strong hint I would be promoted. In my performance review, my manager Chris then made some excuses why I couldn’t be promoted and hinted it should happen in January 2021. But in January 2021, Colin got promoted and I didn’t. He moved from Senior to Principal, so there should have been a free role available. My team members think I am a far superior developer to Colin, so how does it make sense that he is now 2 ranks above me?

My team members started being annoyed. I had people say to me they were frustrated I wasn’t being respected. Even Colin said he had been talking to the Head Of Development about how insane it is that I hadn’t been promoted.

everyone “technical” thinks you should be a Senior

Colleague Developer

and all the Spanish think I am a Señor

Me

I changed managers and my new manager said he would look into my claim that I was underpaid and would try to find out how to come up with a solid plan to also get me promoted. However, I had a performance review with him, and in the review, he read out the feedback my previous boss gave me, although Chris’ notes were vague. So he asked me to explain the “unprofessional comments”. I explained that I have a running-joke where I state “the project is in ruins” when theres a minor change to the scope. It’s an exaggeration and purely in jest, although someone in the team has raised a concern about it. I was really grateful for his response because he laughed and said the person that complained was wrong to do so. However the reason why I panicked when he first brought it up was – I remembered that I responded to Chris’ question on Slack a few days prior with the text “lololololol”. So I then realised that I hadn’t taken Chris’ comments on board whatsoever.

Months went by, and my new manager assured me he was trying his best to promote me but was just getting pushed back by managers. Eventually, after another team restructure, I changed managers again.

In my first one-to-one, my manager asked if there were any concerns I had with the company. I stated that I was underpaid and was getting overlooked on promotions so dropped hints that I would be looking to move on. A week later, he calls me and said he was “absolutely shocked” at how low paid I was so would be taking it to HR urgently because we can’t afford to lose great developers like me. He managed to get a £5k payrise although HR still insisted to underpay me for 2 months before they actually gave me it.

Another month went by and he confirmed I would be promoted. I stated in the past, HR don’t allow big payrises so would probably say I’d already had one and reject the request. He assured me he wouldn’t stand for that. He kept his word, although yet again, there’s a compromise. I get a further £7k but have to wait 6 months until they approve it. HR are just the worst. You would think they would know how to make staff happy. That’s their job, yet they treat people like numbers and not humans.

The good news is that I finally get a good salary and it matches the respect I get from colleagues. It’s not even a change in responsibilities either, so I got £12k extra for doing exactly the same job as before. I probably should have been on this wage/role at least a year beforehand though. Don’t get me wrong, I was grateful for my previous wage. I always remember the times I was unemployed and have known many friends to struggle on low paid/part-time jobs. It’s just frustrating knowing someone could easily join the company and be on a much higher wage than you, and sometimes you even hear underperforming colleagues boast about their higher wage.

The thing is, in the past, our performance reviews have changed several times and we have tried: filling in a form; interviews; filling in multiple spreadsheets and forms; manager’s opinion only – and you could say none of them have worked out for me. It was only when I essentially hinted at leaving did I get the promotion. It shouldn’t be this way. Great people can leave, and the most confrontational get their way. Surely, that is the worst system.

I think I can easily be happy with my job title and wage now. I shouldn’t be complacent because you never know what the future will bring. Maybe one day, I could even come up with an idea about how to fairly appraise people, because we obviously have no idea, and I’m pretty sure it’s a common problem in the industry.

Department Update – Interview With Colin

We had a department update where the Head of Development, Head of Programme Management and other senior managers were doing presentations on aspects that are happening in the department.

I was well shocked when the Head of Development said he had a special guest, and the next section is Interview With Colin. He was being interviewed about the performance updates and the important bug fixes his team was doing. 

The thing is, his team has one of the best developers, David, and David had done ~90% of the work. Colin’s work was minimal and the work he had done didn’t work at all, until other developers had helped him.

Yet there he was, taking the credit for the work by doing this important-looking interview. The annoying thing is, when the Head of Development asked if he wanted to give any “shout-outs” he named several people, but didn’t name David.

There was even one improvement that was hyped up, but that was the first time I had heard about it. So I asked David when that was implemented. He said it was done by a different team, but Colin was basically claiming credit for leading it.

I don’t know how Colin has wormed his way to such status, but he seems to be held in high-regard by management.

Comparing to Others

I came across these quotes a while ago and thought I’d blog about the topic at some point.

“Comparison is the deadliest thing we can do to ourselves because we will always come up short. All it does is it exaggerate all of our insecurities,”

Simon Sinek

“It’s healthy to grow our own strengths rather than being intimidated by the strengths of others.”

(I think this was also Simon Sinek, but it wasn’t clear in my notes)

I have seen similar advice in tech blogs and this very much links in with the problem of Imposter Syndrome.

However, I think I have the opposite approach. I think it is very difficult to gauge how good you are as a Developer. After a few years of experience as a Junior, I had a one-to-one with my manager before an upcoming performance review. He asked “how do you think you are performing?” and I said something along the lines of “I just do my work and I’m okay at it”. He responded along the lines of “that simply isn’t true. You’re much better than that. Try to answer that again”.

I didn’t know what to say, but then he said “compare yourself to your teammates” (who were mainly developers but there was one other Junior rank, but all had years more experience than I had). When I thought about it, I realised that on average, I was probably just as productive as they were, but had a higher quality record (as in Testers didn’t find bugs in my code). Aside from the Team Leader, I also did the most code reviews, and people appreciated my reviews. When Testers needed help, they often came to me because they thought I was helpful, friendly and knowledgeable than my peers.

I said these things to my manager and he said he had already decided that I was ready to be promoted, so I’d lose my Junior status. I was well surprised because I’d never thought I was that good. I’d never considered I’d be close to a promotion until that very meeting where I just compared myself to my colleagues. I’d left the meeting a bit shocked. I’d finally be a “proper” Developer and maybe I was a lot better than I thought I was.

I still find it difficult to assess myself, but when I think about my team members, it is easy to see my qualities and what I offer to the team. There’s loads of developers that I know are significantly better than me (but they often have higher ranks anyway), but then sometimes that’s a good indication of what I need to work on. 

It’s good to think of people who you don’t rate very highly, and think about what aspects justify that opinion. These aspects are traits you value and could be your strengths. If these aspects aren’t currently your strengths, they are what separates the good developers from the bad ones, and gives you aspects to work on. 

I always considered what makes Colin and Derek bad developers, and then I pride myself on what I do differently. Mainly it comes down to: my attention to detail, care for the quality of the codebase, being able to debug more effectively, and being able to review other people’s code.

Maybe it depends on your personality type. Comparing yourself to others could lead to confidence issues and Imposter Syndrome. For me, it’s exactly what I need for the opposite feeling; not relating to poor developers such as Colin and Derek justifies that I’m good at my job.

It also raises the point that maybe managers shouldn’t wait until people ask to be promoted. Those that are bad at appraising themselves will be left behind, whereas those that are deluded will get promoted.

Terrible Colin Logic

The developer job titles are essentially: Junior, Developer, Senior, Principal, then I guess you have Architect which could be seen as a rank above that. Colin is a Principal. In this blog, I document his struggles with simple Junior-level concepts. Using simple AND and OR logic is a prerequisite to being a developer in the first place.

Let’s say you have 4 possibilities which we will label with the letters A, B, C, D and we have some code that checks a variable is one of these types (or not).

He wanted to write some logic that says “Not A or B”. In the programming language C#, “||” is the logical OR, and “!” is NOT which inverts it (so “true” goes to “false”, “false” goes to “true”). So we can denote “Not A or B” as !(A||B). Here it is as a “Truth Table” of how it should work.

Item is (A||B) “A Or B” !(A||B) “Not A or B”
A truefalse
Btrue false
Cfalsetrue
Dfalsetrue
“Not A or B”: !(A||B)

but instead, Colin wrote !A || !B (“Not A Or Not B”).

Item is!A “Not A”!B “Not B”!A || !B “Not A Or Not B”
Afalsetruetrue
Btruefalsetrue
Ctrue true true
Dtrue true true
“Not A Or Not B”: !A || !B

So A returns true because it is not B. B returns true because it’s not A. C returns true because it is not A. D returns true because it is not A. So the statement is always true.

A developer points out that it’s nonsense so he has another go. His new method was

A || !B || C || !D

“A Or Not B Or C or Not D”. It’s getting really confusing now, but also returns true for everything.

Item is A!BC!D A || !B || C || !D
Atruetrue false true true
Bfalsefalse false true true
Cfalse true truetrue true
Dfalse true falsefalsetrue
A || !B || C || !D

I couldn’t believe he has come up with more nonsense and still not tested it. I didn’t want to tell him exactly because he should be able to tell that he has done it wrong if he glances at that logic, so I left a simple comment along the lines of “this won’t work”. 

Later, after I got back from lunch, I saw that I had a missed call. So I send him a message “If you are calling about my comment, just test your method”.

He calls me back and starts explaining the requirement. I said that I don’t really need to know, I just know the method wasn’t what he wanted. I ask him to look at the method again. It took him 30 seconds or so before he spotted it.

Colin: “Why did I type the exclamation mark? I must have copied and pasted it. I’ll correct this line and you can review it”.

Me: “Aren’t you going to test it?

Colin: “No, this will work this time

Me: “Well, you thought the last two times would work. I recommend you look at the logic a bit longer if you’re not going to test it”.

He looks at it for 10 seconds.

Colin: “Oh there’s another exclamation mark. I’ll change that too”.

He got it right with a bit of supervision, but I don’t think he had much intention of testing it.

Increasing Customer Satisfaction

There’s been a big push to increase customer satisfaction, and the Head Of Development is actively monitoring the biggest issues seen by our users.

Colin has been looking at the most frequent errors and trying to proactively fix them. One “frequently occurring” error is from a group of users that need to log into multiple organisations. 

For this to work, you have to have both client versions installed and use a launcher to log into the correct version. However, instead of using this tool, they are just using the same client but logging into an organisation assigned to the other version. The version difference between client and server causes crashes when using certain features.

Our software wasn’t initially designed for this since 95% of users just log in under 1 “organisation”, so support for this requirement has been retroactively added (the launcher), but it isn’t perfect at the moment. 

There’s a team working on better support. Until then, we should instruct users how to use our software correctly, then release an update to stop this from happening.

So the “frequently occurring” error is that these users are not using the launcher, then encountering crashes when they try to use certain features. However Colin aims to “fix it” by adding some defensive code. All that will happen is one particular server call will now “succeed”, but there will be loads of other server calls that will have the problem.

If the user now sees a particular feature is now supported, but another feature isn’t, then surely they may ring Support and ask why it isn’t supported. Support will tell them they aren’t using the software correctly, but the user will say that we should support it because we have addressed similar issues before.

I discussed my concerns with Colin and he eventually agreed to cancel his changes. 

Really, the endgame for Colin isn’t to please customers, it is to please the Head of Development who is aware of these errors. If he sees that the errors aren’t happening anymore, then he will be pleased. We need to make sure we are actually addressing the root causes of the issues, rather than hiding the problems.

Regrettably Paused

About a year ago, there was one employee that posted an angry rant about the lack of communication between managers and development staff when big changes were coming. The managers actually responded positively and said they will work on it in future. Well, it’s happened again.

It seems she was working in a subteam on a project, and her subteam was never told their project was on-hold. She heard the rumours/news from someone else, and posted this rant before the managers fully declared it to the department:

If a project is “regrettably paused” or abandoned in future, please would you consider announcing this news in the form of a department-wide meeting, inviting all those who were involved with it?

This gives people the opportunity to ask questions or make comments, much like you would if a doctor was giving you bad news.

Developer on a cancelled project

We have had a tendency to cancel projects, big or small over the last year. Some have involved my work where I had finished development – and it only needed to be signed off by Testing. 

Another manager made an unrelated post about them sorting out the project plans and bug fixes. They said there were “300 pieces of work in various stages of the software delivery lifecycle. We’ve decided to continue 189 items, reject 35, and move 76 back to the Backlog for further review.” I don’t know the details of these changes, but I really hope they haven’t cancelled loads of inflight work. It’s just demoralising to have your work cancelled, and a waste of time when it wouldn’t be much work to complete it and get the new features out to users.

Maybe there’s nothing you can do about it. If managers insist we want to follow a new process, shuffle the teams about, then the current work basically needs to be abandoned otherwise the new teams cannot form.

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

  1. New managers like Heads of Departments or CTO’s love making changes.
  2. 100% Automation is a dream. I think you always need Manual Testers.
  3. 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.
  4. Assigning a job title to someone automatically doesn’t give people those new skills.
  5. Testers don’t have the same skills as Developers.