How To Make Your Team Hate You #3

I was thinking about the colleagues I’ve legitimately despised (and it’s not just my opinion), and most of them have something in common: they have either been promoted, or told they will get promoted if they prove themselves, resulting in a change of behaviour. So here is story number 3, and hopefully the last one since I don’t have any more drafted up.

The Situation

I was once on a project where I was the only software tester. Usually, when it’s a proper project where it is going to span 3 months or more, then we would have at least 2 testers assigned.

I was well excited to show that I could handle this responsibility. The project went well, and I was well proud. That project was actually a prerequisite for something bigger, and yet again, I was looking forward to the challenge of the follow-on project.

Collectively, both projects were going to be a replacement for part of our software, but it was going to be phased over time. Therefore, it was important that the old version still worked.

So I looked at what the current system did and wrote all the features down. I then spent ages looking through all the Test Cases, comparing these to the features that I documented. Then I had to write the Test Cases that were missing. This probably took around a month of preparation.

Since the new version needed to do what the old one did, but might have done it in a different way, I basically had to duplicate every test, then start changing the steps accordingly.

Having this 100% complete test coverage worked well, and I knew people would be thankful for it in the future. Anytime a feature is changed, you know there are tests that you can run for your manual regression tests. I think every tester has been annoyed at some point; when they think a test should exist, but it doesn’t, so they have to begrudgingly write it.

I’ve done the work for them. I don’t think any other area of the system had this level of test coverage. No one can be annoyed about this can they?

As we moved onto the second project, I was told another Tester, Barbara was joining the team. I’m not sure if I was told explicitly, or if I just heard rumours, but I’m pretty sure I knew it was the case that – if Barbara did well on the project, then she would be promoted to Test Lead. Based on my performance over the years, and based on the project I had just finished, I think it should have been obvious to promote me to Test Lead. Maybe I was slightly annoyed, but I don’t think that had any affect on what happened next…

The Conflict

So Barbara joins the team and looks at the test cases. She wasn’t happy. Despite having that 100% test coverage, the tests were “too granular”. She says that when it comes to testing a particular feature, we would end up adding maybe 10-20 tests from my pack. She only wanted to run 1 or 2.

So she starts complaining at me, telling me I’ve wasted my time and I need to rewrite them. She likes the idea of “end-to-end tests” where one test actually tests several features and could describe what a user would do over a 5 minute period.

For example, I may have written a test that describes how to create a document, then another test how to print a document, then another test on how to email a document.

Her way of testing would be to include all the instructions for these 3 features and put them in one test – since a user may log in, create a document, email it to someone, then print a copy out for themselves.

I argued that my way is better, because if there is a bug involving email, you can just pick out the short test involving email. I’d be annoyed if I had to test printing it when it has nothing to do with the email bug fix.

“But that’s not how we did it in my old team!”

Yeah, but you aren’t in your old team. You’ve joined this one, and this is our process.

She used this statement multiple times about different aspects of how we work. I kept on explaining how if we work “agile”, we are supposed to come up with a process that suits us, and agree as a team. This process suited us, or at least it worked perfectly well before she joined our team.

Yet she comes in, kicks off a massive fuss to try and put her stamp on the team, and bypasses the correct channels for these decisions; which would have been the Retrospectives. I would have been happy to debate it in a meeting, rather than her dictating what I should do in front of everyone.

What Barbara did next was – run off to her manager, who happened to be my manager as well. But because my relationship with my manager was simply a professional one, and Barbara was very chummy with her, then our manager instantly backed Barbara.

So then I had to plan out which features made sense to use after each other. I spent 3 or 4 days planning this out. I spent more days writing them. I only wrote about 7. How many test cases did she write?

Zero.

Didn’t practice what she preached.

I was fuming.

When it came to testing the new features, she often volunteered to test the easier items, and gave me the harder items. I didn’t mind, because if she wasn’t on the project, I would have just done them all anyway.

