Glint Survey 2025

We recently did a “Glint” survey. It was to gauge sentiments about how people feel working here.

All departments completed the survey. Some of the statements we scored, and the results for Development were as follows:

Resources” “I have the resources I need to do my job well” – 63

Energised” “I feel energised in my current role at work” – 58

Contribution” “I understand how my work contributes to the company’s success. – 75

All of these were 5-10 points lower than the rest of the company.

The department is getting worse, but no doubt no action will be taken on the senior managers.

New Login portal

At work, whenever we need to log into a website, it displays a custom login screen. The text box labelled “Sign in” has the following text

“Enter user name as instructed below in GREY Box”

At the bottom, there is a grey box:

“Enter the password associated with your username”

The text box actually wants your email address but tells you to enter your username but to read the grey box. The grey box tells you to enter your password.

Absolute shambles of an implementation.

Code Review Argument: “Why are you reviewing!?”

There was a code review submitted in a project branch. I had no reason to review it because I wasn’t assigned to the project, but I often like to be nosey and see what is going into the releases.

I noticed a few classic mistakes like server-only code placed in “common that gets installed to both client and server when deployed. There was also a caching problem where the first call will store the data in the cache, then a call from a different user will then go into the cache and grab the other user’s data! It’s the classic mistake of forgetting about how the app servers are shared between many users and many organisations.

For years I have flagged these problems up. Maybe we should have it as part of an induction process to go through common misunderstandings. Anyway, I send them on to some developers (Dean and Mark) that I have discussed issues with or joked about them in the past. Each developer then decided to also leave comments on the review even though they also weren’t assigned to it.

In a private chat, Dean said “why isn’t the lead developer spotting these mistakes and teaching them?“.

I assumed he might have actually then put an official complaint in, because Gary, the Senior Developer assigned to the project; then left an angry comment.

“why are you commenting on a project level change? I thought you were struggling for time and this is a project branch that I haven’t yet reviewed”

The thing is, he hadn’t said that to Dean and I, but to the other developer Mark. It’s like maybe they had some kind of previous arguments and now it’s flared up.

Mark rightly responded:

“You’d added comments. This isn’t the place to debate such things, please contact me by message if you have a problem”

I think it could be the case that Gary hadn’t fully reviewed it, just glanced at it, left some trivial comments, and meant to come back. In my opinion, if someone does the review for you, then doesn’t that save you a job? Many developers seem to hate code reviews since they would rather be writing code, not reading it. So really he should be grateful. But he has taken it like a personal attack like we didn’t trust Gary to point out these major flaws in the code.

It’s also beneficial to spot problems as early as possible. There’s nothing worse than aiming to get the project in a release, then when you want to merge it in, then the experts then look at the code and tell you that it has major flaws and cannot be released. At least we have flagged it early in the project and they have plenty of time to address it.

Access To Live: Length

I needed to check the live databases in order to investigate a bug. I had to request access by filling in a form.

There was a field to specify how long you need access for.

Sometimes, you will know you just need 1 day, but other times, you might not know how long it is going to take to complete your investigation. As the saying goes “How long is a piece of string?

It said on the form you can leave the date blank, and they will give 2 weeks by default. I was incredibly surprised by this.

  • A) You would think they would be really restrictive
  • B) It’s like they actually understand how you work!

I thought that would be the best option for me, so I left it blank and submitted it.

I then received an email, stating my request was incomplete and she needed to know how long I need access for before she can approve my request. 

Annoyed at Autonomy

To illustrate how awkward it is these days to do something simple… we needed to disable a button, but it’s not clear to the user why the button is disabled. I quickly put a tooltip on the control.

I knew we needed approval from the UX team who are responsible for the “User Experience”, so I emailed them.

When our Product Owner was told, she was really annoyed and started moaning that I made a decision behind her back.

A decision hadn’t really been made, I was just exploring one simple option and trying to get things done. There was always the chance that UX wouldn’t agree with it, but it’s given them context and a possible solution.

The Product Owner didn’t like the tooltip at all. I did point out that other areas of the system do disable the button but don’t show a tooltip. So my button is an improvement that we show a tooltip – at least the users know why the button is disabled.

