Tag: Process

Making Yourself Redundant

I often find that managers end up writing jargon-fueled posts that don’t mean anything to me. It’s often just hype, or a slight change which makes no difference in the grand-scheme of things. So it just frustrates me or makes me laugh. I was talking to a friend about this topic and he said he loves it when they get the word “synergy” in there, so I was glad to read in in this post:

One thing is certain in life, and that is that change is inevitable. But change doesn’t mean it’s a bad thing; it means new beginnings, new opportunities, new ways to improve. Over the coming weeks we will see some change come to our Product Team. A new structure to bring synergy with our SAFe implementation so that we are better aligned than ever to deliver our hugely important product roadmaps over 2022.

Most notably, Product Owners will move to report directly into the appropriate value-oriented structure (Vertical Markets or Horizontal values).This change will reflect the need to provide autonomy to the relevant specialist areas enabling them to;

  1. make clear decisions on their respective priorities.
  2. bring the Product Owner and Programme Management teams closer together supporting their knowledge of the ‘Why’ and the customers that we are focusing upon.
  3. provide greater consistency of resources working on specific areas based on the technology/product/market in which they specialise

Certainly sounds brilliant doesn’t it? The next bit made me laugh though.

As a result of these changes, the role of Head of Product Owners no longer fits into the product structure and so, unfortunately, George will be leaving the business. He’s been heavily involved in designing the new structure…

Wait…what? He came up with this new team structure and forgot to put himself in it?

20 Patterns to watch for in your engineering team

Pluralsight have a free book “20 Patterns to watch for in your engineering team“

There’s no point in pasting the entire book in my blog, so I’ll just give the initial paragraph to highlight their ideas.

They are mostly negative ideas, or can be in certain situations. However, there are some positive ones such as “Bullseye Commits”.

PART 1 Work patterns exhibited on an individual level 

1. Domain champion

The Domain Champion is an expert in a particular area of the codebase. They know nearly everything there is to know about their domain: every class, every method, every algorithm and pattern. 

2. Hoarding the Code

This pattern refers to the work behavior of repeatedly working privately and hoarding all work in progress to deliver one giant pull request at the end of the sprint. 

3. Unusually High Churn

Churn is a natural and healthy part of the development process and varies from project to project. However, Unusually High Churn is often an early indicator that a team or a person may be struggling with an assignment. 

4. Bullseye Commits

This pattern is relatively common in most teams, but it often goes unrecognized: an engineer understands a problem, breaks down the project into smaller tasks, and submits code that has little room for improvement.

5. Heroing

Right before a release, the “Hero” finds some critical defect and makes a diving catch to save the day. More formally, Heroing is the reoccurring tendency to fix other people’s work at the last minute.

6. Over Helping

Collaboration among teammates is a natural and expected part of the development process. Over Helping is the pattern whereby one developer spends unnatural amounts of time helping another developer to get their work across the line.

7. Clean As You Go

A codebase is continuously evolving by nature, but it doesn’t evolve evenly across all aspects. A Clean As You Go engineer will notice and refine shortcomings even if it’s not essential to the task at hand. 

8. In the Zone

This pattern is exhibited by engineers whose work is, in a word, consistent. They have a knack for getting in the zone and shipping high quality work week in and week out. Their work is reliable and predictable in nearly every way. 

9. Bit Twiddling

Bit Twiddling is like working on jigsaw puzzle to the point where everything looks the same and you’re not making progress anymore. You might pick up the same piece, try it in a few places, rotate it, put down, only to pick it up a few minutes later. 

10. The Busy Body

The Busy Body is an engineer who skips all over the codebase: they’ll fix a front-end problem here, jump to some refactoring, then fiddle with the database over there.  

PART 2 Work patterns exhibited on a team-wide level 

11. Scope Creep

Intuitively, we all know what Scope Creep is — along with its associated risks. Still, there are plenty of different definitions for the issue so here’s what we’re focusing on:

Scope Creep (noun): a pattern
whereby the originally agreed upon
scope increases or changes after
implementation has begun. Often,
though not always, Scope Creep
happens incrementally and thus invisibly 

12. Flaky Product Ownership

