The book of the five rings: Why

I’m enjoying The book of the five rings (Miyamoto Mushashi) way more than what I thought. It’s not only teaching m about martial arts and war but all the lessons are easily applicable to professional and personal situations. Even if I wish to never have to apply this knowledge about sword mastering in my real life (although with my passion of role games, I know they’re going to be handy!), revisiting some experiences in my head as they were a duel, running through all the points Mushashi explain in this amazing book.

What hooked me to continue reading (on top of my inner nerd feeling like a ninja!) was how surprisingly relatable were the lessons and statements to my career. And we’re talking about a half a century old manuscript about surviving duels to the death.

For instance, Mr Mushashi talks about how a bad rhythm can kill you. Moving too fast in a fight is as bad as being slow, as you might make a mistake. That’s why he always keep a steady pace: fighting, walking and living. It allows you to study your opponent and plan a strategy.

He also says that repeating a technique that previously failed will kill you. You might be tempted thinking that the failure was because a bad performance, but the chance of another failure is really high. If you tried it and manage to survive, your adversary will be ready for the third time. And you’ll die.

He stays the importance of your environment. Every one of its details might be an advantage, and you have to avoid that they become an adversity. You should also have expertise with a large variety of weapons, not just mastering a few of them like other duelling schools. Adaptability is required if you plan to keep duelling and survive. People will bring new weapons and tools, and they’ll focus on countering the common techniques.

As he says: no technique is invalid if it makes you survive. I want to end talking about the book with some if its quotes:

“Do nothing that is of no use”

“It is difficult to understand the universe if you only study one planet”

“You can only fight the way you practice”

“You must understand that there is more than one path to the top of the mountain”

― Miyamoto Musashi, The Book of Five Rings

May the force be with you,

Gino

Advertisements

Efficiency obsession: Power Reading

My biggest quirk is this stupid obsession with efficiency. I’ve spoiled every aspect of my life because of this, and the saddest part is that I enjoy it. When I have a new toy the joy of discovering it ends pretty fast, and I just want to learn how to get the most out of it afterwards. Most of the times, I don’t even need to apply that knowledge; just learning, discussing and testing it is more than enough.

I do it with almost every aspect of my life. When a get a new video game and I enjoy the mechanics, I start learning and theorising how to min max it. How to get the most spending the least time, how to break its virtual economy with handmade cost-related spreadsheets, etc. When I walk, I always think the fastest way to get somewhere, even when there’s no hurry. When I have several episodes of a TV show pending, I watch them at 1.5x. Daenerys listing her titles improves at 1.5, believe me.

And obviously, it also affects my career. I won’t talk about its implications for my daily work now, but how it changes how I face my continuous learning. I’m in the first steps in my career and have plenty of free time, so I usually try to spend a fair amount of it trying new technologies, reading about last trends, doing courses and reading. It’s not always related to my field (like The game or The Book of Five Rings), but instead of reading fantasy literature (which I love doing), I’m focusing on amazing papers that teach me something.

But how is my stupid efficiency obsession affecting my reading? I don’t know how familiar are you with power reading techniques, but lately, I’ve been following this one. I’ve always been a fast reader, although my speed is heavily hammered with technical English-written books. That’s why lately I’ve been trying some of these techniques, to get better comprehension and faster assimilation of the concepts.

I know, the main concern is: you should be enjoying the reading, not rushing it! And that’s completely fair. But as I said, the main reason for reading these books is to increase my expertise in an area, expanding my knowledge, learning new approaches, and summarising the best ideas of it. Power reading achieves all these purposes, along with training a very useful skill in my opinion: reading a really long text and assimilating its key concepts.

“But reading fast is really easy, you only have to skip some paragraphs and voilà!”. I’ve also been there. I remember my tedious maths reads, and how I tried to skip everything that didn’t seem enough important. But this time, I have another powerful tool: this blog. For every of this book that I read, I force myself to think about a lesson learnt post, and I start writing a bullet point list of the main subjects and the things I enjoyed the most. Even if I don’t polish and publish the post, it forces me to understand and pay attention to the read!

May the force be with you,

Gino

How my desk affects my work

