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.

Remember when people used to know what they were doing?

Remember when people used to know what they were doing? those were the days.

“what concerns me the most is that there was a time where everything almost worked like clockwork and now it seems like more ruins every day”
Software Architect

“I am more surprised when something works”
Me

We used to be a company full of smart people, working effectively. Now we work slowly and people just cut corners and do incredibly dumb things. In more recent times, people now don’t think for themselves because they ask AI what code to write. Sometimes it’s absolute rubbish but they never reviewed it themselves; so it really is zero thought. You point it out to them that it’s not going to work, and they respond back with an overly polite message, clearly written by ChatGPT; which just adds insult to injury.

So it’s like developers don’t even develop because AI does it. Then they don’t do any dev-testing. Then the Testers don’t know what they are doing either.

Recently Testers have been installing our software on the application servers.

Even though one of the Lead Testers has been posting angry rants about it; it keeps on happening. The Lead Tester’s points were that it’s not representative of live, and how it takes up the RAM/processing time and lags out the app server for everyone else.

I don’t get why people got the idea to install the client on the app server, and remote on. You can’t think that is official. The servers were always configured to only allow 2 people on at once, so it’s not like the entire department can log on to test if it was the official process.

I just hate what this company has become. I feel like it’s just gonna keep getting worse with managers constantly encouraging people to use AI.

Unconscious Bias

There was a time where a group of people were hyping up “woke” topics, and the latest topic was “Unconscious bias” which is supposed to cause a certain degree of racism/sexism during the hiring or promotion process. Or maybe even leading to some microaggressions in meetings.

We were encouraged to watch a few courses on LinkedIn Learning, but it was not mandatory. Some of it was actually quite interesting.

There was one cringy moment where the presenter gave a trigger warning of sorts:

“if you feel an emotion, pause the video and deal with it. If you still feel the emotions, contact me and discuss it“

In my opinion, I think if you get overwhelmed with a simple LinkedIn Learning video, then you have bigger problems.

In my notes, I had written this claim but not sure what it means – because how do you even measure the bias:

“Research has shown that even a 1% bias in favor of promoting men changes the outcome.”

The following sounds like a decent philosophy though. If bias does exist then we do need to take it into account:

“By understanding that we’re all biased, we can make the decision to work together to be more conscious of our thoughts and actions when relating to others. Not only can we fix the current situation, we can then resolve not to do it again. Over time, it’s possible to learn to think and behave differently.”

She then makes the claim that even if you look at different aesthetics within a particular gender, you can notice trends which would suggest there is an unconscious bias at play:

“Blonde women earn 7% more than brunettes. Slim women make more money than obese.”

Some of the categories of bias are quite interesting. Halo bias probably does make a huge difference. You can say it’s like when you work with a Senior who you respect; whatever they claim in the next project you are tempted to back them and agree.

Halo bias – “admiring all of a person’s actions because of their praiseworthy actions in the past”
Perception Bias – “the tendency to form stereotypes and assumptions about certain groups that makes it difficult to make an objective judgment about individual members of those groups.”
Therefore it is difficult for women to be hired in gender perceived roles. E.g. software developer
Confirmation bias – “Seeking out evidence that confirms our initial perceptions, ignoring contrary information.” “We double-down and seek out information to justify our position.”
GroupThink – When the desire for harmony or conformity in the group results in incorrect decision-making.
Performance Bias – Underestimate women’s performance but overestimate men’s. Men are often hired on future potential, women hired on past performance.
Attribution bias – Less likely to credit women for success, but more blame for failure. Women’s contribution is less valuable. Women are more likely to be interrupted when speaking.
Likability Bias – Expect men to be assertive so like them more when they are assertive, but have a negative response to women. Agreeable and nice is perceived as less competent so need to assert themselves to be effective, but then are less liked.
Maternal bias – motherhood is perceived as less committed and less competent. Strongest kind of gender bias. Lower performance ratings, and lower pay in future.
Affinity bias – gravitate to people like ourselves, dislike those that are different. More likely to give positive performance ratings to those that are similar. White men’s prominence means women and those of colour are negatively affected.
Double discrimination (intersectionality): Women, and of colour is double discrimination. 3+ minority attributes make people feel like they don’t fit anywhere.

“Woke” people seem to suggest that men are the problem when it comes to bias. However, I have seen claims that if you have an all-female panel they are often shown to be biassed towards hiring men. The claim was women don’t want to hire someone they perceive as a threat, or someone who is more attractive than them.

There was another LinkedIn course I watched that stressed the point that both genders show bias, sometimes in different ways.

There was a test where participants were shown pictures of men and women and they had to state (purely by stereotyping) if they associate them with “family” or “career”. Regardless of the participant’s gender, 76% of people associate women from the images with “family” rather than “career”.

There was also a claim which I would like to see what results back it up:

“Diverse teams tend to be more committed and work harder, and companies with more women in leadership tend to produce better business results.”

During the hiring process, there is some scope to anonymise it somewhat to try and remove any bias against gender or race, in an attempt to judge purely on merit.

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:

describe the problem,
ideas on how to solve,
pros and cons,
any possible costs like software licences,
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.