Miscommunications between Product and Engineering can easily lead to Scope Creep. Flaky Product Ownership, however, can show up slightly different in the data and also generally requires a different approach 

13. Expanding Refactor

Expanding refactors happen when a planned effort to improve or revise a section of code triggers a dramatic widening of scope. 

14. Just One More Thing

“Just One More Thing” refers to the pattern of late-arriving pull requests. A team submits work, but then—right before the deadline—they jump in and make additions to that work. 

15. Rubber Stamping

Rubber Stamping is the process by which an engineer approves their colleague’s PR without giving it a substantial review. 

16. Knowledge Silos

Knowledge Silos are usually experienced between departments in traditional organizational structures, but they also form within teams when information is not passing freely between individuals. 

17. Self-Merging PRs

This pattern refers to when an engineer opens a pull request and then approves it themselves. This means no one else reviewed the work and it’s headed to production! 

18. Long-Running PRs

Long-running pull requests are PRs that have been open for a very long time (more than a week). A PR that doesn’t close in a normal amount of time (within a day) can indicate uncertainty or disagreement about the code. 

19. A High Bus Factor

“Bus factor” is a thought experiment that asks what the consequence would be if an individual team member were hit by a bus. 

20. Sprint Retrospectives

Retrospectives are a common practice that offer an easy way to continuously improve: take time to reflect, as an individual or a team, on a project, action, or occurrence

My Thoughts

There’s some good observations here, and the book does go into how to spot these aspects and what you can do to counter the negatives.

Where I work, we used to focus on having “Domain Experts” which is the “Domain Champion” idea. In recent years, I think managers have drastically swung the other way which leads to “The Busy Body” who knows a bit about many things but doesn’t specialise; so now we have the opposite problem.

There are a few areas where we still have a “Domain Champion” and they tend to get work related to that area if they like it or not. Even when it does get initially assigned to someone else, they take too long and then say “the deadline is approaching, I think the Domain Champion should do it”.

I always complain we don’t have many developers that are willing to do Code Reviews, or at least; do them properly, so you end up getting “Rubber Stamping” which is like having no review at all.

I personally like to “Clean As You Go”. It’s not a good idea to go far out of your way to change code that didn’t need to be changed. Doing so can dramatically increase the risk of introducing a bug and is “Scope Creep” since more areas now need to be tested. I do some “Heroing” from time to time, mainly because I do the most Code Reviews so I spot more opportunities to improve things, or point out bugs in their code.

Recently, with people quitting or moving teams, the Bus Factor has been severely lowered. Currently, I am the only Developer on the team, so if I take time off; then no work at all is getting done.

False Advertising Jobs

Intro

I’ve never been involved in the recruitment process to hire someone else, but have applied to jobs and read many job adverts. It’s a process that’s intriguing though, and I don’t think many companies get it right.

I’ve criticised performance reviews in previous blogs, and have stated it is very difficult to accurately judge someone. However, job interviews seem even more impossible to me. You need to come up with a good job advert to bring in the correct people to assess. Then your interview and assessments need to judge the best applicants.

Finding the correct people to fill a job vacancy is probably hard. I think you need to clearly convey what the job entails so people know if they are qualified and interested. You want all these people to apply for the job, whilst not wasting your time with people who aren’t qualified or aren’t actually interested.

When someone applies, you need to make a judgement whether to call them in for an interview/assessment. Anyone you reject through the entire process – is time wasted. Employing someone and regretting it is lots of time and money wasted.

I’ve seen many people come and go over the years, some quietly leaving and not even lasting a few months.

Here’s a collection of Job Advert stories.

Apprenticeship Schemes

When I first started my job, we had a special type of apprentice role where you start off as a software tester but then eventually become a software developer.

It sounded like a great idea; you get technical people joining, they then learn how the system works as a Tester. When they have the required development skills after learning with a mentor over a period of time, they can move into a development role. They will show their quality mentality from their Testing role, but also understand the requirements much more than hiring a new developer.

However, they joined, were never assigned a developer mentor, and were stuck as a software tester until they threatened to quit. It was just a scam. The company got technical and ambitious people that did a great job at testing. Those that were allowed to move to the Development role all became great developers. However, some actually moved elsewhere so they lost these good people.

It’s a fantastic idea if it is implemented as promised.