One of the amazing perks of a startup is the small office and teams, allowing you to spend plenty of time with colleagues from other fields. I’ll write a post with all the amazing things I’ve learnt working with product managers, designer, developers and customer support; but today it’s about something different. I want to talk about how changing who are you sitting with will drastically change your experience in the organisation, and even your career.

Keeping your team in sight-distance is easy with our size, and it gives us freedom to move around without compromising the Agile manifesto. We’ve also moved three times offices since I joined, and completely changed the org and teams a couple of times; so I’ve changed my desk on several occasions. I’ve been sitting close to the development team to convince them about the testing importance, with my manager to better define the roadmap and priorities, with the designer just because we’re close and I’m so funny she wanted me there (OK, no), with our customer support guy… and every single of those experiences gave me a better understanding about our product and mission, and taught me something. Both personally and professionally.

Some experiences were more enlightening than others. For example, working close an introvert colleague might produce less conversation about life, the universe and everything else; but you might be able to ask more details about his daily work, and how you can assist him. Other times is your colleague who directly asks you for help. And bonding just talking about the weekend is always a huge morale boost in the office, and you never know when you’ll need it!

For example, sitting with our Customer support guy has completely changed how I approach testing and building the product. It gave me a lot of insight about what the users are complaining about, he engaged me with the community (it’s really useful the I think I found a bug forum!), helped me understanding how to test something, and taught me some legacy parts of the platform. I also helped him understanding how we’re building the new one, reminding him when a change was going to be released, teaching how to find technical details of the cases, and giving faster answers to the user.

With this, I just want to point out that you should care about where you’re sitting, especially if they let you chose! This is going to be part of your onboarding, and it’ll shape your career and experience in the company. If possible, I encourage you to change your place from time to time and visit some of your colleagues pairing with them some days (more about it in future posts!). Less process and organisation empower us, and this is one of the main reasons why!

So look around your desk and think Who should be sitting with to better learn how things work? Who is going to teach me more about X? Where I can be more useful?. No good manager will block you to change providing a valid reason, and testing your manager with the question is valuable on its own. And then… share your experiences with us, please!

May the force be with you,

Gino

 

It’s always worse elsewhere

Yesterday I share a couple of beers with some old friends who also work in the Software industry. They’re working on a small Consultancy agency building websites using the same core, cutting most of the production costs as most of them use fairly similar implementations. Everything sounds right until they get surprised when I asked about their testing framework. “Well, before sending them to the client, we navigate through the site checking that anything breaks”. Fair enough, I don’t expect everyone to use Selenium. “The problem is when a client finds a bug. Most of them are part of the core so that bug is probably on every one of our projects, and we’re afraid of refactoring anything”. If the core is not a volatile piece of code, probably it’ll be a good investment to build some functional tests verification on top of your unit test. “Unit what?”. Bum. And then I remembered.

I was also part of a Consultancy brand (it was my first job in the industry). I remember the “we can’t afford to write the unit tests, our problem is really complex and we don’t have time, we’ll just verify it at the end”. I bought it. I truly believed that we were good enough that unit test was only a plus, and the projects were difficult and fast paced… NO WAY we could afford wasting time on tests! I remember some senior colleagues explaining that to me. Why would I don’t follow their example? They had way more experience than me, and they developed way faster. I wanted to be like them.

And I remember the struggles. I remember that every single bug fix carried weird and unexpected regressions. How the clients complained every week, and the constant fight about who is the responsible for the fix (Was it a bug, or a failure in the requirements?). The hellish deployments, the tedious manual verifications of just what was needed, the numerous problems with our version control tool as we always realised too late that the release didn’t contain that change.

I also remember the change. When I left the company and learnt something new in the next one. And then the next one. On my first day, one of my new colleagues was disturbed because I wasn’t writing unit tests. He didn’t even ask a reason, but I tried to convince him that they just slow my momentum. I remember his face. He just taught me how to make it easy, and handled me a copy of Clean Code. I had to pair with him and… Oh God, that was beautiful. He showed to me what TDD feels. And I started realising that, actually, the team didn’t spend that much time dealing with the horrors I was used to. It was so simple and beautiful.

