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

Tester’s commitments v 2.0

I’ve already talked about James Bach’s tester’s commitments, but I have problems making that promise to my colleagues, as I don’t share some parts of them so I want to create my own version. I want to include Quality Assistance values, as well as some experiences; and keep them as short, simple and relevant as possible. These are my commitments:

  1. I provide a service. You are an important client of that service. I am not satisfied unless you are satisfied.
  2. I am not the gatekeeper of quality. I don’t “own” quality. Shipping a good product is a goal shared by all of us.
  3. I will assist you in the design of the product to ensure its testability.
  4. I will support you in any task to deliver a better quality product.
  5. I will provide guidance in your testing efforts, sharing my knowledge with you and helping with any tool or technique needed.
  6. I will learn the product quickly, and make use of that knowledge to test more cleverly.
  7. I will help you identifying important things to test first and try to find important problems first.
  8. I will strive to test in the interests of everyone whose opinions matter, including you, so that you can make better decisions about the product.
  9. I will write clear, concise, thoughtful, and respectful problem reports. (I may make suggestions about design, but I will never presume to be the designer.)
  10. I invite your special requests, such as if you need me to spot check something for you, help you document something, or run a special kind of test.
  11. I will not carelessly waste your time. Or if I do, I will learn from that mistake.

I know that the list will evolve with time and experience, but these are the commitments I make today for you.

May the force be with you,

Gino

My experiences with pair programming

Pair programming has been one of the buzz techniques for a while now. In our industry, you can find groupies of it, professionals who understand its value but don’t know how to practice it and others who don’t see its value but will defend it anyway. Its value has been proved over and over again, so any developer who talks against it will lose points with his peers.

But I’m not here to talk about industry trends and tabus (microservices as the new default solution). but about my experiences with Pair programming, what I’ve learnt and where I’ve found value using it. This is the direct response of a “Which are the downsides of pair programming?” question during an interview. So… let’s start!

In most situations, when I’ve worked with developers pairing (either between them or with me), I’ve got way more out of it than the downsides. That’s why I’d love to start with the obvious advantages of the technique:

  • Getting early feedback. Code reviews are a standard nowadays, and pair programming is a live code review where someone is questioning your engineering practices. Also, it helps to spot some major issues.
  • Learning from different skillsets. Every developer follows his own book and learning other ways to do things (even if the difference is just minimal) which enrich your solution’s toolbelt.
  • More polished deliverable. When you deliver something after pairing, you know that it had been reviewed, probably tested (even if it’s just in your peer’s head), better practices has been followed (every shortcut will need an explanation, and you want to impress!). In my experience, pair-developed features need fewer interactions, particularly when the requirements were fuzzy.
  •  Work out assumptions and incomplete requirements. When requirements are not completely specified having someone asking you about the unconscious assumptions that you are taking allow the team to raise the correct questions to Product, and therefore need fewer iterations or (even better) don’t release with assumptions totally unrelated with the product. This is more powerful with cross-functional pairing techniques.
  • Cross-functional pairing. Luckily, as a Software Developer in Test, I’ve paired with programmers to get a better understanding of the solution, as well as helping them identifying potential problems and building more testable applications. I’ve seen this with Product people as well (designers, business analysts, etc.), although in that case instead of pair programming I’d call it assisted programming. Group programming is one of the evolutions, and there having cross-functional helpers will greatly enrich the development.
  • Avoiding the zone (or Flow state). Pairing prevents a developer to entering the Zone as we know it. You can get to a highly productive state with your partner, building momentum and getting answers and solutions straight away. As we stayed in the Clean Code review, some professionals try to avoid the Zone as it can prevent good practices being followed.

On the other hand, I’ve also discovered that Pair programming doesn’t have the same level of productivity (nor viability) on every given situation.

  • The speed. This technique may slow down the development, especially until the pair learn how to work together and build some momentum. It heavily varies on the developers itself, as it is…
  • Difficult for some archetypes. There are developers that don’t know how to pair, or they just can’t. They’re used to having their own introspection moment, usually relying on the Zone to get the job done at good pace. This is an amazing technique to spot this kind of developers if you want to avoid them.
  • Building dependencies. Some people get comfortable and rely on the partner to deal with certain kind of jobs, building a dependent relationship where instead of learning they can just use each other. Again, luckily this is not always the case, and it helps to spot this kind of developers to avoid them.
  • Avoid the zone. There are developers that heavily pursue getting into the Zone.
  • Requiring a pair. Working on startups, when you try to build cross-functional Agile teams it’ll be hard to find a pair to code with. If you need 2 frontend engineers, 2 building the services, 2 dealing with the operations, a designer, a product owner…