More recently, we hired loads of Apprentices via boot camp companies. Just like before, they never really got assigned a proper mentor. They mostly got placed in teams which didn’t have any direction on how to use them. A few months later, presumably someone highlighted this to managers and they were then moved to another team but without anything else changing.

They also had the promise of “Apprentices spend 20 percent of their time learning new skills and the rest based in the work environment”. We even published stories in newspapers with this claim. Maybe you could say 100% of their time were learning new skills because they were kinda just left alone and not really integrated into the team. Some quit after being frustrated that they couldn’t produce any valuable work. The better ones quit to find another software developer role, and the rest just seem to be happily taking the pay cheque for little expectations.

Having a nice spread of abilities: Apprentice, Junior, Developer, Senior, Expert is great as long as you have a plan of how to integrate everyone in the team. If you don’t have a plan for short term and long term, then there’s no point in hiring them.

Women are likely to apply if the job is accurate

See Women In Tech blog.

“Women working at HP applied for a promotion only when they believed they met 100 percent of the qualifications listed for the job. Men were happy to apply when they thought they could meet 60 percent of the job requirements.”

Hewlett-Packard

I find this statement bizarre. Most job adverts are basically just keyword spam and it is hard to ascertain what the job actually involves when they are being vague. If it really does reduce the number of women applying for roles, then why does it keep happening?

I’ve seen job adverts that we put out which may say something like “experience with VMWare” when you don’t need to know anything about how it works – you just need to know how to open sofware and log in. Or you see job adverts like “experience with React, Vue, Svelte” when you know the job is only going to involve one of them… but which one? If you have experience in React and have no interest in using Vue or Svelte, are you going to apply to it?

lorem ipsum

On a few occasions, our HR have put out adverts where the full text was just “lorem ipsum”. This is ridiculous. I mean, they have 1 job to put out adverts, and they just copy and paste a template and don’t even fill it in.

If people see that in a job listing, are they really going to take our company seriously? The fact that it has happened on multiple occasions means that they should change their process so it doesn’t happen again.

Cycle to work 

We work at home now, but yet still heavily promote the cycle-to-work scheme as a benefit. Recently we have promoted other “green” ideas like discounts on electric cars. If we don’t drive to work, then really it’s just a potential employee discount. Additionally, it’s not as directly aligned to the company values as they make out – they are basically encouraging more cars on the road!

Bad Impression

We are a tech company that makes various software products. However, our Job Vacancies page isn’t mobile-friendly – you have to use a PC to view them properly. Again, this is going to leave a bad impression and people won’t take our company seriously.

Conclusion

When it is hard to find the right people, and costly to recruit, it is important that you get every stage of the recruitment process correct. You need to get the right people applying, then your process has to accurately judge the best candidates.

Placing a “lorem ipsum” advert which doesn’t display correctly on a mobile device, and also promotes a cycle-to-work scheme on a home-working role – isn’t going to get many applicants.

Team Composition

Several months ago, new teams were formed and we were shown the proposed structure. I thought there were a few strange decisions.

When there’s a team of 8 people, what’s the chance that you would end up with 2 James’ and 2 Louises?

I swear managers like to go out of their way to be annoying :smile:

It’s almost like they think “how can we maximise the communication problems?“

If I was choosing teams, I would notice this, and would swap teams to remedy this. I can understand it might not be possible due to job roles and skill sets, but I’m sure most scenarios could be avoided. I’m sure these teams were chosen randomly rather than having any rationale.

Another team had Jack and Jacqueline. I pointed this out to Jack and he didn’t think much of it… until some members of the team referred to Jacqueline as “Jack” and the conversation became confusing.

The team that I recently moved to involves a third party API which is locked down to only allow network traffic from the UK. (I don’t know why the test API has these extreme restrictions – probably unnecessary “red tape”). It should be obvious to managers that this team needs to be fully UK based, but their insistence of being inclusive meant they still added members located in India.

I was replacing a UK developer who left because he was asked to do everything – because the Indians couldn’t connect to this API. In the first week when I joined the team, I was busy working, when one of the Indians contacted me and told me to pick up a bug fix because it was high priority, and they wouldn’t be able to debug/fix the bug accurately/comfortably.