What was infuriating, was that the next day, she would chat some nonsense about how she was too busy so didn’t have time to test it, so then asked me to test it instead. So I’d end up doing all the work. It’s just that it would take longer because I’d finish my work and have nothing to do, then the next day, I’d have to do her work that she was supposed to do. So the result was that we had 1 extra tester in the team, but productivity had halved.

She did this for weeks. It wasn’t a one off. Often, I’d look at her monitor and saw she was sending personal emails, doing online shopping, or just looking at news.

Then when it came to the stand-ups, where we stated to the rest of the team what we had accomplished; she then claimed that she did the work.

I was fuming. How could she say that when I was standing there with her? It’s plagiarism, and absolute lies. I complained to my manager. She refused to do anything. I was so tempted to walk out.

I’d never had that feeling of not wanting to go to work before, but some days I just didn’t want to go. I actually started looking for new jobs.

Sometimes when Barbara was away from her desk, I’d be ranting to my team. We were a close bunch on the initial project, but it just didn’t feel the same way. Soon I was brought into a meeting with the project manager who seemed to suggest I should apologise and try and get on.

I don’t get it. We were all close and worked well together. We delivered a project successfully on time. A new team member joins. Testing productivity is halved. There’s massive friction. Who do you think is the problem? You could easily verify my claim that she wasn’t doing the work. The test case runs are audited. My name would be on every one.

It seemed that Barbara had just sweet-talked everyone and they were determined to promote her regardless. As a Test Lead, you are supposed to have testing skills, people-skills and some management skills. Barbara wasn’t showing any of it. She was refusing to run test cases and she was causing friction. Productivity of the testing side was lower than when it was just me on my own.

Epilogue

So what happened in the end? Well, I was a bit unsure what I wanted in my career. I initially wanted to move up the ranks as a Tester, but it wasn’t happening. I did get the craving to be a Developer, and considered becoming an Automated Tester. I requested a change of role to a Developer since the Automated Tester role didn’t exist in the company. I’d be in the same department, but I knew I’d switch teams so would be away from Barbara. I just had to put up with another couple of months working with someone I despised.

I did get my internal move in the end. Barbara got her undeserved promotion. Years later she got made redundant. Better late than never.

For more in the series, see: How To Make Your Team Hate You #1 and How To Make Your Team Hate You #2

Return To Castle Monkey Ball

Someone has created a mashup of the games Super Monkey Ball and Return To Castle Wolfenstein. It’s Super Monkey Ball, but with the Wolfenstein theme. Check it out here https://nickireda.itch.io/return-to-castle-monkey-ball

You can whizz through the levels in several minutes, so it’s not much effort to give it a go.

Shelving, failed restart, then restarting a project

When we entered lockdown, there was a small project that was identified as urgent, and very helpful to our users due to the current situation. Originally, they estimated a simple change. So we make a change to one file. When testing it, we realise it didn’t send the information in the outbound messages to a third party. So we made further changes which were a few day’s work.

We then had a meeting with a few different types of managers. They wanted to know about our progress and they wanted estimates to finish the project. I thought it would only take a few weeks to test. However the Tester said it would take 3 months which I think he was just being extreme to cover his back. He did explain it was more complex than I had thought, but still – it was clearly over exaggerated. The Managers didn’t like the idea of having a Tester tied up for that long, so the project went “on hold”.

Months later, I was invited to a meeting to restart the project. A Project Manager was ranting that there was a financial incentive to get the feature out by the end of the year (2020), but if we deliver it late, then we miss the bonus. Even if we restarted straight away, we had left it too late – there was no way the testing could get done, and deploy in time to meet such a deadline.

The Tester stressed that my solution is just a prototype and needs to be reworked. In reality, it was fine as far as I was aware, but he was just buying extra time if we needed it. It was the Testing side of things that needed the focus. We needed to test these extra configurations, but a prerequisite was that we needed to understand how they were set-up.

I couldn’t really do much work until the Tester had done this extra testing to see if my solution covers all the different configurations he had come up with. However, the Tester was busy with some other work so he couldn’t do that for a few weeks. A few weeks later, a Product Manager messages me to ask when the project started. I delivered the bad news: “It hasn’t”.

