Month: Jul 2021

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.