The Code Quality Merge

I get a pull request to approve from Colin:

Title: merge Main in to the code quality barnch
Description: merge Main in to the code qualiaty barnch

It’s somewhat ironic that it’s about quality, yet is riddled with typos. Also, why didn’t he just copy and paste the title and description?

Usually, you can just approve merges, there aren’t any new changes from the developer. They are just updating to the latest version. I have a quick peek and I notice that it doesn’t actually have the last set of changes that went into the Main branch.

So I left a comment;

“Isn’t this still 2 weeks out of date?”
The comment of shame

Nothing like quality.

Pair Programming With Beavis

Beavis is a software engineer that loves making excuses to avoid work. Beavis had a bug to fix in the same area that his previous fix was for. For his previous change he did ask:

“It’s a fix for the current release, so not sure if it goes directly in, or we Dev test before-hand.”

When developers say things like this, I do wonder how and when they test their changes. Do they just change a few lines, and “throw it over the fence” to the testers? Why does it matter what release it is for? “Oh it is for an urgent release? I won’t test it then”.

I don’t think he manually tested it, or even understood the overall context of his changes, but he did eventually add some unit tests which were logical and I believed would prove his fix would work.

The problem is now he has a new bug fix to do, and he still doesn’t understand the context. I was free so I was asked to help him.

For this change, we specifically needed to use a Virtual Machine. We were supposed to set them up a month ago, and Beavis had, crazily, logged 20 hours against this work on his timesheet.

Me: “Have you set up your VM?”

Beavis: “No”

Me: “OK, well that is going to take you the full day. So download the required programs and check out our source code”

I didn’t really expect it to take the full day. Maybe half a day, with a bit more time if there were problems somehow. I wanted to get a head start looking at the code so I had a better chance of training him later. I also thought if I allow him a day, at least it will lower the chances he is going to start coming up with excuses.

I began to look into the problem whilst Beavis was setting up his VM. The next day, Beavis doesn’t show up. The next day, Beavis returned to work but said he was having network/proxy issues so could not download the required software – so was stuck.

It took me a lot longer than expected, but even allowing Beavis 2 extra days, he still didn’t get ready. So I did it all myself.

Merging for 3 days

There was a project in a code branch that needed merging in for the release. Colin volunteers to do it. I expected that it would take him half a day, depending on if there are conflicts to resolve which can be quite tricky.

3 days later, he sends it for review. A couple of developers reviewed it and left him 17 comments of “is this your change?”

Colin responds to them “No I’ll remove it.”

How has this happened? How can he mess it up so bad?

There was a project that I worked on where we delivered it in two stages. We merged our changes in, but there was one feature where we discovered a problem so we reverted one file.

Another team had merged from the master branch into their project branch to take our original changes. When they merged their project branch into master, they wrongly resolved the conflict and reintroduced the problematic change in that one file.

No idea what Colin did though, it’s almost like he had merged a different branch into his branch then had merged it to master. I’m out of theories. It took him 3 days and he had clearly messed it up.

Testing found 4 bugs with the project (which may be original bugs missed in the original testing before it got merged in). How many have they not found? That’s what worries me.

Meet The Team

So I’m in my new team now, and it’s pretty much like I expected. There’s one good Senior developer, some good testers, some bad testers, then a few bad developers. The ratio of developers to testers is a concern, because there’s way more testers than developers, and the standard of developers is poor.

Guess who the bad developers are? The Colins are here, and so is Beavis. Completely called it (see A New/Old Adventure).

The good thing is that I can definitely look good compared to everyone else. I did say there is one good Senior, although I don’t know much about him. He does have a good reputation in the company, so I expect him to be much better than me. He is part-time though.

The more I explain about this team the worse it gets doesn’t it? Part-time staff, incompetent developers (Colin), a developer that doesn’t show up (Beavis), too many testers.

It’s good for the blog, if nothing else.

Who is a Software Developer?

The following blog Are You A Developer was recently shared amongst my colleagues.

The blog addresses Imposter Syndrome. It then reassures people they are a developer if they meet this definition:

A developer is a person who writes code.
David Walsh

I think it is a serious trivialisation of what a developer is. Several of my colleagues apparently agreed with this blog “100%”. I don’t understand how you can agree with it.

One of my colleagues not only agreed with this blog’s definition, but proceeded to say that developers and testers shouldn’t have different job titles, they should just be “Engineers”. Absolute nonsense. Not all Testers are interested in writing code. Some are interested in writing Automated Tests which requires programming knowledge, but other Testers just enjoy Manual testing which has no required programming knowledge.

So let’s address the quoted statement with some analogies.

If I cooked a meal, can I call myself a chef?

If I pull up a weed, am I a gardener?

If I paint a wall, am I a painter?

If I kick a football, am I a footballer?

