Not excited about pull requests

There was a new feature that needed to be added. As the company culture goes, Alice volunteered for the job. She read code around the changes to identify the resident local style in the module, knowing how much of an argument there can be over tabs and spaces. She carefully crafted her changes, created unit tests, built the application and saw her additions working well with the product. She had the habit of testing a little more than the company standard required, she cared a lot of what she was building. She even invited the team’s resident tester to look at the feature together with her. 

All was set except the last step. The Pull Request. It had grown into a bit of a painful thing. Yes, they were always talking about making your change set small to make the review easier, and she felt this was one of the small ones, just as they were targeting. But as soon as her pull request was created, the feedback started.

If she was lucky, there was just the comments on someone’s preferred style on formatting - over all the codebases they were working on, there still was no commonly agreed style and automatic formatting and linting was only available on some of the projects. But more often than not, every single pull request started a significant thread of discussions of options of how the same thing could be done. 

Sometimes she would argue for her solution. But most of the time, she would give in, and just change as suggested. Or commanded, she felt. It was either a fight or submission. And the one with the power, reviewing the pull requests, somehow always ended up with their way. 

After the rewrite to the solution of the people leaving comments, Alice quickly runs unit tests. But that’s it. The version that ends up in production does not get the tester’s eyes before merging, nor the careful testing in the product context Alice put on the first version she created. 

Another time, her change was just a fix on something that was evidently broken. The pull request rumba started again, with requirements of cleaning up everything that was wrong around the place that had been changed. This time she gave up again - accepting the rejection of the pull request, someone else would get to enjoy the next try of fixing. The “perfect or nothing” attitude won again. 
When Alice was free to review Bob’s pull request, she too mimicked the company culture. “This is the way it works”, she thought. She felt that if she said less than others, it would reflect badly on her. So she said as much as she could say. Shared other way of implementing things. And just as Alice would change her code to comments, so would Bob. Knowing the difference of “here’s another way I thought of, for your information” and “I won’t accept without you changing this” had become impossible to differentiate. 

This story is fictional, and Alice (and Bob) was just the person that got on this fictional project. But the dynamic is very real. It happens to developers with all levels of experience, when the culture around pull requests goes into aiming for perfection instead of good enough. It happens with the culture of delayed feedback with pull requests, with refusal to pair. There’s many ways of implementing the same things, and sometimes arguing about my way / your way AFTER my way was implemented gets overwhelming. 

Here’s what I’d like to see more:

• suggest changes only when that is needed not because you can
• improve the culture created around “acceptance” power dynamic and remove some of the power reviewers hold as guardians of the codebase
• when suggesting extensive changes, go to the person and volunteer to pair. 
• volunteer to pair before the work has been done

Writing this reminds me how nice it was to mob on some of the code, when the whole pain and motivation drain related to pull requests was absent. 

Camps of testing

The testing world is divided, sometimes I feel it is divided to an extent that can never be resolved. Friendly co-existence seems difficult. Yet, the effort to work together, and to hear out the others, to have the crucial conversations about something all the divided camps in their own way hold dear needs to happen.

I think these camps are not clearly formulated, but they feel very real when you end up in disagreement. So I wanted to write about the three that came my way just today.

Testing should be a task not a role -camp

There's a significant group of people that have hurt my feelings in agile conferences telling me I am no longer welcome. Testing should be a task not a role is usually their slogan. They seem to believe that professional testers and testing specialists should not be hired, but all programming and testing work should be intertwined into teams of generalists. Of course generalists are not all made of the same wood, so often these generalists can be programming testing specialists, but the part about programming is often the key.

I've seen this work great. I can see it might work great even in my team. But then I probably wouldn't be in my team. And my team couldn't say things like "things were bad for us before Maaret joined". Because the things I bring with me are not just the stuff around automated or exploratory testing of the product, I also tend to hold space for safety and learning. And I do work with code, but more like 20% of my time.

I hypothesize that if this was the dominant perspective, we would have even less women's voices in software development. And I would choose having diverse views through roles over homogenizing any day.

Testers vs. Developers -camp

This is my reframe of the group of people I would think of as testing traditionalists. They're building a profession of testers, but often with the idea of emphasizing the importance of the job/role/position through pointing out how developers fail at testing. They make jokes on test automation engineers being not developers not testers (bad at both). They often emphasize the traditional tester trainings and certifications. They don't mean to set us up to two camps, but much of communication around us and them feels very protective.

I have seen this be commonplace. I have not seen it work great. Creating separate goals for testers (go find bugs!) and developers (get the solutions out there as specified!) isn't helping us finish on time, and making awesome software.

Developers working with testers in this camp have a tendency of becoming religious about Testing should not be a role -camp, if they care for quality. If they just work here and do what is told, they probably will live with whatever structure their organization put them into.