We had 2 fairly urgent bugs and I was being asked to do both of them, yet I didn’t know what the 2 Indian developers were doing in the meantime. No wonder the other guy left – the team’s composition is nonsensical, and the Indians are always going to use this excuse. I’m sure the Indians don’t actually want to be in the team though, they would be more comfortable being assigned to any other team. 

You would think creating teams is generally easy, but I suppose there’s a bit of complexity to it. I’ve never had the opportunity to propose a team structure. I’d probably say my method would be something like this:

  1. Pick the correct number of Developers and Testers, considering their ability and knowledge. Do they have experience in the areas the team is focussing on? Does their job title really reflect their true ability? No point just putting one Senior in the team if they don’t have Senior qualities.
  2. Consider their personality types, are there any leaders in the team? No point putting together loads of silent types. Conversely, you probably don’t want too many big personalities.
  3. Consider if there’s any problems due to their location (access to networks or physical locations, consider time differences).
  4. Consider how well people get on:
    1. If you have people who are really close and are productive, then it’s most likely a good idea to keep them together.
    2. Conversely, people that have caused conflicts in the past could be placed in separate teams. No point risking extra tension.
  5. Try and avoid having similar names. This gets confusing in both written and spoken communication. 
  6. You may be limited when people can start working in the new team. Presumably everyone is already working on something and will need to transition.

Dealing With Software Support #2

I recently had to deal with another company’s software support team, and this was the second bug I had logged. The first bug didn’t go well at all. For this second issue, I had provided them detailed recreation steps, and videos of the issue occurring.

After I logged the issue, they said they would investigate and get back to me shortly. After nearly 2 weeks, I received an email requesting to arrange a phone call. I thought he was going to give me some news but he wanted me to demo it. So I asked him what that would give him over the videos. He said the videos I sent him wouldn’t play. Brilliant.

I didn’t understand why the videos won’t play. I recorded them using the Microsoft Game Bar feature and they ran fine on my machine. Instead, he wanted me to record the video with Powerpoint. This is bonkers. At least I learned that Powerpoint can record screens. It’s quite useful because you can zone out a tiny part of your window to record…but then there is no option to simply record the full screen!

The problem we had was that our software was intermittently crashing when it was interacting with theirs. However if you changed some Security settings in their software to “never warn me about suspicious activity”, then the crash didn’t occur. You would have thought it should pop up a message box rather than crash. So I asked their Support specifically if he had any idea why this would happen. If it was something I could change at our end, then maybe I could quickly resolve the issue.

“Our software may be thinking this 3rd party app is suspicious. And disabling that security setting helps!”

Support

Well, that sure was helpful. I bet he referred to Captain Obvious for that one.

Why is it intermittent? Why would it think our application is suspicious? why would it crash instead of popping up a message if it was suspicious? My line of questioning is to prompt him into getting to the bottom of the issue but it seemed he couldn’t be bothered investigating or even logging it with their Development team with this information.

I was also annoyed how he kept on chasing my responses when I’d barely had any time to respond. In his email signature, it said he was working 9-5:30 Monday to Friday, and he sometimes sent emails at 8pm on a Friday. Then I’d also get an email 9am Monday reminding me that I haven’t replied to his last email. If he doesn’t work weekends, why does he assume I do? He has literally given me 0 working hours to respond. 

There were even occasions where he wouldn’t even chase me by email, but would chase me up by an actual phone call that I didn’t agree to. We had put our IT’s department’s phone number on the Support ticket. I told him many times to contact me by email, but we can arrange a Microsoft Teams call if we need to talk. He would then email saying he couldn’t get through by phone. So I would remind him

“The phone number is for our IT department. I don’t have a direct number.”

Then he would sometimes respond with something similar to:

“We tried to connect you by phone, but unfortunately unable to connect”

Support

Absolute wind-ups.

I find that they always want to arrange calls, even though they end up asking something that can have been addressed by email. They must get reviewed by how many calls they make or something. I don’t understand the advantages. Being put on the spot to give information over the phone isn’t as effective as asking in an email and waiting for the person to have time to acquire the information when they are free. But maybe that’s just my preference? Still, they should respect the customer’s preferences.