Which are your experiences with Pair progrmaming? Did you find it useful? Did you like it?

May the force be with you,

Gino

Lessons learnt from Clean Coder

Previously I talked about Clean Code, I want to focus this entry on how Clean Coder:A Code of Conduct for Professional Programmers (Robert C. Martin) made me evolve professionally. This book focuses on the professional aspect of a developer: the interactions with the rest of the team, the responsibilities of the roles, etc. I don’t know how to keep things short so let’s start with it!

How to manage estimations and its importance. Now you always have to work as a team, and in order to manage projects you need some time of estimation, and its the responsibility of the programmer to be as accurate as possible (and to research and train the technique).

How to interact with other roles in the Software Industry. Skills like managing expectations with the stakeholders, getting the best out of your QA, understanding the differences between a development manager and a developer manager, etc. A professional programmer is not only a good coder but an amazing team player. So take so time to learn everyone’s role!

The professional also carries the responsibility of saying no when the situation requires so. Everyone can say yes to anything and then deliver a shitty result, but you have to raise your hand when a situation will undermine your craftsmanship and end with a compromise in the Quality. Things like repeatedly doing overtime will end with some buggy and unmaintainable code, so saying no when there is no plan be, or the plan is to stay in that situation for longer than it should, it’s your responsibility.

Managing your time and schedule is also a really important skill everyone should learn. Uncle Bob talks about Pomodoro and other techniques, and it was the first time I realised about these amazing approaches. This has been a subject I’ve been working on for so long that you can see some of my latest results here.

He also made a controversial statement which I share. The Zone, even if you feel productive while staying on it, should be avoided and only used when the situation requires to. Entering that mind state will make you drop some of the best practices and induce you to decisions really hard to tackle and fix. That’s why he recommends not to listen to music while programming (making it harder to enter The Zone), and activities like pair programming or taking breaks from time to time (Pomodoro).

As said during the Clean Code summary, he considers Unit test as one of the main sources for code quality. If something doesn’t show how it works in a test, then you can trust its code.

A good professional is responsible for his art, so you have to allocate some time to train and improve your craft. Part of that time should be given by the employer, but you have to invest some of yours to stay always on top of your game.

He also recommends techniques like code katas to interiorize new languages, frameworks and tools; as they allow the practitioner to focus on the changes (as the problem is already known and mastered). He encourages as well to warm up with a coding kata before starting the working day, helping with all the bugs and failures that get introduced while you’re still getting into the programming mindset.

Personally, I found this book even more interesting than his Clean Code brother. This was the first time I start thinking about the surroundings of my career and how to become a better professional dealing with them, instead of just focusing on improving the code itself. A highly recommended read!

May the force be with you,

Gino

Gamificating testing

Gamification is one of those buzz words that you can easily find in articles, not only relating to the Software industry. There are numerous examples, both successes, and failures, but I want to talk about applying some gamification concepts to the testing world. I’ve never heard of any case, so I’ll talk about some things we tried and ideas I want to try in the future.

I’ll define gamification, so we are on the same page, as the application of gaming concepts to make a process or task more appealing to the practitioner. It usually involves a point system so the player can brag, some tier levels and perks related to them. In some cases, you don’t even have to give real rewards, like Reddit’s karma or StackOverflow’s reputation, as they rely on the power those systems have to gain recognition in very large social groups.

Obviously, they’re not appealing to everyone, although in my experience I’ve found some key factors that would dramatically increase its success like having a large enough group to contain some advocates of the game. There are always going to be detractors, but if you have enough people enjoying it the ball can keep rolling, and most of them are going to start realising the value. Keep the points meaningful and not easily obtainable, usually involving the players itself as the ones giving them. Allow players to brag about their points usually sharing a leaderboard. It’s usually better to keep rewarding the top players but avoid punishing the ones who doesn’t get involved.