I suppose showing a tooltip for this disabled button is inconsistent UX, but that’s why I emailed the UX team. I know UX Team tend to hate “dynamic” UIs so don’t like things appearing/disappearing. This isn’t something we are removing, but just disabling/enabling.

After the Product Owner contacted UX, they wanted me to basically redo the dialog because other aspects don’t conform to their standards, but all that functionality has been around for years.

The bug/enhancement wasn’t actually reported by our users. It was just a Developer who decided it would be beneficial to change.

Conclusion

When there’s many people in charge of deciding what work needs to get done, and many people in charge of how things get implemented; making any change is a slow process and most things end up getting thrown on the backlog because the effort of implementing anything increases.

OpenJDK

Recently we had this slightly humorous exchange. It’s a good example of how something minor can cause confusion. Java was apparently added to the list of software we could no longer install, but it wasn’t communicated well across the department, including what the alternate plan was. So people had different beliefs of what could be done.

Apache changed the Java licence to be paid for commercial organisations. We didn’t want to pay, so we were prevented from using it.

  1. Manimozhi needs Java to run JMeter.
  2. Nandha tells him to install Java.
  3. Manimozhi says he did that previously but got told off by Devops Team because it was unlicensed
  4. Nandha says to use OpenJDK then since that is free
  5. Manimozhi claims it doesn’t work
  6. Nandha thinks he must be confused and tells him again to use OpenJDK
  7. Manimozhi is sceptical
  8. Matt says if it doesn’t work, then don’t use JMeter
  9. Mukesh then chimes in saying that we actually do have a licence to use Java

I don’t know if we did have a licence to use Java, but I believe OpenJDK did work.

Full conversation below:

Manimozhi
We need Java in our environment to run the J meter - to get it we have raised the ticket to IT but that seems they don't have access to the machine, so could someone guide us what we have to do to get install Java in our environment.
Thanks!

Nandha
you can install latest and compatible Java version yourself in the machine it's pretty straightforward

Manimozhi
yea , have already installed but when we did this last time we got email from devops team asking about java license and reason for installation . as Java v8 involved cost and J meter is compatible only after from V8.

Nandha
It can't work with openjdk ?

Manimozhi
no
I suspect being a Apache foundation open source project it must not have any paid dependency.
It was free before Nandha, later they have changed it for paid

Nandha
No I'm saying about jmeter
https://stackoverflow.com/questions/59269365/does-jmeter-works-on-openjdk-13
I suggest you to try openjdk first it's free

Manimozhi
ok Nandha, will check this, Thanks!
I am worried will I get error while launching, but lemme try that.

Matt
If OpenJDK doesn't work, I suggest you find an alternative to JMeter.

Manimozhi
Sure Matt

Mukesh
Java JDK was licensed now recently,

Retention Policy

After we got taken over, we were notified that our parent company has a “Retention Policy”. This is the time when information will be permanently deleted. 

This affected emails, Teams messages, OneDrive files, and SharePoint data.

Emails90 days
Archived Emails3 years
Shared emails3 years
Teams personal chats90 days
Team Channel posts3 years
OneDrive5 years since modified
Sharepoint1-5 years (decided via approval process)

When we were told this, we thought it was ridiculous. How many times has someone needed to dig up an old email to determine why code was written the way it was? How many times have we dug up an old Team chat to know how to fix a random configuration error that suddenly happened?

If they are deleted after 90 days, then we will lose a lot of information.

After raising concerns, we initially got pushback along the lines of “if it’s important, then it should be in a Team Channel or on Sharepoint“.

But even then it can still be deleted after a length of time. 3 years might sound a lot but it soon passes by.

It sounded like there was no warning when information was about to be deleted either. It just disappears silently and there’s nothing you can do about it if you didn’t copy it elsewhere.

There was more pushback when some long-standing employees said they would have to go through 10 years of emails to decide what could potentially be useful and what isn’t. After a lot of pushback, we got the email policy increased to 3 years.

Secrets in code 