At one point, he suggested that the reason why some users didn’t encounter the issue was due to a different “Microsoft .Net Framework” version installed on their machine. I asked him the best way of finding this information out. He replies with the following: 

I found the framework version in the error listed in Event Viewer for the affected machine. You can check if they are different by comparing a working machine and non-working machine.

Support

Do you see a flaw in their plan?

A working machine doesn’t log an error in the Event Viewer:smile:

Change to avoid change

Where I work, we go for long periods with barely anyone leaving the business, then we seem to be hit with several at once. There’s been a few people leave recently when we announced we would switch from the standard Agile process to SAFe.

With this restructuring, some roles did change but I think it was mainly people that weren’t affected like Software Developers.

I was talking to one of my colleagues, and he said 

“Why are people leaving? it sounds like we will still be using the same technologies”

Developer

The thing is, Developers will leave if you make them use different languages, and Developers will leave because they want to learn something new, so you cannot win.

I think some people may be leaving because they don’t believe our new software will ever get finished, then they have used the news of the process change as a final trigger to leave.

It seems quite stupid to me though – a change in management/process often makes people leave, even though leaving means you are dealing with a new management/process anyway in your new company.

It happened when we moved from Waterfall development to Agile. It also happened when we moved offices, and we have moved 3 times; even though it’s always been 10 minutes walk at most to the new location. If you come by car, it’s not even a problem unless the parking situation is different.

“OMG IT IS DOWN THE ROAD, I AM LEAVING to an office further away”

Stupid staff member

I remember with one office move, I was in the new office kitchen and talking to a Developer who was leaving. He said “I’m sick of these office moves”. I pointed out that we were literally standing in the new office, so he has already gone through the hassle of moving. He said he was only here because he had to serve his 3 month notice period. Yet he was moving to a new job that was probably further away from his house, and would more likely to have more job pressure because it’s very relaxed where I work. Also, since we had moved office, you could essentially guarantee we would stay there for at least 2 years because of the building lease. At a new job, you will more likely have to move offices within that time period.

In my mind, a change should be an encouraging aspect to make you stay, unless one of the changes has a negative impact on why you liked the job. In my experience, it seems a lot of people don’t see it that way.

Dealing with Software Support

I was invited to a call with some of our users who wanted to explain some of the problems they had in a particular feature of our software. One of the problems was actually an issue with a massively-popular 3rd-party software we integrate with, so they wanted me to log a bug with the 3rd-party on their behalf.

A reasonable request I thought, but I really didn’t want to have loads of phone calls/email chains back-and-forth with support. I just wanted to log it and forget about it. Luckily, I am a developer so I have a good understanding of all the information Support/Development would want.

This company that I logged the bug report with must be one of the Top 10 software companies in the world. So you’d expect their Support to be of a high standard. Due to the fact that the bug report is still open at the time of writing, I’d better keep their identity a secret, otherwise they could easily look up my name from the bug report and my anonymity is blown.

The feature is that you click a button, then their software will open a dialog with some data pre-filled in. If their software is currently closed, it still opens the dialog (their software is just temporarily open). In this scenario, when you save/close, then their software is supposed to close back down completely. However, it was getting stuck and you had to use Task Manager to kill it. This problem can be recreated consistently every time.

So I put together a great description of the problem, the recreation steps, the version of Windows, the exact version of their software I was using. I told them our users have recently upgraded from ‘X’ edition to ‘Z’ edition; and I was using ‘Y’ edition and can now see the problem after installing ‘Z’ edition so the problem is definitely in this new edition. Since I didn’t want to provide them with our software to recreate the issue, I even found some of their software with a similar feature and recreated it on there too. But to make sure they definitely didn’t consider it to be a problem with our software, or their other software product, I found another 3rd-party, free-to-use software and recreated it there too.

So I’d say they have a 100% chance of recreating that themselves, and I had proven it was a problem with their latest iteration of software. 

Within an hour, I get an email asking questions. So it seems I failed to provide them the information required:

  • What version of Windows are you using?
  • What exact version of our software are you using
  • When was the feature last seen working?