A few more weeks go by, and we have a meeting with a new Project Manager. So we discussed the story so far with him. It was also announced that the Tester (who has all the knowledge about this project) would only be partially available – so needs to pass on his knowledge to another Tester.

Another week or so goes by and another meeting was arranged. We have a new Project Manager.

Ridiculous.

She starts making all kinds of demands about having all the usual Agile process. (User Stories with estimates etc). However, it’s a weird project because we have basically done the development and we just need to test. All this process seemed a bit overkill to us.

We had another “Project Kick-Off” meeting, and the Tester asked the Software Architect about setting up all these different configurations. The Architect then said the Tester had misunderstood and there was actually only 1 configuration.

This meant the testing time had been drastically slashed – you know; the exact reason why the project was delayed in the first place. So all these delays, extra meetings talking about the delay, all the meetings to rearrange the project; none of them actually needed to happen. We could have just completed the project when it was first assigned, additionally collecting that financial bonus.

The secret Touchpad features that Microsoft didn’t want you to know

I do love a stupid clickbait title. I’m sure Microsoft wants everyone to know these.

I always use a mouse and avoid using the touchpad. So I’ve only just discovered a bunch of touchpad shortcuts in Windows 10. Check these out:

2 finger swipe scrolls the page
Tap 3 fingers to open the start menu
Tap 4 to open the notifications panel
3 fingers swipe down to go to desktop
3 fingers swipe up shows all open windows, plus you can scroll down to see previously opened windows

Programming Podcasts

I’m always on the lookout for podcasts to listen to, but I think good software development ones are quite hard to find. There’s loads of languages out there, so you need to find ones based on languages you know or would like to know. Also, podcasts are audio only, so you are limited to what you can discuss, since many aspects would benefit from diagrams, or to see actual code.

I was listening to a particular podcast and thought I could review it on my blog. After typing up a draft, I held off publishing it because they have quite a big following and I was quite critical. After consideration, I’ve anonymised it somewhat, and tried to frame it more about Podcasts in general.

When I was learning about Web Development, I did want to learn more debugging tips. This particular podcast had an episode on debugging websites, so I eagerly listened to it. However, they didn’t talk about actually stepping through code using a debugger! They did partially talk about the newbie way of writing “console.log” statements in the code. I wasn’t impressed with this episode.

Another episode was discussing experiences of being a woman in the tech industry. This is fine; talk about what you know, what you have experienced. However, sometimes they went off on tangents talking about women specifically, and not in the context of software development. I think it was this episode where I wrote down this somewhat ironic quote:

“I get told I’m too emotional, do you know how angry that makes me?”
Woman developer on her critique from a Man

That did make me laugh out loud. She was totally sincere.

A few episodes have discussed doing presentations at Tech Conferences. I did watch a couple that I found recorded on Youtube and they did seem really impressive presenters. One of them presented at “Frontend Love” which is just a hilarious name. I think that’s why sometimes they brand it as “Frontend Developer Love” to make it sound less rude and more professional. I found it very strange that one of the hosts stated that sometimes they have signed up to conferences to talk about a specific topic, but they actually know absolutely nothing about the topic. The upcoming deadline then forces them to learn quickly. The thing is, surely your talk can’t be that interesting if you aren’t an expert in the topic you are presenting. I definitely wouldn’t want to put myself in that situation. What if someone asks you a question and you have no idea? You will look like an idiot. That brings me onto the next point…

I think it’s the same approach with many of their episodes. Host A starts talking about a topic, Host B asks a question to get more detail out of the statement, then Host A says “I don’t know, that isn’t in my notes”. Then at that point I realised they were just reeling off information from Wikipedia. What value does that give the listener? Anyone can read Wikipedia. We need “added value”; you need to talk about “lessons learned”, your opinion etc – just give us something more than an audiobook version of Wikipedia.

Compared to other programming podcasts, it hasn’t been as nerdy with its themes since it has mainly covered subjects relating to the industry (recruitment and conferences), rather than the subject of coding directly. Personally, I don’t think this is what I’d look for in a Programming Podcast.

