Mini Musing #6: Expenses Risk

I overheard a conversation between a Tester and his Manager. The tester explained that he had purchased an online course on a programming language and he asked if he could claim the money back on expenses. When his Manager expressed doubt that the company would cover it, he then said “well, never mind, I knew it was a risk.”

A risk!?

The way I see it, he should have bought the online materials to become more knowledgeable because he is interested in the subject, not because it’s simply something he could get for free. Describing the purchase as a “risk” shows the wrong attitude in my opinion.

I do wonder if he regrets the purchase and wanted to get his money back via any means necessary.

Beavis and the Mail Merge

Beavis was fixing a bug where the header in a mail merge didn’t display the correct label. Each country has a different name for their Identification numbers. The data was correct, but the label always showed the English name.

He comes up with a fix where he checks if the region is Scotland or Wales, otherwise he returns the English label. What about Ireland? The bug still remains. What about other countries we support in the future? This will require a further change to this code.

He takes the text from a resource file which is fine. He wrote some unit tests which covered his few scenarios. However, he was comparing the returned value to the text from the resource file. This means if someone accidentally changes the text in the resource file, then runs the tests; it will still pass. The tests should have been written with hard-coded text so isn’t so coupled to the actual implementation.

When it was submitted to review, the Lead Developer comments that it doesn’t fix all scenarios. He also made a brilliant point about another aspect of Beavis’ code. He was taking the customer’s information from the currently selected customer. This is mail merge. Mail merges are often done in batches. There isn’t just one selected customer, but a list of them. This could take the wrong person’s data.

A few days later, Beavis finally came up with the expected solution. The next day, it still isn’t checked in, and his update was along the lines of “I’m updating my branch”, which should only take a minute, not the entire day. I checked the history of the Bug. It has taken him 2 weeks, when I reckon I would have completed it in a day.

Later on, I overhear a Lead Developer express his concern to a manager that Beavis had been really slow and hadn’t showed any thought or care about his work.

It’s nice that it has been flagged as an issue.

Women In Tech

Recently, there seems to be more of a push to encourage women to apply for tech roles through means of tech conferences. I was thinking though, that surely the types of people that know about tech conferences – are the people that are already in the industry.

It probably makes sense to target the promotion directly at schools. Back in my day, if you knew programming, it was because you taught yourself, or went onto further education to study it. I have heard that these days, it is taught more at schools, so over time, I think the new generation will naturally enter the industry. It’s at that age you really need to get people interested. Otherwise, they will go and get a degree in some other field and the tech industry probably has a lower chance of getting someone to switch.

