Month: Jun 2020

Public Speaking Expert

A former colleague left to set up some kind of business to do with public speaking. He did have a fairly short-lived video channel where he posted up vlogs about software. 

He was a terrible speaker. 

There was one video where I thought his dialogue was so funny, I typed up the transcript, so I can laugh about it in the future. Well, I have found the notes. Here it is:

The reason for that is that a good friend of mine, erm, erm Neil, who I went to university with, erm, commented on Facebook, er and said, you know ‘what do you mean by “Digital Service”, surely it is just software?’.

Erm, oh erm and, I…yes it is just software, erm… but I…I’m trying to make a distinction, erm, erm, trying to make a point about, erm, er the nature of software and the nature of delivering software and that to me, erm software IS a digital service.

Erm, erm… you know… erm, there’s there’s, you’ll not have come across a software project that erm… simply, erm… you deliver the software and you walk away, erm that never usually happens, you you, you are actually delivering a service, because erm when you deliver software erm you sort of committed to support that software, you committed to provide a service, erm, for me, software engineering is actually all about, erm, taking a service and transforming that service, such that you are providing new features, new functionality, maybe you are joining things up.

Maybe you’re, erm, erm, you are seeking to refresh that service, you are seeking to, erm… ensure that service is continuing to deliver the value it’s meant to deliver. You are maybe looking to make sure the service is more efficient. You, you’re using, you’re developing some software, delivering some software to transform a service.

“Software” vs “Digital Service”

I hope you understood that, because I certainly didn’t. 

People often add filler sounds like “erm” when they are nervous, but he had all the time in the world to write a script, record it, and edit it. It’s not a great promotion of his “skills” that he is selling.

Nerd Dad-Jokes

Javascript developer Wes Bos is maintaining a list of nerd Dad-jokes. They range in quality and many only make sense if you are familiar with programming languages.

https://github.com/wesbos/dad-jokes

Here is my favourite joke:

I went to a street where the houses were numbered 8k, 16k, 32k, 64k, 128k, 256k and 512k.

It was a trip down Memory Lane.

If that is too nerdy for you, have some pizza humour instead:

The YouTube Channel

A colleague promoted his YouTube channel which is the result of an amazing idea he had during the Coronavirus lockdown.

He thought it was clear that “people who didn’t have access to the internet, or lacked the basic digital skills would find this situation an immense struggle”.

So his solution is to create a YouTube channel where he makes videos on basic stuff like “how to use a mouse”, “how to use a touchscreen”, “how to navigate a website”.

There’s a major flaw in his idea.

How do people watch YouTube? Does someone print it out for them? No? So they have to go on the internet and use basic skills to navigate to YouTube, in order to watch a video telling them how to do so.

Even though he promoted it at work and many colleagues would have watched the content just to see what it is like – he only has 350 views and 12 subscribers in nearly 3 months. Don’t quit your day job.

Hoaxes and campaigns

There’s been a lot of hoaxes/campaigns/fake news in recent years, and sometimes a small Google search can easily disprove them.

I’m not even sure if there was an outcome to the campaign against the communication app House Party; which was accused of hacking into people’s bank accounts. Even one of my colleagues shared that one, and actively encouraged people to uninstall the app. I pointed out it was probably just a cause of reusing passwords, which also was the opinion of security expert Troy Hunt.

Another recent example is 5G causing Coronavirus.

Troy Hunt’s blog on Let’s Stop the 5G Hysteria: Understanding Hoaxes and Disinformation Campaigns is brilliant, so go and read his blog instead of mine.

Here is a summary of the headers:

Insight 1: You can tell a lot about the credibility of a claim by observing those attracted to it.

Insight 2: Understand the difference between people who have formed their own opinion versus those who are qualified enough to influence your opinion.

I enjoyed Zombieland, but not once did I stop and think “here’s a guy who looks like he’d know a thing or two about voltage-gated calcium channel activation exacerbating viral replication”. Yet here he is, broadcasting it to 2M Instagram followers. Fortunately, he’s since deleted the post.

Troy Hunt on Woody Harrelson’s level of expertise

Insight 3: Consider whether you believe a claim because the evidence supports it, or simply because you want to believe it.