One Podcast that I have enjoyed is Merge Conflict. Those guys talk about Android/Apple development, and “.NET”, and both James Montemagno and Frank Krueger seem incredibly knowledgeable in their topics. Never have I thought they were just reading from Wikipedia, they seem to have a deep understanding and plenty of experience in what they are talking about. Sometimes it might be more news-like, so they talk about upcoming changes to “.NET” or a new iPhone etc, but their experience of previous iterations means they can actually provide an opinion on the new features.Another one I enjoy is Fredrik Christenson who also posts them to Youtube. He keeps them concise, usually under 10 minutes and answers a question from his subscribers. He speaks purely from experience of the industry and has some good stories, or makes good points in general.

Software Testing – Can developers test?

A software tester created a presentation about “the role of a tester”, and discussed whether “software developers” make good “software testers”. I thought the presentation was a bit confusing, because in some parts it sounded like she was saying they can, but in other places, it sounded like a categorical NO.

I found this quote recently from Ron Gilbert, creator of computer games like Monkey Island and Thimbleweed Park. It covers “game development” specifically:

Don’t believe the myth that programmers can test their own code. They can’t. Programmers will test for all the conditions they can imagine, but a good tester will imagine many many more and players will try things programmers never even considered. Knowledge of their code is the achilles heel of programmers. I’ve had code I was 100% sure was rock solid, only to have one of our testers reduce me to tears. A good tester excels at poking your code in places you never considered. I’m not talking about your unit tested sort routine, I’m talking about complex puzzle logic and odd UI uses. It’s the stuff unit tests will never catch, but a good tester will. Testers are the unsung heroes of your team, treat them very well.
Ron Gilbert – https://grumpygamer.com/delores_dev

This is the way I see it:

There’s the concept of being “close to the code”. So the developer that wrote the code will test exactly how they implemented it – and not test the cases they missed; because they never thought of those scenarios in the first place.

A tester inside the company could be influenced by their relationship with the developer; have some unconscious bias about not wanting to find a flaw in their code because they don’t want to upset them.

A tester for a third-party has no connection to the code or the staff at the company. They can test it without any bias. Finding all bugs is a good thing, because it enhances their reputation and should help with repeat custom. This is a good rationale for why some companies choose to outsource the Testing aspect entirely.

When I have worked in small teams and there is a testing backlog, sometimes the developers will help out with the testing, but they won’t test their own work; they will make sure it was done by another developer. This helps alleviate the above point slightly.

I have heard many developers say “they aren’t testers”, “I don’t know how to test” etc and for the most part; I think that’s nonsense. If you understand code and how to use software, then you understand how to test it. Sometimes it is directly transferable skills, but I think sometimes you need to take a step back, “put on another hat” and try to look at it from another perspective. For example, you then think “If I was a user, what would I want to do?”, “if I hated the company and wanted to find a bug in the code, no matter what it is, what would I try?”. You poke it in different ways. I think if you fail in the skill of being able to “put on a different hat”, then Ron Gilbert is 100% correct.

Personally, I have experience as a software tester, and as a developer. I do think I test my own code better than many other developers – ones without that experience. However, I don’t think I test as well as I used to when I was testing someone else’s code. It mainly comes down to the point I mentioned earlier – the fact that you only test what you know you have implemented and don’t test the things you haven’t. I mean, if you did think of it earlier, then you would have implemented it.

numeronyms

When colleagues were talking about improving “accessibility” of our software, I saw them write “a11y” and wondered what crazy thing this was. It turns out it is a “numeronym” which is like an abbreviation, but really dumb.

What you do is keep the first and last letter, then any letter you remove between those, you count them, and put the number there instead. So there are 11 letters removed from the word “accessibility” so it becomes “a11y”. I also came across i18n (internationalisation), and K8s (Kubernetes).

This website has more information: https://a11yproject.com/posts/a11y-and-other-numeronyms/