It’s obvious you need a certain level of competency to be able to call yourself one of these things. If you play football in your free time, you can say you “play football”, but not many would say “I’m a footballer”, because it comes with the implication that they have an exceptional level of skill.

I was thinking you can’t simply state you can call yourself a Developer if you receive money for writing code. If it was a simple website you did for a friend, maybe you wouldn’t be skilled enough to be employed in a full time job.

Conversely maybe you make brilliant websites in your free time but you have other passions for your full-time job. Maybe you are good enough to declare yourself as a developer, but you just aren’t a “professional” developer.

What about developers that don’t receive money but only work in Open Source projects? At least the community would give them recognition, so at that point, I think they can call themselves a developer.

So it definitely seems money isn’t a factor.

So who determines whether someone is a developer? Do you self-assess? or is it when you get a certain level of kudos from your peers?

When you look at the people I often write about like Colin and Derek, are they developers? Well, they have had a job for years, and managed to get lucky to be promoted to Senior. On paper they are more successful than I, but I think you’d be crazy to imply they are at the level I am; and I’m not anywhere near the best in the company. Maybe we are all developers but there’s good ones and bad ones.

Ideally, Job Titles should reflect people’s skill but they aren’t a perfect system. But I think it is clear you have exceptional/great/ok/poor developers, and everyone else below this skill level, just isn’t a developer.

So if you have followed a tutorial, copied some code and ran it; are you a developer?

No. But keep working, and maybe you will be. Then work your way through the ranks.

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.

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.

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.

Batch File Shenanigans

I was running a batch file (a script containing a series of command line commands) and it was randomly closing without displaying any errors. A developer, Lee had recently made changes to this script. I had posted a message to state the problems I was having, and he messages me. The exchange roughly went like this:

Lee: “I can help, share your screen”

Me: “You will just see it close though; there’s no errors”

Lee: “No, just share, we will make it work. I just need 5 minutes”

Me: “Oh, do you have an idea of why it isn’t working then?”

Lee: “No, I need to see what you are doing first”

Me: “I’m running the batch file, and it closes, that is all you will see”

Not sure why he claimed it would only take 5 minutes. How did he pluck that estimate out of the air? After he would see it close, he was only going to get me to try all different workarounds. That is going to take way more time than 5 minutes.

There was a simple workaround that would allow me to get on with my work: simply revert his changes and carry on.

I reverted his changes, and carried on with my assigned work. After I finished my work, I did go back and work out what was causing it. I shared my findings with Lee, who made some changes and asked me to try it out. It didn’t work.

did have to try several different variations of the script to help him come up with the proper solution. This back-and-forth ended up taking around an hour or so.

I definitely didn’t have time to do that when he contacted me and claimed he would just need 5 mins. I’m glad I used my intuition.

Discovering the Programming Process

An automated tester posts a blog which got loads of “likes” and comments from Managers. One example comment was “what a well-written and informative blog”.

I read it, then read it again, then read it again. I’m so confused.

He begins by explaining how they are testing an API using Postman and have a collection of tests that they need to check-in to source control. Fair enough.

Then they say how it’s a tedious process where each team member needs to download the files, try them out, then mail the developer/tester who wrote the tests with their comments, then the process repeats.

I’m thinking “what sort of crazy process is this? This is what Source Control and the Code Review process were invented for”. You have side-by-side comparisons (“current file” to “changed file”) so you can see what they have changed. You can write comments directly alongside the code for them to read and make changes.

I must be missing something.

Then he explains that they needed to decide where to save their files. The Postman software encouraged them to store the files in Postman’s cloud service. “No, we aren’t gonna do that!” he writes as if it is some kind of security risk to save your files online. Instead, he is gonna save them online in GitHub. I send him a message about it, and he admits that I’m right, it’s just that he felt Github was more secure.

My loyal readers will be thinking “Hang on, haven’t you come across this scenario before?”. Oh yeah, here it is: GitHub Actions Are Secure. Yet another staff member chatting nonsense to sound good to the Managers and hype up GitHub. “We are taking security seriously with our decisions! This software is more secure because I said it is”. Has GitHub hypnotised everyone or something? They must have some propaganda machine. I’m not saying it isn’t secure, but claiming everything else isn’t as secure without evidence is just weird.

He then says how they wrote their own test library in Javascript which slowed them down because you don’t get great autocomplete support in the IDE. I’m thinking “maybe use Typescript”. He then explains that after writing their own library, they discover Jest; the most popular Javascript testing library. Hang on, how did you overlook the most popular testing library?

He then concludes that it is best to:

Use GitHub for source control
Take advantage of side-by-side diffs, and publish feedback in this code review process
Use Jest for Javascript Testing
Use Typescript to give type-safety and autocomplete support in the IDE

Tell me something I don’t know.

Then managers are drooling over these revelations, even though this is common practice to Javascript developers and probably has been for several years.

I want to know how much time his team has wasted messing about. Surely they didn’t start the project pretending software development had just been invented?