How does this relate to testing? Well, as you know, we’ve been trying Quality Assistance for a while, and the biggest change is to convince everyone that Quality is a shared responsibility, and we expect some deliverables from them; for example developers should include their automated tests in the reviews, should spend some time testing a new feature, etc. One of the solutions we tried was including a point system where we reward the programmers who focus on quality, especially when they went above and beyond creating a testing demo, including non-functional tests, refactoring for testability or asking for help. We had a “testing padawan” in every team to understand how was it going. This way we could weekly showcase those coding rock stars: They felt rewarded, and we learnt which team should we focus our efforts on.

Other places where I think gamification would help us is in our user testing group. While we work on new products we seek for user feedback either for the prototypes and early builds. We find them among friends and family, power users or just random people. Ideally, if we implement a gamification method between our users, we can find the most engaged ones and reward them giving input for the new products, although this can be dangerous as most of the times new features are not targeted for these users. But when someone listens to you, it’s easier to get attached to a product. And that’s never a bad thing.

Can you think of any gamification example in the Testing industry? I’d love to hear it!

May the force be with you,
Gino

Developer archetypes

During my career, I’ve encountered numerous and very diverse professionals, which is one of the best perks of teamworking: you have to try really hard to not learn something from the experience, because learning how NO to do things is even more important than learning the best way. Reacting differently is always a factor that will empower the team as it’ll allow a wider expertise. But, obviously, there are some behaviours which help to build teams, while others make it challenging.

As most of my working hours are between developers (right now I’m the only QA for 15 programmers), I want to focus today on describing the different developer archetypes regarding Quality I’ve found, as well as sharing some tricks I’ve learnt dealing with them. Let’s start!

The “testing is not needed” one, which have two branches: “I’ve never seen proper testing, so I don’t see value in it yet”, typically found on junior profiles or professionals coming from experiences where no one cared about good practices; and the “My code doesn’t need to be tested” which can be even found on really senior profiles. For me, the wisest tip is focusing on them as few as possible.

When they start seeing the results from the others and realising that they’re getting behind, that they’re less shining, is the time to offer yourself to help them as much as needed. Your job is to make their work look awesome, don’t forget the commitments!

The “I don’t have time for testing” one, typical from junior profiles as well. They know that writing automated tests is valuable because… Well, probably because they’ve read that somewhere, and they know people expect it from them. Most of the cases they think there’s no time because they don’t know how you make them, so it’s a daunting task. The best that you can do is showing how easy is to get value from the tests. Handle them a framework with an example, pair during their first implementation and support them at the beginning.

If you see they become needy (what happens way less than I thought), gradually stop giving them that much support, coming from time to time to ensure they don’t get stuck. I’ve found that sometimes spending time explaining how this new skill is needed is they want to step up their career at some point towards “one of the big names” is really helpful.

The “I’m too biased to test” one, especially when you start talking about approaches like Quality Assistance and making them autonomous sharing the testing responsibility. They’ve heard that a developer can’t test, he’s biased, and that’s the perfect excuse to not even try it. The most successful way I’ve found to deal with this is focusing on the keener to test team members, sit with them and teach some tricks and examples. They love solving puzzles, and breaking systems!

When those colleagues are motivated enough, convince them to pair with the “biased” developers so they can test the new features together. Seeing a peer testing their code will show them that it’s possible to do it, and realising that when they review the dev on test feature finding way fewer bugs… Well, data is more convincing than words. And shame, more convincing than anything.

The “So, how can I test…?” one. This is the dream. These developers know what testing achieve, they understand that delivering a solution doesn’t mean anything unless it’s a quality one, they see value in the automated tests and prefer being the ones finding their shit. After seeing them work, and enjoying the results of their effort (fewer errors on their developments); they get your trust and you can focus the efforts on the rest of the Archetypes.

That doesn’t mean all the work is done. We assume most companies aim to have these developers, and sometimes you’ll be blessed with loads of them in your project. Now you can start working on what they’ve hired you to do. You discuss with them to build more testable products, review their work, build additional tools, assist them on the hard-to-test features, and experiment with new approaches. This is the dream. And that’s why I’m spending all my effort right now to convince as many developers as possible.