I’d never really thought about what the W3 in “W3Schools” meant. Seems these stupid abbreviations have been around for years but haven’t really took off until recently.

Estimates Meetings

There’s a meeting that (I think) happens every week, where projects/enhancements are discussed and estimated. I don’t think there is enough time to really discuss them in great detail, and the people in the meeting don’t really care because they won’t actually be developing and testing them.

The thing is, it’s quite hard to judge how long something will take even when you have a decent understanding of the requirements, because you don’t know what the current state of the codebase is until you really start to dig into it. Also, you will uncover multiple problems and come across things you never considered earlier.

I think the key thing to remember is that ‘estimates’ aren’t supposed to be exact and are only based on the knowledge you currently have, plus additional time for contingency.

Even considering that, I think most people struggle to come up with estimates – even people that are regulars to the meeting and should be experienced at it.

One day, I received a message from my manager asking me to join one of these meetings. The meeting had been going for 10 minutes or so.

I join the call, and my manager tells the Host to re-explain. I felt awkward, he probably had done a great 10 minute explanation, and then they somehow decided they need my advice. So the Host reexplains. I ask a few questions, in particular about some previous functionality that had apparently been rolled back. I wanted to know why it was rolled back rather than fixed, because that would be key in coming up with an estimate.

My manager decides that we need the previous Product Owner on the call. She joins the call, and my manager asks the Host to re-explain. This is definitely awkward now. You can tell the Host is so frustrated, and he audibly sighs before explaining for the third time.

Now the group should estimate collectively, but everyone seems to want me to estimate it by myself. Why does everyone think this is a hard one to estimate? I end up being vague and saying it was 1-3 weeks. The thing is, they usually want the estimates to the nearest 2 week period, so 4 weeks is a fine estimate. I try to push the others to suggest their own estimates. The group decides it is too hard to estimate so the Host needs to come to a future meeting with more information. He must be fuming.

I get invited to next week’s meeting. There’s 2 projects to estimate – this time brought by a different product manager. This new Host says the first project was estimated a year ago, then put on hold. It was given 16 Weeks at a “high confidence”, however, there’s no notes to explain how they came up with that figure. But it is “high confidence”, so unless we know of any complications that have happened over the year, maybe we could stick with that?

Judging by the small amount of notes and screenshot, it looked like a few day’s work to me. One person says there’s some “cross-account functionality which is against the current architecture”. So now we are all scared. One manager states: “There’s too many unknowns, so let’s come back to it”.

So the Host moves onto the next project. It’s quite complicated and requires a good 10 minutes of explanation. When she got near the end, I thought “I hope we don’t estimate it; it will be a right laugh.” When she concludes her amazing speech, we decide “we need to break it down – it’s too big”.

So that’s 2 hours of meetings to estimate 3 projects and we didn’t estimate any of them. Good work team!

A Day In The Life Of A Software Developer #1

At the start of the year, I thought of a new blog idea. I could pick certain days to give a run-down of the day’s work, including some banter. I drafted this up before the lock-down when we were working in the office. I hoped to write a few blogs in the series before posting them, but that didn’t work out. I suppose I could still write some based on working from home, but there won’t be as much banter to write about. So here it is. Note, this was when I was in a team doing a Web-based project:

I get into the office and give my previous day’s work a quick test before I send a Code Review to my team. I load up the website, open the menu… the menu is screwed up and won’t open at all.

I couldn’t understand what happened. I’m sure this was working yesterday. I spent some time analysing my changes; I really can’t see how this has happened.

The Junior Developer gets in and I ask him if he can give me any ideas on how this can happen. “Oh, I saw this happen yesterday.“

“What? You saw it, and never said anything? You didn’t log it, or even post it on Slack for the team to see?“

“No, it is a minor issue“.

I was outraged. I’ve told him not to ignore issues. We are paid to make things work. Also, if it was logged, I wouldn’t have wasted time analysing my changes when the bug isn’t even caused by my changes. If a bug is logged, if someone assigns it to themselves, then you know not to waste time looking at it, because it is being investigated. If the issue isn’t logged, you can end up with 2 team members looking into it because they think it’s a newly discovered problem.