That’s why I spent some time yesterday trying to show them the importance of this practices. Explaining to them why most of the companies they want to work in ask for TDD practices or writing functional tests. Exampling to them how they’ve been important during my projects. Giving them resources, guidelines and the chance to ask any question. But, obviously, I’m just a QA, so what the heck I’d know about coding.

Yeah, dear readers, it’s always worse elsewhere. That’s no excuse to not try to be the very best you, including the best professional you can be; but sometimes appreciating what you’ve learnt and why you’re doing it is needed. It is also important to identify who would use some help, and offer it. For me, life is how you feel sharing with the people you choose your knowledge, resources and smiles. I’ll talk in further posts about some of the

I’ll talk in further posts about some of the anti-patterns I’ve seen (and do) during my career, and some lessons I’ve learnt fighting them. But, for now,

May the force be with you,

Gino

Why being a tester spoiled my life

I truly believe that a great tester is born, as well as most other professions. Testing requires a strongly critical thinking, as well as perseverance and lateral thinking. There are some technical and products details that undoubtedly help in your daily work, but in my opinion, those skills don’t make a great tester on their own.

I’m not a great tester, and that’s what is driving me to understand, learn and practice how you become one. But I’m a critical thinker. I love breaking down situations too, in the calmest possible way, and identifying what is happening, which are the potential outcomes and how can it go wrong. I’ve been doing it my entire life, and probably that’s why I enjoy being a testing professional. But I can’t stop being a critical thinker in my personal life.

There are times, MANY times believe me, when spoiling yourself thinking what can go wrong will ruin an experience. There are times when understanding why you ended in some situation make it way less enjoyable. And, if you’re sharing it with someone, people will hate you when you try to anticipate the issues and prepare a plan B in advance. Some just want to do things, regardless of the result. A simple example is my peculiar relationship with food.

My mum in endocrinologist, and I grew up learning the calories of the food, which are their main nutrient and what is missing in any meal. And that has spoiled my life. I obviously eat junk food, and I enjoy eating colossal portions, but I can clearly point you how it will affect me, and what I’m doing wrong. So when I see someone eating a really big budget with doughnuts as buns, I just can think “SERIOUSLY??”, instead of enjoying it.

But peeps, if you’re cursed like me, remember that you can use it and become part of the testing community. Your colleagues will praise your ability to anticipate fires, and they’ll learn it after throwing away your recommendations; you’ll help people understanding why things didn’t work and you’ll show people that some details really matter.

This is why I’m still a tester. I spent part of my career pretending to be a developer, dreaming of being a designer and even thinking how would be producing. But I’m cursed, I was born to be a tester, and breaking things is SO funny.

May the force be with you,

Gino

The no-QA way

We’re still finding out sweet spot regarding Quality and there are always some developers that think no “formal tester” is needed in our process right now. This approach even gains more followers when you have an ex-Facebook in your team.

Don’t get me wrong, I never take the bait to jump yelling “You NEED me, this will be a MESS without me!”, mainly because I think this approach is as valid as any other if you focus on the right things, and meet some conditions. And I really enjoy discussing testing, especially when it allows me to understand my peers’ point of view.

So we started a conversation, but it didn’t lead to anything because we were just pointing the pointless parts of our current process, instead of really talking about how to make it work. Afterwards, I schedule some time on my calendar to sit in one of the meetings rooms and use the Whiteboard to clear my ideas. Would it be possible? What are we missing to get there? What would it offer us? How would it impact our team and process? Which are other solutions?

Then I felt way more ready to have that conversation again, but I decide it will improve with a broader audience, and sharing the questions in advance so everyone’s is better prepared. And, this time, I really enjoyed the chat. We still complained about what is currently failing, but we managed to come with tentative solutions. As well as some answers to the previous questions.

Let’s start with motivation. What would it offer us? The answer was almost unanimous: less friction in the process. As developers will be more autonomous and the QA layer is not going to be annoying, coders can focus on the code. It also carries some challenges, but we’ll talk about them later on. The goal is having a simpler and smoother process, and also, you don’t have to spend on QA itself. Win / win situation!