I don’t want to finish without naming one of my favourite archetypes: the “then, what are we paying you for?”. At the beginning, I wanted to answer them in a similar way but… wasting energy won’t take you anywhere. That’s why I keep it simple now. “My job is to review you until you become autonomous. Then, they can make me redundant or I can start focusing on the interesting stuff: doing whatever it takes to increase the Quality of your deliverables”.

Have you encountered different developer types?

May the force be with you,

Gino

Defining our QA process

As I mentioned before, we’ve been going through some structural changes recently. If we add to the equation a really tight deadline where we decided to drop the process and survive however we can; now we have some madness around. And, one of the craziest fields is quality and testing.

That’s why I spent half of today in a meeting room discussing how can we do, what can we try and why is so important. And, guys, I have to admit that I’ve enjoyed the experience. This is one of the first times I have to propose and implement a process on my own and… Such a shame I can’t share with you all the details and products from that meeting. But I can tell you what worked and what I learnt.

I always fancy starting with why we need the change; this helps to highlight the issues, stating that it’s not only impacting the people involved and we have to work together the solution. I started detailing how every team is dealing with quality right now (without process, every team has adopt QA on his own way), summarising it in bullet points as potential solutions and asking a really simple question afterwards: “right now, if you have to develop a new feature or refactor a piece of code, would you be confident enough to push it to production right away? “.

Obviously, we don’t want to push things blindly, even if the developer promises us how complete and awesome the solution is. But, if the one doing it doesn’t even have the confidence to make the step… Something is missing. So we start discussing why that was happening, and what it needs to change to get there. As you assume, the first solution was obvious.

Automation. We know how useful it is, especially helping us trusting a refactor and preventing regressions. As you should know, the team less confident about their code changes was the only doing less (none) automation. In my opinion, the main reasons were: lack of expertise, and without knowledge is easier to see some practices daunting and don’t realise its value; and a more complex automation problem, because UI are always more tedious to programmatically test, and without expertise you don’t know how to build testable products.

We discussed how to incorporate automation in our process, how can QA (just me) and Product leverage the task, and some technical details about the challenge. As some teams are using BDD, I propose The Three Amigos technique to define the tests, and I’ll provide them with examples, guidance, and support during their implementation; although they were really vocal about being the ones trying different frameworks and solutions. Fair enough, it’s going to be your child, I understand you want to choose it. Automation, checked. This will prevent some of the regressions, build back some trust and make them realise how untestable their current solution is, keeping that in mind for future builds and projects.

But, I’ve already told you that Automation is not the one and only solution, and there are some circumstances and problems where automation is just the inefficient and overkilling solution. You won’t write every possible test in the code, as it would be impractical. That’s why testing it manually, particularly new features, and getting feedback and soon as possible will help us meet Agile speed. Remember what I said of Quality Assistance).

That’s why I proposed QA Demos, where the developers show the new feature to Product or QA, and we try to break it in front of them for some short period of time. This way we can get the obvious feedback really fast, and developers can learn how we test. If we do it enough times, there is going to be a moment when they’ll be able to do it autonomously, knowing that their releases will contain fewer bugs, and building a better product because they have tested in mind. It’s a huge win situation, although there are some challenges (the biggest one I want to talk about it in my future post: Developers Archetypes).

This solution was less popular. They were sure that asynchronous solutions are more efficient, so deploying something and testing it whenever we can makes things faster (apparently, the industry doesn’t share that statement). Luckily, we decided to try it out in a couple of stories per sprint and check how it goes.

I finished the meeting with the QA manifesto, wrapping the actions, discussing some of the details and feeling that I’ve made a huge step in my career. I’ve done it on my own, and now I’ll try my best to achieve a process where we can trust our changes, and hopefully where the Quality Assurance role is not needed because everyone is ensuring the Quality of our product across all the journey. So, guys, I encourage you, if you don’t agree with the process, if you spot lacking points, try to change it. People is keen to improve what they neither like. They’re more supportive than you think. Well… Sometimes.

May the force be with you,
Gino

Exploratory testing: Testing tours

I’ve been talking about exploratory testing for a while now (either about Rapid Software Testing or Quality Assistance). I like to focus in this series on some testing techniques that I’ve learnt from the Exploratory world, although they can be applied to any testing practice. In this particular case, we’re going to describe some Testing tours.