Testers and Developers -camp

I would like to believe there is a group of people like me, who don't identify with either of the camp archetypes defined above. They believe there can be professional testers (profession/role/job/position, whatever you call it) and some of them can be awesome with automation focus, and some of them can be awesome with exploratory testing focus. They might cross role-task boundaries frequently, in particular through pairing. The keyword is collaboration. Bringing the best of us, a group of diverse people with differing interests showing up and differing skills areas, into the work we are doing by collaborating.

This group tends to shift left, until there is no more left or right as things turn continuous.

Where does this lead us? 

As with the stuff around schools of testing, this is putting people into boxes that are defined through trying to describe what is good about the way I think. I will continue to evangelize the idea of letting people like me - and people like me 5 years ago - and people like me 20 years ago - enter the field and learn to love it as I have learned to love it. I know I make a positive difference in my projects. I belong here. And I know others like me belong here.

I want to see us thinking of ways of bringing people in, not closing them out. I'm open for new ideas how that could be possible for those who realize they want to be programmers only after they have become excellent through deep, continuous learning of things that are not programming but make us excellent exploratory testers. And it might take some decades of personal experiences. 

Playing with rotation time in a mob

A common thing to happen in a retrospective after Mob Testing is that someone points out that they feel they need more time as designated navigator / driver, "I need more time to finish my thought". Today, it happened again.

I facilitated the group on a 3-minute timer. I emphasized the idea that this is not about taking turns on each one of us executing our individual test ideas, but it's about the group working on a shared task, meaning same ideas, bringing the best of each of us into the work we're doing.

On two retrospectives with a 3-minute timer, the feedback was the same: make the time longer. So I did what I always do in these cases: I made the time shorter, and we moved to 2-minute rotation.

The dynamic changed. People finally accepted it wasn't about finishing their individual task, but to finish the group's shared task.

A lot of times when people feel they need more time, they are saying they have their own individual idea that they don't share with others. Longer time allows this. Shorter time forces the illusion of that being useful out of the group. 

A Search for Clear Assignments

I spent a wonderful day Mob Testing with a bright group of people in Portugal today. They left me thinking deeply on two things:

1. Importance of working in one's native language - the dynamic of seeing them work in English vs. local language was immense. 
2. Need for clear plans

I wanted to talk a bit about the latter.

I've been an exploratory tester for a long time. I've worked with projects with very detailed specifications, with the end result of having a system that worked as specified 100% but filled 0% of the real use cases the system was intended for. I've worked with projects that don't bother with specifications at all - all is based on discussions around whiteboards. And I've worked with projects where all specifications are executable, with the experience that to make it possible we often like to minimize the problem we're solving to something we can execute around. 

The first exercise we do on my mob testing course involves an application that has very little documentation. And the little documentation it has, most people don't realize to go search for. The three sessions we did gave an interesting comparison.

First session was freeform exploration, and the group was (as usual) all over the place. They would click a bit here, move to somewhere completely different, check a few things there and make pretty much no notes other than bugs I strongly guide them to write down. The group reported as experience that they were "missing a plan".

Second session was constrained exploration by focusing on a particular area of functionality. The group was more focused, had hard time naming functionalities they saw and finishing testing of things they saw. Again the group reported as experience that they were "missing a plan" even if the box kept them more cohesive in the work they shared. 

The third session was tailored specifically for this group, and I had not done that before. I allowed the group 30 minutes to generate a plan. They selected a feature with a web page claim after discussing what the unit of planning should be (use cases? user interface elements? claims on the web page?). Before spending any additional time hands on with the application on top of the two sessions earlier that had barely scratched the surface of the feature, they cleared up their plan. 

The interesting outcome was that

• They found less bugs
• They were happier working against a recreated (low quality) checklist
• They missed more bugs they saw while testing and dismissed them as irrelevant. 
• I saw some of the symptoms they saw as symptoms of something really significantly broken in the application, and having seen them test, I now know how I could isolate it. I suspect there are only a few people in that group who would know what needs more focus on. 

I take this as a (trained) wish for clear assignments, clear answers and generally a world where we would have our tasks clear. I find myself thinking it is not the testing that I know, and that it is the testing a lot of my automator colleagues know. And that in getting out of that need of someone else placing us the "plan" and being active about making and changing our own plans as we learn is the core to good results. 

We all come from different experiences. My experiences suggest that my active role as a software learner is crucial. Having documentation and plans is good, but having the mindset of expanding those for relevant feedback is better. 

My team is looking for a manager

I love my team, and I love my manager. My current manager however has come to the realization, that having 50 direct reports is too much, and while he always has time for me, there might be others that need different type of support from a manager and don't get the same access.