Recently, we received the following message sent to the entire Software Development department from a manager:

Over the last couple of days, we have witnessed multiple instances of sensitive credentials committed into GitHub. This has been noticed by chance whilst supporting teams / reviewing PRs. Instances have included an individual’s GitHub PAT & test user account password. 

The security team are likely to enable a secret scanning tool in GitHub to help identify instances of this in future. However, this isn’t guaranteed to spot all issues and by the time it does; we are already potentially at risk. 

Please ensure that you are vigilant in reviewing your own / other’s code before committing / merging code. If a sensitive credential is identified; please ensure that this is removed and revoked immediately to prevent misuse of the secret. 

I’m really surprised if multiple people have done this, because we keep talking about improving security, and improving processes. Adding private keys/credentials etc to your repository sounds like a common cliché and is like Security Lesson 1. From the very start of the project, we have talked about having security scanners on our code from the very start.

I thought GitHub automatically scanned for credentials but it might just be for public repositories, and ours are private.

Security keys/tokens can often easily be regenerated so it’s easily fixed. However, your mistake of committing them is in the history of the file. I suppose there’s technically ways to modify the history but at a massive inconvenience.

Suspicious Parent Company Emails

When we got taken over, we started receiving emails from our parent company. However, we were not told what to expect in future emails and many look rather suspicious. 

Some emails just go straight to Junk so they obviously haven’t communicated well with our IT department either.

As part of our security training, you are told to be wary of unexpected emails, then look for suspicious links, text calling for urgent action. These emails tick all the boxes.

One example of an email was titled “Secure: Your Security Access Request was completed“, then looked like an invoice with my name, date, a Request Id link; with a header containing the word SECURE in upper case. It had no information detailing what request was completed, making it required to click the link. I didn’t make a request, but it did say it was on my behalf.

The email address looked like our parent company’s main domain name. It was received in the same week as we got told about our new credentials to access some of their systems. So was this related or not? 

When we don’t understand the new systems, know what we should be able to access, and who we need to communicate with, it would be prime-time for a malicious hacking group to try to socially engineer our credentials. This seems hypocritical when they made a big fuss when they were hit with a cyber-attack in recent times.

Project Gatekeeper

A few years ago, the company I work for was taken over. This was by a larger group of companies. One of the smallest companies they own was a company dealing with financial payments so was much more important than their size suggests.

My understanding that someone working for that company was “social engineered” and their password was accessed. This cyber-crime group that acquired the password then used it to install ransomware on the entire system. Sensitive information was believed to be stolen, and the systems were unable to be used; preventing millions of transactions being processed.

It was a massive hit to the reputation of the parent company, and cost millions paying out loans to those hindered, and compensation over the incident.

Even though it had nothing to do with our company, it caused instant fear that we could be next, therefore any security policy that could be changed was.

The stolen account didn’t have 2 factor authentication, but even if it did, the code could have also been socially engineered. I think it’s a bit naïve to assume that was the only reason it happened.

Even though we used 2FA on our accounts, products like Microsoft Teams asks you to log in then keeps you permanently logged in. So then they changed the policy so it asked you every day. As we found out, Microsoft Office doesn’t handle this well, sometimes struggling to log in to Teams and Outlook to start our days. I’m not sure what that was even trying to achieve, but it was a massive annoyance to everyone. It then got reverted after a week or so.

Other changes followed as part of what we called “The Gatekeeper Programme”.

 Gatekeeper Programme Scope

  • Risk assess all practices, tools and techniques.
  • Prioritise security based projects
  • Create new practices, policies, process and control measures.
  • Improve security monitoring
  • Remove use of out-of-support products
  • Training to prevent against social engineering

What it really meant is we ended up switching to products used by the parent company, and we lost access to do certain activities. So our VPN software was changed, we had different Remote Desktop software and only certain people were allowed to use it.

In some ways this does make sense as it reduces the number of products that could have a vulnerability. Restricting privileges to only necessary staff members also reduces the number of people malicious groups can target.

Many of the changes seemed an over-reaction and the urgency we had to remove products was a massive hindrance on certain departments, mainly Group IT.