Testing tours are guidelines and examples to follow when approaching a new testing challenge. They help to identify where should the focus be, and highlight components highly automatable as well. They’re well described by James Whittaker in Exploratory Software Testing and How Google Tests Software. Let’s example some of the tours now!

  • Demo tour. Find what’s going to be showcased, which are the biggest selling points and verify them. If that’s where the money is, spend more time polishing it. View the tests from the perspective of the sales staff. Are you able to easily show the functions of the application? Does the application execute as described by the literature?
    • A variation of this tour is called the Skeptical Customer tour in which the tester would get in the mind of a customer asking a lot of questions about what is being demoed. This tour should test the answers of questions such as “what if we did this?” or “how about if I want to do that?” Imagine the customer that will want to prove that the demo is marketing spin. What kind of questions would be asked?
  • Landmark tour. Identify the components of the system, the functionalities of every component and the capabilities (or actions) or every functionality. Having that list, you can check the transition between states (and empower automation). This list must be prioritised, and development should be involved to complete it. A nice trick is to share with the team the priorities, everyone would detail the list in order to get their work prioritised. Keep in mind that navigation is important as well (different links to reach the same page, keyboard shortcuts, etc.).
  • Intellectual tour. In this tour, the tester needs to be asking the hardest questions. What is the most complicated function that can be executed? Test the limits. What inputs would cause the most processing? Which queries would be the most complex? Execute the functions of the power user.
  • Fedex tour. Identity the points where data gets modified or passed by, and focus on them. Add verifications around those boundaries. Things like: where the data gets displayed, localised, formatted, extended, etc.
  • After-hours tour. Focus on the maintenance tasks. Backups, cleaning, garbage collector. Check that the environment is clean after running those, and their task is being accomplished.
    • A variation of this is the Morning-Commute tour where the tester focuses on starting up the application and the initial state of the system.
  • The garbage collector tour. Like a guy collecting trash, the tester runs the same operation for all the neighbours (menu items, tabs, etc.). It’s not testing exhaustively, but checking that everything is in the place, and there are no obvious issues.

You can find more specific tours in the mentioned books, as well as lot of literature about which’s the best tour, keynotes from testing mesias, or implementation examples (in this case, from Google). Have you applied any of these tours personally?

May the force be with you,

Gino

Is moving abroad a company perk?

I know that Internet is saturated with this subject, but I got asked several times about it and having a post to share instead of hand crafting a response is going to be really handy. I’m going to keep it as personal, funny and anecdotical as possible, making it different. Also, you know that I’m following the 10-idea movement, so I’m going to use the same schema to detail 10 tips I want to yell to my 5-years-ago self. Let’s do it!

  • Build your core group. You’re going to need people, so start building
  • Avoid your hometown ghettos. I’m in a different place to meet new people, to learn from new cultures, not to build a Guetto of Spaniards abroad. Also, pro tip: I’ve found that people become their contry “cultural cliche” when they move abroad.
  • Walk the city. It’s the best way to discover its secret. It’s free, you won’t stay that much time at home and it becomes handy when visits come!
  • Ask for recommendations and try new food. Your hometown food is not going to be the same here, so avoid visitting those places. It’s time to experiment!
  • Don’t be afraid of digital platforms and tools, they’re handy to meet new people. They are groups, apps, meeting software..
  • Every company has a mad employee, so join that colleague. At the beginning, it’s going to help you learn what you like and what you don’t from the city, as you’re going to try a lot of weird activities accross several places!
  • It’s easier to socialise with other ex-pats than with locals who has all their life here. It’s a shame, because sometimes I feel that I’m not learning the culture of this place, but a thousand different ones because of the people who I spend most time with!
  • On a personal note, try to find a local significant other, that’s the best way to improve the language, get involved in their culture and discover even more secrets of that place!
  • Most capitals will have loads of meet ups, don’t be afraid to join them, particulary when they relate with one of your passions!
  • Share as much as possible with people you won’t find elsewhere, because it’s the best chance you have to learn from them!

Seriously, for me, this is by far one of the best perks a company can offer to you. I won’t work for a company just because it reallocates me to a new place, but when I find an amazing opportunity, having to move is a HUGE plus!

May the force be with you,

Gino