At first, he opened two manager positions internally. Both my manager and my team encouraged me to apply for the one for us, but I have other aspirations as I plan on being the best tester there is, and if I move, I will become a software architect. A trip (again) to management sounds like the wrong move for me. Everyone else had similar ideas internally, so we ended up where we are now: we are looking, externally for our team manager.

We're a really truly self-organized team (no product owner experiment ongoing, the team decides) and need a manager who understands what that means. And an ideal person for the role would be someone who is half tester (or dev) and half manager, and would like the idea of working as part of the team for some of their time.

As we were discussing this yesterday with the team, devs expressed that they'd love a tester. Well, they have good experiences of testers. And to clarify, they said it could be either someone with manual testing or test automation background.

So I call out to people I know: would working in Helsinki, in a half tester half manager role with awesome team becoming more awesome all the time be something you'd aspire for? If so, this is the position you should apply for.

Just a few words what usually happens: my manager screens candidates and discusses the manager part. He involves the team in another interview.

We're also looking someone with good understanding of full-stack development into another similar position for team that does Java/Javascript/AWS.  And if you're like the team members we have now, aspiring for learning more on how to build awesome products and you want to spend time with an automation emphasis, we're also looking to replace one of our full-time testers as they turn into a cyber security consultant.

All these 3 people end up in what I consider the product I work with, consisting of 7 teams. If you'd like to try out something further from me, my manager is also looking for a tester for cloud protection solutions.

Observations on Survivorship Bias in Programming

Programming is a fascinating field of study. For a long time, I was discounting my programmer abilities for never staying around one language long enough to get fluent with syntax, and if you need google to remember when others (supposingly) didn't, it must mean that I'm not a programmer.

Mob programming changed that for me. I saw that others needed to google heavily too. Just like me, they remembered there were many sorting algorithms, but needed to check how a particular one would be implemented - they knew, just like me, the word to google for. And obviously, it's not like that is a problem we need to solve every day in the real life of a programmer, that's where libraries come in.

There's still other things that come in as a little voice in my head, trying to talk down the programmer me.

• I don't take joy in all the same types of programming work as others around me do
• I don't pay attention to all the cool libraries that are emerging and their inner workings for comparison purposes, still often happy to go with what I got
• I'm more interested in mender than maker types of programming

I realized that instead of listing the things I do, my voice inside my head lists the things I don't do. And as so many women before me, when I don't tick all the possible boxes, I don't apply. Instead of a job application, I do this on what I identify myself as - usually as a tester, not a programmer. Yet recently working with my inner voice, as (polyglot) programmer in addition to all the other things I am.

There's a thing referred to as survivorship bias. It is our unfounded belief that when we are successful, the things we did are what are needed for success. All of this, while there might not be as strong correlation as we like to tell ourselves.

So if a programmer does well mostly talking about technologies in particular way, both they and others around them attribute the visible interest in technologies as a reason they are a good programmer. A new line to a list of what we must be to qualify is born.

If a programmer does well not collaborating with others, just focusing on solo work to think deeply around the problem, both they and others around them attribute ability to work alone as a reason they are a good programmer. A new line to a list of what we must be to qualify is born.

There's many behaviors we see successful people do. Without mobbing, the control on what people choose us to see is on them. But each thing creates a new line to a list of what we must be to qualify. 

Survivorship bias is strong in programming, and it results in lists that feel impossible to tick. And when the visible behaviors around you differ, it can be really easy to discount what you are.

We need to make it easier to be a programmer. It's not an end, it is a journey one can start. And there's many paths we can take. Be careful not to force the path you have chosen, be open to other options. 

Why Do I Go to Conferences?

I find myself asking this question more often these days: why do I go to conferences? And in particular, why do I speak at conferences? And my answers vary, as I really don't know.

This week I spoke at Oredev, a developer conference, and felt totally disconnected and invisible. I did not talk to any new people. And new people did not talk to me. At first, I was quick to blame it on a tester identity, but it isn't that as I also identify as a polyglot programmer. I just did not have the chances for a discussion without first being active on it and even when I did, topics changed from tech to life. I listened to many sessions, some really great and others not so much, and came back with a decision on cutting down on conferences.

I used to get learning from conferences, but now my "being aware of techniques" learning quota feels full. Knowing of AWS, SAM, lambdas and step functions takes me somewhere, but the real application of those ideas takes me a lot further. And conferencing is threatening my time for practice.

My situation with this is not quite the usual one. I've been collecting the number of talks I do per year, and I already decided to cut down a year ago. Yet, looking at where I ended up isn't exactly showing the commitment: I have 27 sessions in 2017. 30 each year for 2016 and 2015. At this point of my life, talks emerge from my need of organizing my thoughts and driving my learning, and there are smaller time investments that would give me the same value.