Insight 4: When faced with alternative theories, consider which one is the simplest and therefore most likely to be true.

Insight 5: Question why you’re being encouraged to influence others and if you’re sufficiently informed to do so.

A New/Old Adventure

I received an ad-hoc meeting request with two managers. I wasn’t sure if the fact my line manager isn’t involved is a good thing or a bad thing.

One manager, Chris, explains that the business has acknowledged that our new software (currently in development) hasn’t really gone to plan. It’s nowhere near complete and Chris reckons our current software still has a good few years left in it and needs supporting. 

The problem is; over the last few years, more developers have gradually switched over to work on the new product and now there’s a bit of panic that we don’t have the resources to adequately support the current product.

He plans to create a new team and lead it, and he wants me to be involved. Together, both managers explain that my ability and knowledge are a good fit for this team, and they could easily see me progressing and would be promoted quickly. They expect me to lead a sub team.

I am really tempted by this suggestion of promotion. It’s what I need, and probably should have had years ago. However, it ain’t in writing and is probably just a false promise. However, my current project does suck and I have lost motivation.

Also, I’m not impressed with my new line manager. Switching to this new team would mean Chris will be my manager and he does give me a really good impression. He seems passionate and organised, and doesn’t throw business jargon around to make everything sound important.

I still had reservations. The other manager detects the uncertainty in my responses. “What’s on your mind?” he says.

“Well, the good developers will want to work on the new, exciting product with all the new technology. Who would go back to work on our “old” product? Surely it’s going to be a team full of failures? People who can’t handle the ‘new world’.”

He laughs. “Oh, no, there’s some great people that have signed up already. Many are seniors.”

Now, I’m beginning to uncover their lies here. How can I lead a team if there are already loads of seniors involved?

Either:

  • There’s no seniors, and I can lead them
  • There’s seniors, but they are failed seniors. They know they can’t handle seniority, and will let me lead them
  • There are seniors, and it was a lie about me leading anything

I was also sceptical of my ability to learn new things. At least with my current project I was learning new programming languages. Going back to the old product is just working with stuff I already know. Chris did say there’s some cool projects coming up, and has the potential of using exciting tools/languages; but I remain sceptical.

I thought about it, and even though this Team/idea probably contains at least one big lie – I accepted the challenge. Hopefully if I get a promotion, then at least I can take the hit of the team sucking.

I fully expect I will be working with failures. I expect Colin and Beavis to be there as Developers, alongside some of the worst testers. There will be more idiots to pad out the numbers I’m sure. But if that’s true, then that’s brilliant news for the blog. There will be plenty of stories in this new team.

Buzzwords #2

I’ve got another great quote which features a combination of buzzwords within the same sentence, stated by the same manager as documented here: Buzzwords

The proof-of-concept endpoint is the culmination of efforts across the application space. It will migrate into an integration account used by teams going forward for the integrated product.

I can’t stand it when people churn out nonsense like that. What does it even mean? Does it just mean “a team has written a framework”?

Memory Leek

A memory leak is where memory resources are “incorrectly managed”, so memory isn’t freed up when no longer needed. This leads to reduced performance; slowdown, and eventually crashes when there is no memory available.

So this picture is a USB flash drive in the form of the vegetable; leek. That’s nerd humour.

Simon Sinek

I came across Simon Sinek and some of his talks are really interesting.

I was watching some of his ideas on performance.

Here he was illustrating that you can set a goal (the circled dot in the top right), and one team’s performance may be all over the place but has a general upwards trajectory. They may have many moments of poor morale, high staff turnover, yet they reach the target and are most likely rewarded by many companies.

The second team is the fairly straight and consistent line. They don’t reach the goal and aren’t rewarded. However, give them a few more weeks and they will get there. They get there with high morale and with structure. His point is that it’s the team’s momentum that is important to spot. 

He prefers this second team but most companies will reward the first team and that bad culture will thrive.

Here, he was saying how you can categorise people in terms of Performance and Trust. We often have metrics for performance but not trust, which leads to companies rewarding toxicity.

You don’t necessarily want someone who performs high, but you don’t trust (top left circle); they may perform but “do you trust them with your money and your wife?”. No.