I think my employer has a lot of females in the managerial side of the department, but are severely lacking in terms of female developers. There’s a better representation of testers though, although still male dominated. I firmly believe this is purely a case of the representation of applicants, rather than any gender bias of offering roles. If anything, females have a better chance of landing jobs (LinkedIn even state this here https://business.linkedin.com/talent-solutions/blog/diversity/2019/how-women-find-jobs-gender-report).

Recently at one of these “Women In Tech” events, one female manager, Jackie goes to it. She surely has been in the industry for 30+ years, she joined the company in a high managerial position within the department, and has had promotions since. Surely her experiences of being a woman in tech hasn’t been negative. Therefore, I think she isn’t really the sort of person that could benefit from the event. Maybe a good candidate for actually doing a talk though.

If the talks involve how to tailor job advertisements to encourage female applications, then it’s probably a great event for HR to attend. It’s also ideal for women not currently in the industry, but they need to know the event is on, and be encouraged to go to it. This poses a question of where to advertise, and how to advertise.

So on to the actual criticism. Jackie comes back and reports on the event. One of the “facts” caught my attention. It said:

“Women apply to jobs when they meet 100% of the job listing. Men apply when they meet 60%.”

Now, I’m always sceptical of “facts” and severely doubted this one. Surely you can easily disprove it by simply assuming it is true. Sounds odd, but bear with me. A female reads this “fact”, then applies for a job when she meets 60% of the criteria. Fact disproved. Any fact that claims it applies to all people surely cannot be accurate.

As it turns out, with a bit of Googling, I found a more accurate quote, although I couldn’t find the actual source.

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

So the quote was from Hewlett-Packard, observing their staff applying for promotions. So it’s a very small sample size to base the statement on, and it is for internal staff rather than external applicants. So women and men already in the tech industry. Interestingly enough, the LinkedIn study I mentioned early verified that women did apply to roles differently to men.

I was thinking about job advertisements and thought there is no way I’d ever would have had a job if I only applied to jobs when I met 100% of the criteria. Most of them do contain irrelevant technologies just to sound more exciting (maybe they use C# but they will say C#/Java/C++). They often ask for degrees, or experience as a “Full-Stack” developer when it’s not actually required. Maybe they specify things you use rather than things you need to know the inner workings of (virtual machines). Maybe they even ramble on about generic stuff like “enthusiasm for technology”, “passion for quality”. The more things you list, and the more jargon you list – the more chance people are put off because they don’t feel qualified.

Mini Musing #5: It Doesn’t Compile

I was having a nosey at the latest Pull Requests and there was one from Colin. Usually, there’s a good few mistakes in his code. The Lead Developer comments:

“Does this even compile”

To which Colin responds:

“No, lol”

He never learns. How many times does he have to make these mistakes to realise that: if you make a change, then test your changes? When there are unit tests, it’s a simple as clicking a button, then waiting a few seconds.

Enforcing The Quality Process

If you find a bug, you are supposed to log it. Simple logic. However, people get annoyed when they log a bug, then the developer just tells them it’s a simple configuration option they have missed, or they don’t even have the latest version. It can take time filling in the Bug report, and it’s annoying when you have to almost instantly close it.

So then you get the attitude where people will rather email the problems, and hold off logging it until a developer confirms that it’s probably a valid bug. If the developer doesn’t actively check, then bugs can go unreported; which can be a disaster.

The other day, a Senior Tester posts a massive stack-trace in Slack. I have a quick look and realise it is a bug. As I was about to reply, another Senior Tester, (who is about to be promoted into some kind of Quality Process Manager or some nonsense; or maybe that is a rumour), tells him to repost it on Microsoft Teams. But not just one post, she wants it posted across two channels for “maximum reach”.

Or maybe maximum annoyance.

It’s really dumb, we have this process, and someone that is supposed to enforce the process – and definitely someone that will be enforcing the process in her new role – is coming out with nonsense like posting in informal channels.

If there is a Bug, then log it. It can always be closed with a valid explanation; which can help others in the future if the same problem crops up again.

Team Velocity

In Agile Development, you have a concept of Story Pointing and Team Velocity. Most people hate coming up with time estimates. If it is in hours, it is too specific, and then you feel under pressure to meet the exact timescales. With bigger work, it’s quite hard to measure things in days. The idea of Story Points is that you can just gauge items in comparison with each other, so you think about your smallest piece of work, then benchmark all other work against it.

Although teams may roughly have the same scale, and you could roughly map Points to days; the scale only truly makes sense within that team. So 5 points for Team Badger, may be a different size to 5 points by Team Snake.

The amount of Story Points you complete in a “Sprint” (often a 2 week period), becomes your Velocity. Well, the Velocity really makes sense as a moving average across multiple sprints, because in Sprint 1 you may go through 20 points, but Sprint 2 may achieve 35 points. If you analyse it, it may be because people understand the project and are working better together, so improved in the subsequent weeks.

We had a meeting today. One of the questions was

What’s your team’s velocity? If you don’t have one – then pick a suitable number“.

A) What are we doing with these numbers? Comparing them between the 3 teams? It’s nonsensical.

B) It turns out people haven’t been working in this Agile style anyway, and haven’t Story Pointed their work. But if Velocity is a sum of completed work that has been estimated, how can you estimate how many points you have completed by estimating what you think your estimations would be?

I’m sure managers are getting dumber.

The API 2

