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.

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.

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.

New Comms Process

I’ve made many blogs about communication. It seems that over time, there can be a new tool that managers start using which then becomes the cool thing to communicate with. Email was always a popular way of sending the information to all. When messaging apps like Microsoft Teams or Slack were available, then these became the cool way, but it involves people subscribing to the channel in the first place. Then we had Social Media style apps, initially “Facebook for Work” and then Yammer which was recently renamed to Viva Engage. Then there’s documentation style websites like Confluence, Sharepoint.

There was one post that made me laugh where a manager highlights the problem of having too many apps which then people have their favourites and have different frequencies checking them. So he points out the absurdity of cross-posting, and wants to fix the problem by carrying on cross-posting, but mainly causing you to divert from one platform to another.

As one colleague hilariously pointed out: 

“I’ve just followed a link posted to Teams to a Yammer post that contains a link to Confluence…”

Here is what the manager announced:

Hey everyone,
You might have noticed, during this quarter, that I have been trying out various different ways to get a message out to the whole department. I've put content on Confluence and Teams, and sent messages by Teams, Slack and Email cascade. The bottom line is, there is no one-size-fits-all solution to getting important info out smoothly.

But this is a problem we can solve. And it's a problem that we must solve: with this many people in the team, it is critical to have a way to announcements and updates out to everyone. So this is how it will work from now on:
You are reading this on Viva Engage. This is a new community set up specifically for long-form comms across the train. If you Follow this community you will get updates of new announcements. But I won't rely on just that - I will also send out notifications on Teams and Slack, with a link to new posts. I will also use Teams and Slack to post short-form updates that do not need a post on Viva Engage. So here is the call to action:
• I will commit that the leadership will use both Teams and Slack to send out department-wide notifications. As long as you look out on one or other of these channels, you will not miss out.
• I ask everyone to do this right now: whichever tool you prefer (Teams or Slack), make sure you have access to the right channel (see screenshot), pin it or star it, and make sure notifications are turned on.
For this first post, I will also send out an email cascade but in future I will drop this step. It's vulnerable to delays and with the other channels set up, we don't need this as well.

For the Viva Engage posts - please "like, share and subscribe"!! Let's make this a conversation
Thanks

Managing The Message

We released a much anticipated feature to our users, and it was going through our roll out process. This means only a group of users got the update, then next month it would go out to more, and so on.

So the initial users were excited to use it, and other users were eager to hear their opinion. As part of the release, there were other changes that went out, and some users were encountering issues with Feature A which had some bug fixes and improvements, and this was unrelated to our Feature B which went out in the same release version. Since both features involved some processing in the background, some users were falsely attributing a problem with Feature A to a problem with Feature B.

They took to Facebook to complain, and even suggested some workarounds that were complete nonsense. It’s basically a placebo effect of making a change and the crash goes away so you falsely conclude it helped when it was mere coincidence.

We are told that we must never respond to users on social media. All posts have to go through official channels that Marketing and Support use.

A developer raised the issue with a group of managers and a liaison from Marketing.

“Are we doing anything to combat this line of thinking that Feature B is causing crashes? This is one of those really fun Facebook threads that has popped up because our company has remained silent on the cause of an issue with Feature A, and the users have clutched at straws to come up with ideas for a fix and pooled them all in one place. One of their suggestions is quite harmful to us because it involves clearing the cache which then requests a large download to our servers. We now have a fix for the main crash they are reporting, so we should make it clear a fix is coming, there is no workaround, and it has no relevance to Feature B.

Concerned developer

I agree that as we’re quite clear on what the cause is (and isn’t) it feels like we should explicitly clarify this and address the incorrect speculation.

Product Owner

As I’m sure you can expect, we have been very close to this for the past four weeks and are working with relevant senior people to agree what messaging we can send out to the market.

Marketing Manager

close to this for the past four weeks”! Yet have stayed pretty much silent the entire time. Then that resulted in Feature B getting a bad reputation which puts people off using it, and it’s generally damaging to the company that we responded so slowly to address what the users consider a big issue with our software. Marketing have been really bad in recent years, and is a reason why we have lost market share because the opinion from our users has declined.

Innovation shambles

Recently, managers decided that every few months we should have an Innovation Week. The idea is that you can work on ideas that can improve our work processes or even add a new feature to our products. However, the time limit of one week is a bit limited to actually get something complete in my opinion.

To be efficient, we really need to come up with a great list of ideas before the innovation starts, otherwise it cuts into the week. Some people did submit ideas before, and others on the day.

The initial meeting quickly became a bit of a shambles. Paul had created a Miro board under a different account that the attendees didn’t have write permissions for. Even when we clicked the link to request access, and Paul claimed he approved it; it still didn’t work.

He then tried creating a different board, but that didn’t work. To not waste further time, we just posted ideas into the Microsoft Teams chat which then he transferred onto Miro.