But, obviously, there are some requirements to get there. So, what are we missing to get there? First and more important, by far, is the culture of owning quality. If there won’t be a “quality gatekeeper”, everyone should be responsible for their deliverables quality as well as ensuring that everyone’s working on it. We’ve been moving towards that (as well as most of  the Agile testing approaches), but we’re not there yet and it’s really needed making this huge step.

This is especially tricky when you think about testing the “big picture”. It’s quite straight forward that when you deliver your solution, it should contain unit and functional automated tests verifying its behaviour. Hopefully, you have a culture regarding integration and component testing as well. But what about ensuring that the application works as a whole? Who will be responsible for that? Who will create, maintain and run those tests? What about the strange and complex cases that are almost impossible to automate? When and who should explore it?

One of the huge differences between the Facebook and our case is the amount of dogfooding that they do. We don’t have beta users, we don’t do canary releases, we don’t even use our tool that much internally. That’s one of the biggest challenges that we’d need to solve before taking this approach. It can be done, things like getting used to exploratory testing the application after when the development is done, but no developer is used to do it. One of the reasons why Quality Assistance keeps a testing expert available for the team is to help in this transition.

Then… how would it impact our team and process? Well, spreading out the responsibility about quality need some process changes, like defining some steps or techniques to review the solutions in pairs, not only reviewing the code and the tests. Get some understanding of the application that we’re building, and we need to play with it if we want to verify the changes. We’ll need more involvement with the product in order to find dependencies and better testable solutions from the beginning, although it will improve after the team gets better knowledge about it.

So, would it be possible? Well, one of the Agile principles I TRULY believe and share is “Fail fast, fail often”. As long as we timebox the try, set some retrospective meetings and are aware of the potential impacts; I think is stupid to answer the question instead of trying it out for a while, analysing and understanding the outcome afterwards. For sure, the first version won’t be the good one, but will teach us some tricks for the next one.

And which are the other solutions? I’m still keen on giving it a go, so it helps us identify what are we missing from the current approach and what we love from the change. But it’s always good keeping other solutions in mind. We can always go back to the old model of a QA wall where we throw everything, having someone to help us embracing quality and building tools to aim us (Quality Assistance), heavily invest in automation, or whatever pop your mind that might work.

There are thousands of different approaches to find Quality at Agile speed, and none of them works flawlessly. They neither work in every organisation. And I know a thing for sure: spending time and resources on finding a sweet spot for your process is always a good investment. Period.

Do you have experiences with a non-QA environment? I’d love to hear them!

May the force be with you,
Gino

My best colleague

Today I spent my retrospective break thinking what I value from a colleague and why. The reasons were simple: identifying what is important to me, especially now that I’m reading Subliminal; and understanding what makes them amazing colleagues will help shape myself into one. This is obviously personal preferences, and as you imagine most of the points are not even technical. So let’s start!

  • Passionate about their craft. When you work with people that love what they do, they’ll try to do it better. And, more importantly, passion is contagious!
  • Critic, but not a Grinch. The main difference for me is proposing and trying different solutions instead of just complaining.
  • Up for a conversation. I want to be surrounded but people social enough that doesn’t cause awkward meetings.
  • Skillful. Right now, learning is what drives me the most, and my colleagues are an invaluable learning resource!
  • Resilient enough to take some jokes. Unfortunately, I love joking and making comes, and I’m more than pleased to take them back. For me, having the freedom of pulling our legs from time to time without dramas makes a huge difference in the team.
  • Not a diva. This collides with previous points, but by experience: Discussing with divas about some work related subject is not productive at all.
  • As different to me as possible. Because skill is not the only subject I have to learn.
  • Autonomous without fear to delegate. This is really hard to find, but having a team that you know will get the task done, and that they count on you is the most productive environment.
  • Healthier work/life balance than me. I know I’m lacking it, and if I surround myself with people like me it’ll get worse.
  • Open to socialise. I’m always the new one, and I love being abroad. Having colleagues open for a beer is needed sometimes.

Which are the virtues you value from your colleagues? I’m trying my best to improve all the points in this list. If I wouldn’t enjoy working with myself, I can’t expect anyone else to do so.

May the force be with you,

Gino