I wrote in a previous blog (https://strangercodingtings.home.blog/2019/12/30/the-api/) about an API that we wanted but didn’t meet our needs.

Another month went by, and we contacted the team to get estimates when they plan on changing the API to actually be usable.

The response we got was that their project was finished, and all the developers have been reassigned to different projects.

Hang on! How can they write an API and not work alongside any team!? The whole point of it is to provide data to other teams, so how can other team’s not be involved?

It’s not like they didn’t know we wanted it, I was requesting data from them in the prior 2 months.

I’m not sure when they plan on scheduling this work in, but it’s just stupid.

Joined up working

I think it’s best if you have teams that are in the same location since meetings are easier to arrange and have fluid communication.

If you are in the same office, you can have ad-hoc face-to-face communication. You can all go into a meeting room and don’t need any conference-call equipment which can have all kinds of problems; disconnecting, low audio quality. Same time-zones means there are more hour slots available to arrange meetings in.

I’ve heard people imply that teams end up being distributed just so that the other offices feel like they “feel part of it”/feel integrated into the company. Yet giving them a dedicated project they are responsible for would probably achieve that better; they will have more responsibility/autonomy. Adding members from the main development office makes it feel like they are been supervised.

Many times, you rely on a third party of some kind (by third party, this could be another team within the company or a different company). Maybe the third party collects the data and you just retrieve it via an API. You don’t really care about how the data got there, just that you can use it and it works accurately. Your team that wrote the user interface feel like they have achieved something. The team that collated the data and provided the API feel like they have achieved something. The teams may only need to communicate for a minor part of it. The teams need to know the overall aim, and what parameters they need for the API. My point here is that you can have two different teams with some minor collaboration, but both feel like they have contributed massively to the overall goal of the project.

I think adding a remote worker for the hell of it is just inefficient. Unless they are exceptional and can’t be replaced by the talent you have locally, then its just adding in unnecessary inefficiencies and causing unnecessary bottlenecks (have to delay meetings due to time-zones), have to wait until the next working day to get a response, different countries having different National Holidays.

Unprofessional Slack

I find that people can be rather informal on Slack due to people perceiving it more like an Instant Messaging client, rather than a formal communication channel like email.

Here are some examples words and phrases:

  1. Words, phrases or spelling that I would consider “Baby speak”: Fanks, looksies,
  2. Very similar to the point above: comedic phrases like Facejacker’s Brian Badonde: “Bwoh bwexcellent work”,
  3. Switching letters for comedic effect: “fassive mailure”.
  4. Old English phrases: “I say, old bean
  5. Regional slang. I’ve seen it all, from Geordie “howay”, Yorkshire “off t’meeting”, and Cockney “I’ll have a butchers at your report”.

When we are in a multicultural team, there is no way a non-English speaker understands this. I did ask the non-English members of my team, and they were unaware of Cockney rhyming slang. They did recall a few phrases from films that they had seen and were now enlightened.

Other comedic spellings/phrases/inside-jokes can be confusing or make people feel left out.

Other unprofessional examples:

  1. People putting silly statuses including sexual innuendos. They would never do this on Skype.
  2. People posting stuff they would never write in an email or say to your face. I was communicating in a thread with someone over the course of an hour. It was time to go home, so I left the office. He then posted some meme along the lines of “and he’s gone!” implying I fled because he asked me to do work. There is no way he would have said that to my face. I have never even met the guy in person or spoke on the phone.
  3. Someone asked for help with putting a video together. For some reason he added a random swear word. One guy points it out that it is NSFW, then someone makes a joke about the video consisting of pornographic material, someone else makes a joke about a convicted sex offender. No idea why people thought any of these things were appropriate, and it is completely out of character for our company culture. If I hadn’t read it myself, I wouldn’t have believed it happened…

but I guess anything goes on Slack.

Side Rants: Music Hipsters

Just for a change, here is a non-development blog.

I once was talking about music with my brother and ranted about someone claiming their music taste was the best and they kept on hyping up obscure bands. It seemed to me they just liked them because of their obscurity, and then trashed any band that was popular.

My brother responded; “damn, I hate those Pitchfork hipsters”.

I asked him what he meant, and he told me about the music review website Pitchfork. They tend to cover music outside the mainstream eye (apart from Kanye West for some reason), and my brother said he knows loads of people that listen to obscure bands, plus Kanye West, and also think their taste is elite. A weird coincidence.

Music is all about having your own opinion, but yet there’s loads of people that just accept the music that plays on the radio. Then there’s a large group of people that are very anti-radio, yet just follow Pitchfork instead. Ironically, they are just doing the same thing and following trends, but then pretending they’re not a sheep.

At work, a guy keeps hyping up how cool his music taste is. He does listen to quite a range of stuff; a combination of obscure rock bands, electronic/indie-pop, and hip-hop.

One day, I take a look at The Needle Drop aka Anthony Fantano aka Melon, and noticed many of these obscure and cool bands that they love have been reviewed by The Needle Drop; and reviewed highly.

It seems we have a Melon Hipster on our hands.

Today, he starts ranting about how bad Green Day’s new album is; “Father Of All…”.

Melon Hipster hadn’t listened to Green Day since American Idiot, presumably after that his music taste “matured”. So what makes him listen to “Father Of All…” when he hadn’t listened to 21st Century Breakdown, Uno, Dos, Tré, and Radio Revolution?

Well, The Needle Drop had just reviewed it, hated it, and gave it a ridiculous score of 0. Melon Hipster had listened to it just to trash it.

I’m not saying it’s a good album (I haven’t heard it), but listening to an album once and then ranting about how bad it is isn’t an honest opinion. Echoing the “opinion” of a media outlet or social media influencer doesn’t make your music taste cool either.