The Chop

I was once contacted by my manager to review a particular code change, but with the instructions to actually select the Reject option if there was anything wrong with it.

Things seemed a little odd, so I was suspicious about the request. Usually you would only use the Reject option if it was completely the wrong approach, not just if one thing could be improved.

The change was an SQL data fix, but seemed for a bug that would rarely occur, so my instinct is that it should be run manually on the afflicted sites rather than sent out as part of the normal patching process.

The normal process would mean the script would be run on all servers, and be subject to the usual slow “roll out” process; therefore delay its application to the affected site.

Looking at the comment from Support, it sounded like it was possibly just on one site.

There were 3 cases linked to it; 2 from the same site, 1 with a title of a completely different error number. Then the workaround is stated as “Re-add the Default Location to the Template” so they probably fixed it already. So maybe we didn’t even need to do anything.

Looking at the dates that it was logged, it seemed like it was classed as a minor bug so had a long time period to fix as per the Service Level agreement so I was sceptical it was still an issue after 2 years.

So my initial instinct says it should be applied as a manual patch, then reading the details from Support, it sounds like it was just on one site and they had already manually fixed it, presumably via the UI.

So I asked my manager if the site has been contacted to see if it is still a problem? Then we can just close it.

And that’s when my manager said

“His skills are currently being assessed so he’s been left to figure it out and told to ask for help if/when he needs it.”
Manager

So it seems like they have given him a bug to investigate then fix/close. Since he has struggled to resolve items before and been reluctant to ask for help, they have chosen this one to test if he is collaborating with the correct people. He didn’t, so they sacked him.

I haven’t encountered many sackings; everyone seems to imply it’s a lot of hassle, but certain managers are more willing to do it. Another approach is to declare that a “new opportunity” has come up and they will be placed in a new team to see if that causes an improvement.

Whether to log a new bug

Recently, we had the classic debate whether when discovering an (unrelated) problem, a bug fix:

should be rejected/marked as failed,
or if you pass it, but log a new bug.

Sam said he had never logged a new bug if testing failed, even if this issue wasn’t called out in the bug report; in the description or recreation steps.

So to explain using this situation: I had fixed the Entity Framework code which saved a new row to the database table. The bug was for passing correct values into it, and my change was fine; the correct values were now saved in the appropriate columns in the new row. However, if you send multiple calls at once, Sam noticed it wasn’t incrementing the number by 2 as expected, only by 1 (the first call was then essentially being overwritten – a classic concurrency problem).

I think it’s reasonable to use the original Work Item (Bug Report) to flag any issues testers find, but once we confirm the new issue isn’t caused by my change it should go into its own Work Item. You might assess that the new bug could be fixed in a later release. It makes no sense to fail bug A because you found bug B.

Sam is basically increasing scope, then moaning that we might fail the sprint, because we cannot complete the new item within the 2 week deadline.

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.”

Debate about ChecksumGenerator

I was working on recreating functionality in our new API. It was basically a copy-and-paste job from our current product.

I had another debate with the Team Lead who said I shouldn’t have copied the ChecksumGenerator, and wanted me to replace it with a Nuget package.

The idea of using existing packages is from the generic advice of “don’t reinvent the wheel“. If the code already exists and has been thoroughly tested by loads of people, then it’s best to use that. In terms of future fixes and enhancements, if it is a popular open-source package, then other developers will update it. If you rewrite the code for your own company’s use, you are stuck maintaining it.

However, in our case, we already have some code, we know it works since I took it from our other product and it’s been used for several years. It’s only 58 lines long and has no need to change.

The package he wanted me to reuse wasn’t actually that popular so it adds some risk using it. I had just finished my code changes and already ran all the tests, so any changes would need to be retested.

Isn’t using loads of packages just adding bloat? That is such a webapp thing to do. My brief experience of developing a React Application, has shown me that it uses a crazy amount of packages with a basic boilerplate application like create-react-app. Then anything you install has loads of other dependencies, and you end up having bloated install size and loads of potential security risks.

The Team Lead’s justification is that a ChecksumGenerator isn’t directly related to our API so shouldn’t be in our repo, and wants to “do things properly“. I think if you go that extreme then the software ends up in development hell. Which is exactly what has happened here because this API is part of a larger project that has been in development for about 7 years now.

It’s quite hard to win an argument against a Team Lead because unless the majority say that he is wrong, then what he says goes. We have a Junior in our team, then the other developer is the Team Lead’s best friend. Then the other two are Testers that don’t have much interest in a coding discussion like that. So it’s gonna be rare for someone to speak up and cast a winning vote there.

I asked my Software Architect friend what he thought:

“That’s completely senseless. Pretty much always use code that works, as long as it performs well as part of it ‘working’.
Does the new package have an allowable licence?

You should ideally try to avoid dependencies”
Software Architect

I had a discussion with another colleague in another team. He mentioned that infamous time someone got angry and withdrew a package which took down a large part of the internet. I think we have mitigation for that scenario though.

Robert:

What if the package gets pulled?

Me:

I was about that yesterday. I think we mitigate it by having our own nuget store. So I think the package goes from the main nuget source, down to our local nuget store, then into our builds
might have made it up, but that's how I picture it
so unless you attempt to update the version, you always have a copy of the one you currently reference because it is cached on your server

How (Not) To Split An API

I’m a software developer that only really has experience on desktop apps, and was recently put on a project to make an API. I had an interesting debate with the Tech Lead of the project about where we should put our code, and how we should view its responsibilities.

To make it more anonymous, I’ll change the functionality slightly but it’s the same idea.

An Orders API had been in development for a while, and my team needed to add functionality to send some data to a government API, so let’s say it was for ID verification. Even though our initial requirements are that only the OrdersAPI will use the VerifyAPI, you could argue that in future, maybe in future, other applications we have made, or third parties could call this VerifyAPI directly.

There’s a famous idea in software development; YAGNI; You Ain’t Gonna Need It. Which is the idea that you should program to requirements and not speculative “what if” scenarios.

The Tech Lead argued that we should put our code in a new repository because it was a separate API. I said that that adds loads of overhead because we will need to write code in OrdersAPI to call our code, then will need to add a reference to our VerifyAPI using a Nuget package. This will slow down development as you need to update 2 repositories, need some temporary reference as you develop, create multiple “Pull Requests”, then need to publish the Nuget package and update the references once more. I stated this was gonna be a huge inconvenience if the project ends up running over the year.

I also called YAGNI on that we will probably never use the API for anything other than OrdersAPI so it should just go in the same repository. In the event where I am wrong, it should be fairly easy to move it out as long as we just use separate projects to keep our code separate.

He insisted on doing things his way, but the thing is, even though we had a separate repository, it wasn’t a separate API. It was more like a code library. So several months later, he was asking managers if we can create a “mini project” to turn it into an API for clearer separation.

So it seems like we had 2 opposing viewpoints but ended up somewhere in between with all the disadvantages.

Another interesting debate I had seemed to illustrate his confused view of what our code is. He has always viewed our code as intending to be an API, but I was changing some error messages and he said my messages were misleading because our repository is not an API!

The confusion seemed to be him saying the “client” is the OrdersAPI, but I see the user of our software as the client, the OrdersAPI is the server call, and it doesn’t matter where it goes next

The message was something like. “Field ‘Date of Birth’ is missing”. He didn’t like the word “field”

Tech Lead
"I'd change the wording on these messages. We're no longer talking about "fields" since we've split the API request out."

Me
“does it matter where our code is? it's part of the same request as far as the client is concerned”
 
Tech Lead
"fields" just sounds like API talk
 
Me
but the client has made an API call
 
Tech Lead
the client hasn't made an API call though
if those prerequisite checks fail then no API has ever been involved
and even if it has, why would the client need to know anything about an API?
are you talking about the browser client?
 
Me
isn't it
client -> OrdersAPI -> our library {fail checks} -> error status to the client
 
Tech Lead
sorry i thought you were referring to the OrdersAPI as the client in this context
which it is
our package shouldn't know that it's being used in an API., that's the whole point of this change
 
Me
it's a black box for the caller. The user shouldn't know that it's using a library. The code could all the be in the same place as far as it is concerned

Then after more discussion, he is adamant that something could use our library in future so then there’s 2 usages, an API and non-API. So it cannot have API related stuff in it.

But our intention was to have a separate space for our team to maintain, we have never discussed it being used by anything other than the API. The early discussions was to have our repo that was an API.

Daniel
tbh I don't immediately think API when I see "field" I think it's fine
 
Me
he did say the message could just be
"‘Date of Birth’ is missing"
Which might be better but then wouldn't you want all the messages to be consistent. However, I guess someone could update the OrdersAPI repo with a new message style, and then forget about ours.
 
Daniel
you make a good point about consistency though, the API should be consistent regardless of where the code lives

It’s a really trivial argument, but I think this is just the beginning of many debates. Sometimes I think we like adding loads of complexity early on then work doesn’t get done.

Experimentation vs Being Safe

When it comes to software development, often you can play it safe using technology you already know, or be more adventurous and use something new. I think the trick is to research the pros/cons of the language and make sure it is suitable for your approach.

There’s no point thinking something is cool and therefore using it – when it might not be the correct programming language to use. An entire team investing time learning something new can be a complete waste of time if the project is then cancelled/restarted due to heading the wrong direction.

A rule a thumb when choosing technologies:

For an experiment? be as weird as possible.
For production? be as boring as possible.

When it comes to maintenance, sometimes you end up in situations where someone is the “Expert” and therefore has to fix any issues themselves, or will be approached for help by another developer. Therefore, if you write something crazy for production, it will be you that maintains it, either directly or indirectly.

Sometimes becoming the expert in something is the way to get promoted or pay rises though, since you become the super important developer that the company can’t afford to let go. However, that also means you will be stuck on this part of the software, and can’t really move on to different projects.

If you do become one of these experts, and if you want to move on to a new project; you need to train a replacement up. Can you find a replacement that wants to take over, knowing that they will be stuck with this special project? How long will it take to train a replacement? How much documentation did you write?