I had literally given him all those answers. So I reworded my original report and put them in bullet points. He then mails back saying he cannot recreate it and would like a demo. Unbelievable. I can recreate it everytime, our users can recreate it every time. It’s not a Windows issue because I was using Windows 8 and our complaining users are using Windows 10.

He specifies that the demo must be on Windows 10. Why? Is he just trying to mess me about? You can’t expect someone to have access to various computers. The version of Windows is irrelevant.

Regardless, I accept and I set up a Virtual Machine. It’s like a fresh computer install so maybe it is better than my work computer to prove this is a bug. I put their software on it, even created a brand new account. However, now my user doesn’t have the Premium licence but I accept the trial, so had 14 days. I can recreate it every time. Surely he hasn’t tried hard.

So I arrange the call, share my screen and I demo the feature to him. I ask if he did the exact same thing. He then tells me the main difference was that he was using the very latest version. Is he trying to wind me up? I told him the exact version, he asked for the version, then didn’t use it! Surely if he couldn’t recreate it on the latest version, then he could have checked on the version I was using; then rejected the bug as fixed. Instead, I waste an hour configuring the Virtual Machine and another 30 mins demoing it to him.

He was supposed to send me instructions on how to update because it wasn’t as simple as clicking a button. However, he didn’t bother and I found the instructions after some Googling. He was right that it was fixed…or kind of. I tested it several times and I saw the same issue again. So I tried some more and it worked for maybe 30 times then failed. So it’s intermittent. So I tell him it’s not perfect. He wants another demo because he can’t recreate it.

So I demo the problem and he said he cannot help because he noticed I’m “not using the Premium account” and he is in the Premium support team. I told him I do have a licence, I was just using this account to rule out if it was a problem if you had a large user profile: basically doing his investigation for him.

However, I have to deploy a new Virtual Machine since the settings don’t allow me to sign in (seems to be some restriction from our IT department). So after setting up yet another Virtual Machine and signing in with my work account (with the Premium licence), I do another demo. However, the intermittent nature means the issue didn’t happen and the meeting had already lasted 20 mins. I was pretty bored clicking a button and closing a dialog for that length of time. So I said if I had time, I’ll try and record it happening, but in the meantime, I’ll send him the recordings I had from before (with the Standard account).

After a few days, he says that he is going to log a ticket with the Microsoft Windows 8 Support Team, so I ask him why. It doesn’t make sense when the issue occurs on both Windows 8 and Windows 10. He said it was because it only happens on Windows 8 since I had demoed it working on Windows 10. I told him again that I have recreated the issue with the latest software on both Windows 8 and 10, and using 2 different user accounts. The recordings I sent him were Windows 10. It was just that the issue was intermittent and coincidentally worked during the time I was demoing it.

He apologises for the misunderstanding and would need some time with his ‘senior’ to come up with the way forward. A few days later, he says that his senior wants me to arrange another call to test out some scenarios. I told him I didn’t understand what the plan was. He apologises for the misunderstanding, but there’s some scenarios that we need to test. I told him I didn’t understand what the plan was: am I doing a demo? or am I watching them do a demo? He apologises for the misunderstanding, but he wants me to deploy another Virtual Machine and create a new user and demo this to them. Surely, I needed to know that and set up a Virtual Machine and new user account before we start the call. It would have been a bit awkward if I set up the call, he asks me to demo it on a machine I wasn’t logged into and with a user I hadn’t even created.

I told him I didn’t understand what the plan was. Why do I need yet another Virtual Machine and user account when I recreated the issue already using 2 accounts, 1 Windows 8 physical machine and 2 Windows 10 Virtual Machines? He said they had attempted to recreate the issue with multiple users and on different Virtual Machines, but since the problem seems to exist on my Standard account, then he would like me to verify it on another Standard account.

Let’s recap: when he concluded it was a Windows 8 issue, I told him it wasn’t because I’d recreated it on Windows 10. It seemed that me demoing the feature working on Windows 10 was the thing that he picked up on, and completely disregarded everything I wrote and said. I had told him on that call it was intermittent and I had seen it fail that same day on the same Virtual Machine. Now we are in a situation where I had told him I had recreated it with multiple users, but he is still thinking of that demo I did where it was working. Not only was it Windows 10, but I was using my Premium account at the time. So now he has this idea that the problem is with my Standard account.