Obviously “low performance and low trust” is really bad, and high trust and low performance isn’t that great either. 

“High trust and high performance” is really rare, but if you come across them, then keep hold of them at all cost. The people you also need to make sure you keep are the ones he has circled on the right: “mid performance, high trust”; they are the loyal and effective employees. If you ask someone “your team is failing, who do you turn to for help?” then they will point these employees out.

How do you measure success? Simon Sinek

Why My Project Sucks

This is basically a follow up to the previous blog. So here is why my project sucks…

Firstly we are distributed across two offices with the justification of “the people in the other office need to feel involved”, or that is what one manager explained to me. They could have just assigned them their own important project rather than unnecessarily split the team.  Due to the office split, half the team were managed by the person actually assigned as the Team Manager, and the others were line managed by a manager in the other office who was primarily the Team Manager of a different team.

That manager was in charge of (what I liked to call) Team Duplicate who kept on duplicating our work. It’s approaching a year since our project started and we don’t really have much to show for it. However, what we did do; they wanted to directly duplicate (either directly using our code, or basically copy and paste) to have a slight spin on it.

Half the team aren’t interested in doing Code Reviews. This slows you down when you start coding a feature that relies on some other work, but yet it isn’t committed yet, because it hasn’t been reviewed. It then becomes a bit fiddly to manage code branches and merging code.

Unclear requirements. It seemed one person in the “Product” Team was making them up, rather than looking at contractual requirements or features that users actually desired.

The Product Owner didn’t take ownership of the requirements. This is linked to the above, but also he kept on saying “this is a technical project and I’m not a technical person.” No, Requirements are written as “User Stories” which are from a User’s point of view. It’s up to developers to discuss the technical implementation details. We didn’t have requirements from a user’s point of view, so it was difficult to understand what the end goal was. If the Product Owner actually wrote User Stories that were well-defined, it would highlight what UI designs we need from the UX Designers, and they can pass the work onto the UI Controls team. Additionally, with clearer requirements, it would probably highlight the distinction between my team and Team Duplicate.

The Team Manager added some ideas he wanted people to look at, but they weren’t backed up to a requirement. Again, they were a technical implementation detail, but what were we implementing? In the refinement sessions, we kept on pushing these “User Stories” down the backlog, but the Team Manager was reluctant to remove it outright, because “we may need it. It could come in handy one day.” If the Product Owner took ownership, he would have just binned these so-called requirements.

Due to slow progress due to many of the above reasons, we had a high turnover of staff. Most people that moved, simply switched projects, although I think one person did leave the business. We have a team of 9, and have had 5 replacements over 7 months. One person partially moved teams. He seemed to shift his focus to help another team, but seemed to dabble in both projects. It really felt like he didn’t care about the project anymore.

Conversation With My Line Manager – A Project Review

My manager asked me how the project is going. I was honest with him. I stated most of my concerns.

First of all, the teams aren’t well defined. We have some User Stories that seem like they would sit better with the team handling Authentication. We also have work that shouldn’t be much work on our side, as long as the UI Controls team have created the controls we need… but they haven’t – so that work has to be marked as “blocked”. Then you also have what I call “Team Duplicate” who are just duplicating our work.

I ask my manager what Team Duplicate is for, and why they just don’t merge with my team. He doesn’t give a straight answer, he just says:

“trust me, there is a difference”.

Line Manager

He is leading that team, and he can’t even explain their purpose.

I also said we don’t have many User Stories that are true User Stories. They have that name because they are from a User’s point of view. They should be defined like “As an admin user, I want to manage member’s privileges so they can access confidential records”. They shouldn’t be “As a menu, I want to provide options for the user to click”. Seriously, we do have some written like that.

My manager said my opinion was interesting, because someone else had said the same issues to him.

“Oh, so are you going to do something about it?”

Me

“No, it’s not my responsibility”

Line Manager

Brilliant. Multiple of his line reports are complaining about big problems but he won’t feed it back. Why can’t managers manage all of a sudden? They were fine last year. Now they have all given up and forgot their skills.

I could raise the issues myself I suppose, but it didn’t used to be this way. Also, part of my problem is the team he is managing, but he doesn’t agree there is a problem there.