Since the ideas were essentially just titles on the board, people were supposed to explain their ideas but I don’t think many explained too well. We probably needed some kind of formal process to:

  1. describe the problem, 
  2. ideas on how to solve,
  3. pros and cons, 
  4. any possible costs like software licences,
  5. prerequisites to be able to investigate or implement the idea.

Another thing was missed is that you have to have accounts to use many of the AI tools, and that was a focus of this month’s innovation. With a lot of software, it often needs a special licence for commercial use and we weren’t advised how to acquire licences. We had Github Copilot and Office Copilot but what about other AI tools?

One guy apologised for misunderstanding that the ideas should be process improvements and he had come up with an idea for our software that our users would use. Paul said he hadn’t misunderstood at all and we could suggest either process improvements or new features… but that’s not what the Miro board said. It was only for process improvements and so all but one idea was for process.

We needed to assign our names to them, so initially Paul tried to create a spreadsheet but couldn’t work out how to share it so we could all edit at the same time. He ended up pasting the ideas into a Microsoft Teams “Whiteboard” which I had never used before but it looked like the Miro boards.

There were loads of ideas, but many were of debatable value. However, like I stated, we never discussed them effectively. Without knowing the pros and cons or prioritised the business value; there were loads of ideas that definitely weren’t strong enough. So with a large list, it was hard to pick something to work on. Some of them would need more than one person, but what guarantee is there that the team will be full? Less likely when the list is so big.

So I asked the question if we should only put our name against 1 item, or vote for several so we can see which teams are full, then the full teams get approved. Paul said to only vote once otherwise it will look like teams are full, but you’d end up dropping out if another one of your votes were successful. I suppose that’s a good point, but only voting once will mean you could be the only person to vote on a team project, so would then have to choose something else anyway, or gamble and go by yourself.

With most people finally assigned (and many just disappearing, presumably to slack off), with many going solo, and some probably having more team members than required; we got told to communicate with our team members.

I was in a team of 3 but I thought the ideal team would just be a pair. I waited for 30 mins or so but the guy that came up with the idea hadn’t contacted me, and you would assume he would take the team leader position.

I then took initiative and added a group chat with my 2 team members, and after another 1.5 hours, I finally got a response from one person who asked how we should begin to plan. I responded with my notes I had created to set the scene. He suggested one extra point to my notes, then didn’t hear from him for the rest of the day. The other team member didn’t respond at all.

The next day, my manager contacted me and said I was assigned to help finish a project that was behind schedule so my “innovating” had come to an end.

Absolute shambles really.

Time management – A manager’s perspective

A manager recently posted the following. I think this sounds like good advice. Although I always think with us breaking work down into 2 week “sprints”, then the tasks just expand to fill the time allocated. So I think you need to process change or a collective mindset change across the team for this to actually work…

“Some thoughts on getting more for less…Individuals in all teams should analyse what they currently do in their role on a daily basis (i.e. where the time is spent). 

Then see what that could look like moving through transition (modernisation) and what next year could look like.

Right across the business, all individuals should take a moment to analyse where they spend their time each day (not high level timesheets, actual analysis). If we are ever going to get more productive output from already lean (stretched) teams then we need to work out where to optimise time and get the most quality output out of each day.

Examples of questions that individuals should ask themselves each day:
 
1. Am I managing my time properly? 10 minutes planning the start of your day can save hours. Write down what you would like to accomplish during the day. If you plan ahead and write it down, you can enjoy any breaks without thinking about work. Heads full of tasks that are not written down creates brain chaos meaning we break away from smart thinking.

2. Am I spending too much time playing around with ideas before I decide what to do? By the time I decide what to do there’s no time left. Stop procrastinating. Putting things off can affect your productivity.

3. Do I need to be in these long meetings? What am I contributing? What else could I be doing? Meetings are crazy expensive. I have been in meetings of 20 people where 3 people talk/contribute. Could I skip a meeting and watch the recording later?

4. Can this repetitive task I’m doing be automated? Should I be doing it or someone else more suited? Am I using technology to speed up my job? If I am a developer, do I spend too much time manual testing when it could be automated? Just because it’s always been done this way doesn’t mean it’s the right way.

5. Am I working in ‘smart mode’? Is there an easier way to accomplish what I’m doing? Am I over-elaborating? Finish unimportant tasks within 10 minutes.

6. If I have 5 things to complete concurrently, try allocating time to each task and set a timer. This speeds up work. Divide your day into time increments. Then, assign specific tasks during each portion of your day.

7. If you need to concentrate hard on certain tasks, then minimise distractions. Block time away from people.

8. Prioritise your tasks. Starting off with your most difficult or important tasks first can help you feel more accomplished.

9. Group similar tasks. When you focus on related assignments, you spend less mental energy context-switching between different tasks.

10. Finally, set aside personal time to disconnect from work. This can increase your productivity. A stressed and tired brain cannot work efficiently.”