I think I need to take him to a hypnotist to train him to forget the existence of that demo. What’s he going to claim next? That because he saw it working on a Friday, then it’s a Monday to Thursday issue?

My dream of just logging the issue and them instantly confirming the bug was completely ruined. 

It’s dragged out for a month or something daft and I feel like I have invested weeks of time investigating it. This is literally his job and I am doing his work and telling him how to do his job. It’s ridiculous. 

I keep saying to my colleagues that it seems that he is trained to mess people about so they drop the issue then they don’t have to fix anything. It’s a bizarre strategy, but what other logical explanation is there for his behaviour?

I like our system: Regardless of whether Support can or cannot recreate the issue, the bug gets prioritised based on what they know. If it is deemed high priority then it will get sent to Development, otherwise probably gets thrown on the backlog and we might look at it in a year… or never. But I think the key aspect is that we always believe our users, so it does get logged (“the customer is always right”). Well, I guess we get evidence like a video or screenshot, but I had already provided those – and we would never dismiss video evidence. 

As a side note: I wish that low priority bugs were dealt with faster because it will discourage users from reporting them if they think we will ignore it for a year. Maybe they can be given to Junior Developers to clear down.

Crisis Meeting

Apparently my employer has recently made a big deal and sold our software to a large group of users, but the users now want to reverse their decision based on other customer’s opinions of our software. Not sure why this group of customers only found out these opinions after making the deal.

We had a meeting with the new Head Of Development to discuss what we can do about it. The overall aim is that we need to repair our reputation: fixing major bugs, improving performance, improving the user experience in general, and making it clear to our customers that we value their opinion.

He initially stated that he wants more bug fixes, especially performance improvements and delivered in smaller, but frequent releases. He states that the current process doesn’t work and we should ignore it and come up with a new one.

Sounds great in principle, and a desired philosophy of Agile Development. However, Release Management stated it wasn’t possible to update the entire customer-base so quickly. This is partially due to the way some users work, and some contractual obligations. Both of these problems pretty much come down to the idea of essentially wanting close to zero downtime, so they want to choose a specific time to accept our updates, and they like this to be around once a month.

So the discussion turned to the development side. It seemed we were in agreement that we need higher-skilled staff to target these important bugs (we love throwing Juniors at these important issues), and we would also like to work in Domain based teams. Examples of this team idea is that you’d have one team that exclusively handles the Reporting module, and another handles Registration module etc. This way you can have a fuller understanding of all the configuration, features and the codebase; so can fix/enhance the software faster. Essentially you specialise, rather than going with the jack-of-all-trades master-of-none style. We also wanted more Testers since some teams have produced a lot of fixes recently but the Testers couldn’t get through it. To be honest, I expected that some Testers were just working slow and the fix isn’t necessarily to throw more staff members at the problem (just have a stern word).

The response from the Head of Development was that “the business” has decided on the team sizes and who is in those teams – and they won’t change. 

So to summarise – we are asked how we can make dramatic changes to the way we work, ignoring the current process… then get told we can’t do our ideas. We’d shot-down his suggestion, then he shoots down ours.

I think he shot down our suggestion because he is too focussed on the current process and structure, and he isn’t taking his own advice by ignoring it and coming up with a new idea. To be honest, it is easier said than done, and I think his way of thinking is – how to preserve the current in-flight projects? You can’t simply restructure the entire department without dealing with the current projects.

What you can do is just make the current project teams bigger and let them take the project and some bug fixes. With a bigger team, they can easily carry on with their project work, and with the extra people, they take on live Bugs, fixing “Technical Debt”, adding more automated tests etc.

I get confused how we get told these “Service Improvement” teams (teams that deal with bug fixes only) are the most important, yet it’s the Project teams that get the most experienced developers and the most attention. He has limited the “Service Improvement” teams to 20 developers with only 4 with Senior rank, one of which isn’t good enough to be Senior. Then most of the other developers are essentially Juniors. 

How can you deal with important bugs with a lack of talent? It’s frustrating that he arranges a meeting to ask how we can solve our way of working, but then he doesn’t listen to the feedback.

If he wants a quality product and to deliver faster, then we need the staff and process to actually achieve it.

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.

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.