Wednesday, July 31, 2019

Power of Hindsight and Critical Mindset

Disclaimer: this story is roughly based on true events but this didn't happen in this format. All pieces on their own are real, but as a flow they are purely a depiction of my imagination. 

I was chipping away work, just like we do. A lot of the work was pull requests, code changes. Because, without changing something in what we deliver, nothing changes for the people who matter: our users.

Adding the thing was giving me pain. Not the physical kind of pain, but I could recognize the heavy feeling on the back of my head, it wasn't just going to go easy. And since I wanted my pull request to be small and done, and it was working just not pretty the way I like, I made a pull request: "a temporary solution" I labeled it.

I went home, relaxed, didn't think about it. Back at office, I got help from lovely colleagues, hit my head against a few more walls but at least this time I was not schedule pressed nor alone, and eventually I was again doing a pull request.

And again. And again. And again.

The flow of making small changes made me lose sight of all the things I had done. I had received feedback, but I didn't remember any of it. Did any of it change me for the future work I did? I really didn't know.

Like a person with a question, I wanted to answer my question. Jumping into the tooling, I started of a Jenkins job to summarize all the changes I had done in 2019.

Instinctively, I first counted the lines and jumped to judgement. If the number was big, I primed myself in seeing that perhaps I just did everything twice and did not remember. If the number was small, I wondered where my life went when this was the track I left behind.

Similarly, I eyed on the title lines. That already responded to my concerns on doing everything twice, because while each pull request had moved on its own though the systems into the masses of forgotten details, the titles represented what I had wanted to say about the thing as one liner back when I still had it in my fresh memory.

With numbers and titles, ideas of patterns started to evolve. But I wasn't done. There was a third level of remembering I needed, which was the comments I was getting as a timeline. Was I always reminded of the same thing, like leaving the salami pizza box on the living room floor, only to be kindly reminded it wasn't it place over and over again? If I created taxonomy of my feedback in hindsight, what would that teach me?

In the moment, if I would stop analyzing my actions with my most critical mindset, I would be paralyzed, too afraid to do things. But doing the same thing in hindsight, in cadence, as if I was looking at someone else (and sometimes, looking at someone else to have a comparison point), is invaluable.

Own your own learning. Never become the person the team always tells of the pizza box. Even if they created a linter for that purpose. Think, learn, and try something different. Fail because it is a First Attempt In Learning.

Don't wait for your manager to do this, know your own signature first.

Monday, July 29, 2019

Getting to Know Great People aka Call for Collaboration

Year 5 of organizing European Testing Conference has just started. We took notes of possible locations and decided to head to Amsterdam. And with the choice of location, figuring out the program comes next.

What I really want to do on conference talk selection is to invite people to speak. Save them the energy of preparing a submission that may end up rejected. Make them feel like they are recognized, noticed and thus invited. I could do that with many people. As soon as I find them, I could invite them.

But if I did that, what about all the awesome people I have not paid attention to yet, that I may not had a chance of meeting? They may not go to other conferences (where I find people), and they make not be particularly active on social media (where I find people) and they may not work for the considered-cool companies (where I find people).

To balance my troubles, since year 3 of European Testing Conference, we have done a Call for Collaboration instead of a call for proposals. And I'm learning how to best run it.

With a call for collaboration, we ask people to make their existence known balancing our ability to make good decisions on contents and using their time. To do so, we have asked potential speakers to do a Skype call of 15 minutes with us, to together discuss what their topic is and how that would fit our idea of the conference.

Here's the math I work against. 200 people submit. Each use 4 hours to prepare an abstract. That is 800 hours of abstract preparation. We choose 5%. 760 hours of other people's work is wasted, or hopefully thinking either a useful learning experience or reusable for other conferences. I rather use 50 hours, where individually wasted time goes down by 3,75 hours for every single submitter. I have to use 50 hours instead of 10. But my 40 hours are not of more value than their 760 hours. I may run a conference but I am their peer another tester, another developer, another manager.

There are people who find the idea of a Skype call a blocker. This year, we introduced an optional pre-screen route to just tell us the talk idea (not prepare the full abstract and description) in writing so that if the topic seems like the right fit, we could reach out to have our discussion in format they find comfortable.

Some people are terrified of the idea of being rejected on a face to face call, and we surely can never work enough to make people understand that it is not the call but the program fit. We select very small percentage of talks we are considering because we are running a 3 track interactive conference with a limited amount of talk slots.

The way we want to approach these calls is that it is a discussion of peers in testing to geek out on topics. We know everyone is worth a stage, and we need to try to build something that fits our vision for our stages. We try to find great stories, good illustrations, practical experience that highlights the work that is different enough from what we end up choosing otherwise. Trying to guess what might make it without the collaboration is hard.

Every year, we've had talks that were not submitted but ended up being discovered. They are often specific techniques that originally were part of an agile transformation story, a sidetrack where they deserved the full focus.

I hope you trust us to have one of these discussions with you. We seek a mix of testing as testers, developers, designers and managers know it. There is no reason we couldn't discover your experiences to highlight a perspective, and you identifying that idea of what you tick is our starting point for the conversation.

Join us and schedule your own session for discussion.  

Thursday, July 25, 2019

Telling what testers do in simple terms

As I was browsing facebook, I read a comment from a friend on testing stating there are three things all testers need to learn: automating, exploring and telling what we're doing in simple terms.

I find that automating and exploring are activities within the exploration when you know how to write code and can make thoughtful decisions on documenting with code or using throwaway code to extend your reach. Yet both these two things are so wide and varied that you can spend a lifetime learning how to get really good in them, and listing microskills within them would probably be more helpful. I know both of the two already, but I don't know all of them. How could I better show what I do and don't know?

The really fascinating part though was the third key thing my friend called for: telling what we're doing as testers. Explaining our worth. Explaining what we've done, what we'll do and why it takes more than 10 minutes. People's ideas of how testing happens are often so shallow that testing != testing.

Talking about what is going on in testing isn't simple and straightforward. And talking about status isn't a skill we all have equally developed.

I was explaining this on a ride today. If you imagine testing is like painting wall, you can expect that the work depends on the circumstances of doing the work. A breaking brush will make your progress slower, and you may not know all things that happen as you are just getting started. There can be nooks that require more effort. You could stop at any time, leaving an artistic impression. You could approach the painting in many ways. But if you leave a corner undone, it would at least be good if you can tell the others a heads up, rather sooner than later that you'll be running out of time and don't see yourself getting there. If you notice a part of the surface being harder to work on, make others aware of the surprises and allow them to pitch in and help with some of the parts.

Describing something invisible is much harder. Yet we see the same troubles over and over again on talking about what we're doing. We need to be getting better at explaining what we're doing in simple terms. And at minimum, we need to stop assuming people don't want to hear anything but a binary done vs. not done.