We end up finding the cause, and we correct it.

Someone talks about a Pop music concert involving the groups: A1, Five, Damage and 911. “Sounds like a traffic report“, Seth says. We all laugh.

It’s time for the Scrum Of Scrums. Dean is currently occupying the meeting room on his own, but on a conference call. Helen waits outside and debates with a nearby colleague if she should kick him out of the room. Josh says “maybe Dean is waiting for the Scrum of Scrums?“. Helen says it wasn’t the case. Dean sees them awkwardly queuing outside, so he quickly leaves the room. The rest of the participants for the meeting show up. A minute later, Dean comes running back exclaiming “I should be in the meeting!“. I laugh at him.

A colleague tells me about a massive rant on Slack about the poor communication from management. I read it. It is brutal, but they make a good point. The upper management have kept quiet, when they used to hype up projects all the time. Additionally, new staff members have been quietly hired, some have even quietly left. We used to get emails to welcome the new starters, and also got emails to arrange leaving parties for departing staff.

Shortly after, some guy I have never seen before is asking a manager, Tim, about the progress of some important bug fixes. When he leaves, another manager asks “who the hell was that?” Tim replies “he has been here for 5 months, he is the latest Project Manager”.

Well, that certainly validates the Slack rant about the quiet hirings. No one in my team knew who he was either.

I’m happy with my work, so I send a Code Review to my team. I check to see if there’s any outstanding Code Reviews that I can review. Last week, I had left a comment about lack of test coverage. The developer hasn’t bothered adding any more tests. I ask him about it, he seems to be playing dumb. I told him I would sort it. So that is tomorrow’s work sorted.

First job – The “just Google it” seniors

When you are learning programming, I think it does help to have some kind of mentor, or alternatively – many mentors. There’s certain aspects that are hard to learn yourself.

One simple example for me: Even though I could go out of my way to learn keyboard shortcuts, or find cool features of Visual Studio, I feel I have learnt the most by sitting next to someone while they work, or if they come over to help me. When they have the keyboard, they will bring up features I have never seen before, or manage to find files way faster than I could, and I’d be like “WOW! How did you do that?”. It’s amazing how much faster I am now, and it is mainly due to what I have learned from others.

When I started my first programming job, it was for a very small company (less than 10 staff), and I expected the Senior developers to help me a lot. Instead, when I asked them for help, they always said “just Google it”.

No matter how much I tried to argue with them that it would be faster for them to tell me, they would insist that I should Google it. If they were really busy, then fair enough, but I knew they didn’t have much work.

Sometimes you can find your answer fairly quickly by Googling. However, you still need to understand what you are reading, and sometimes it is far easier having someone explain it to you. It’s possible for someone to explain something in a few minutes, rather than reading a huge article for 20 minutes.

Also, you may not find your answer in the first article. You could have to trawl through several articles. Additionally, the articles could have a lot of irrelevant aspects to it that doesn’t apply to your situation, or confuse you further… possibly causing you to Google other terms you have seen on that article. You could end up with an hour passing by and you are left more confused than when you started.

Alternatively, maybe you find the correct answer, but the example code is in a different programming language.

Google only really works if you use the correct terms. If you know you have a problem but struggle to explain it, you don’t have much chance with Google, but an experienced human may be able to tell you the correct terms and concepts. At least a colleague has a good chance of understanding the problem you are trying to solve because they may have seen the requirements.

I vaguely remember spending ages trying to learn Threading, and I chose to use a “Thread” class. Then days later, when I had it working, I demoed it to the Seniors. They then said “why didn’t you use the Timer class, it is much easier?”

My thoughts were “why didn’t you tell me to use it when you knew exactly what I was working on, and knew I wanted some guidance?”.

It’s like they took great pleasure into watching Juniors struggle. They did mention that previous employees in my position left within 3 months, and they actually sounded quite proud of it. I always respect people that are smart and are willing to pass on their knowledge. It’s frustrating when you meet people that are smart but are so arrogant and patronising about it.