So I wonder if people are finding pieces of joy, enlightenment, thoughts from whatever I end up sharing. Maybe that is worth the investment? There was one women I can thank for from Oredev that really made my day, coming to say one thing to me after my talk: "Thank you for speaking. It is so wonderful seeing women in tech conference stages." Most people say nothing, and pondering on this made me realize one of my speaking motivations is that that I crave for acceptance and acknowledgement.

Thinking a little further, I was thinking of the test conferences I find the most valuable for me: TestBashes. I've come back from those with new colleagues in the community to learn with, even friends. People I get to meet elsewhere, who bring so much joy into my life. But in particular, I remembered there is one accomplishment from each test bash that fills my heart with joy: I came back with a connection that created a new speaker.

Thank you Gita Malinovska, Bhagya Perera and Kate Paulk for making me feel like I had a role to play in the world seeing how awesome speakers you are. Gita and Bhagya I mentored in speaking after TestBashes brought us together, and they never really needed me but I needed them. Kate blew my mind with the discussions we had in TestBash Philly a year ago, when she seemed shy to take the stage, and I feel so proud seeing she delivered awesome in TestBash Philly this year.

There's a lot more names that I could drop that make me feel like I've served a purpose. But these three remind me that without going to conferences, our paths might not have crossed.

So I go to conferences for:

• Collecting ideas that I need time to turn to actions at work
• Making friends and maintaining our relationship
• Encouraging awesome people to be the inspiration on stage they are off stage

I speak to make it cheaper to go. I speak in hope of recognition. I speak in hope of connection, as I have hard time initiating discussions. But most of all, I speak to sort out my own thoughts. 

What are your reasons? 

Making Everyone a Leader

A year ago, some people were fitting the "Leader" title for me in the context of the testing community, and I felt strongly about rejecting it. We have enough of self-appointed leaders, calling for followers and I felt - still feel - that we need to stop following and start finding our own paths, and just share enthusiastically.

Today, someone was fitting the "Leader" title on me in the context of work and our No Product Owner experiment. I was just as quick rejecting it, but this time realizing even more strongly that I believe that for good self-organizing teams, everyone needs to become a leader instead of one self-appointed or group-selected leader.

I believe our No Product Owner experiment will show its best sides if I manage to avoid being appointed the "leader". There will be things where people choose to follow me, like the idea of experimenting with something we thought is out of our reach, meeting people who "never have time" yet find time in three days when we ask, imagining the possible. But each one in my team will lead us on different things, I follow with joy. Today I followed one of my developers on them leading the way on solving customer problems and they could use my contribution. I followed another one of my developers in supporting him when he imagined a feature that we thought wasn't wanted that turned out to be the "dream we did not dare to hope for". I followed my two tester colleagues in solving puzzles around automation where recognizing an element (no Selenium involved) wasn't straightforward, and working together was beneficial.

Everyone has room to be a leader. We don't have to choose one. We can let one emerge for different themes.

And what makes a leader, anyway? It's the followers. I choose to follow leaders in training, enthusiastically. It does wonders to how my group works. Maybe it would do wonders on communities too? 

Trawling for feedback

As a team without a product owner, we needed to figure out what is our idea of what someone with product management specialization could bring us? And we hit the discussion around the mysterious "customer voice".

At first we realized that having someone allocated as a "customer voice" with "decision power" (a product owner), isn't an automatic ticket for the team to hear any of that. So we ended up identifying a significant chunk of work the team isn't doing, would love done better and goes under the theme of trawling for feedback.

With customers in the millions, there's the feedback we get without them saying anything through monitoring. Knowing when they have troubles, knowing when they use features we think they must be using, all of that is primarily a privacy but then a technical challenge. Just the idea of going for no product owner made us amp up our ability to see without invading privacy. It was necessary before, but now it was our decision to include the tools that improve our ability to help our customers. Mental state does wonders, it seems.

Then there's the feedback that requires time and effort. Reading emails and replying them. Meeting people on specific topics and meeting people on general topic for serendipitous feedback to emerge. There's the skill of recognizing what feedback is critical. Being available for feedback, and identifying what of it is the core, not the noise. And passing the core to people who can do something about it - the team.

We realized there is a fascinating aspect of timing to this feedback trawling. Think of is as comparison to trawling for fish.

If you get a lot of fish without the proper storing and processing facilities, it will go bad and get wasted.

Feedback is similar - it is at its maximum power when fresh. That extra piece of motivation when you see the real person behind the feedback gets lost when we store the feedback for an appropriate time to act on it.

Having to deal with lots of fish at once creates costs without adding much value. 

While writing down a thing is a small cost, going through all the things we have written down, telling people of their status, and our ideas of their importance isn't a small cost anymore.

If you pass a fish from the fisherman to the second person in the chain, it is not as fresh anymore. 

First-hand delivered feedback to the developers just is different. It's more likely to be acted on the right way, with added innovation.