API TESTING WITH JAVA AND SPRING BOOT TEST – PART 1: THE BASIC SETUP

Here at Mercedes-benz.io (MB.io), we collaborate as multiple multi-disciplinary teams (nothing new to a Scrum-based organization).

I’m part of one of those teams, responsible for a Java-based microservice. Since this microservice sends data to a back-office application, we need to test the APIs provided by it.

With that said, we had the challenge to build a new API test framework from scratch.

In this series of articles we’ll show:

  • How we choose the tools
  • The process of creating and improving the test framework
  • Pipeline configuration
  • Test report

Choosing the language and framework

The main reason why we went for a Java-based framework is that the background of our team is Java and the microservice itself is written in this language. Our team is composed of Java developers, so they can contribute to building the right solution for our team and also maintain the code base of the test repository in case it’s needed.

The test framework we’ve chosen to be the base of our solution was Rest Assured.io. The reason behind it is that rest assured is already used in several projects within our tribe at MB.io and is also widely used and maintained in the community.

We also added Spring Boot to organize, structure, and be the foundation of the project.

Setting up the project

Step 1: Create the project

We choose Maven as our dependencies manager. Now, the first thing to do is to add the dependencies we need in our project.

Tip: You can use the spring boot initializer to get the basic pom.xml file with the spring initial setup.

After the initial setup, we need to add the dependencies for the rest-assured test framework and other things we’ll use to make our lives easier.

The pom.xml file should be something like that:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.7.3</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

    <groupId>api.test.java</groupId>
    <artifactId>apitest</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>api-test-java</name>
    <description>Api Tests</description>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-text</artifactId>
            <version>1.9</version>
        </dependency>

        <dependency>
            <groupId>io.rest-assured</groupId>
            <artifactId>rest-assured</artifactId>
            <version>5.1.1</version>
            <exclusions><!-- https://www.baeldung.com/maven-version-collision -->
                <exclusion>
                    <groupId>org.apache.groovy</groupId>
                    <artifactId>groovy</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.apache.groovy</groupId>
                    <artifactId>groovy-xml</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>io.rest-assured</groupId>
            <artifactId>json-schema-validator</artifactId>
            <version>5.1.1</version>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-log4j2</artifactId>
        </dependency>

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.18.24</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

</project>

Show code in Github Gist

With this, we should be able to start organizing our project.

Step 2: Changing the Main class

The Main class should be changed to a SpringBootApplication. And the main method must be configured to run as a SpringApplication.

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Main {

    public static void main(String[] args) {

        SpringApplication.run(Main.class, args);
    }
}

Show code in Github Gist

Step 3: Create a Service to manage your API

To abstract access and configure the requests in one single place, we can create a new Service and take advantage of it.

Here is the place to set the proper configuration of the requests.

Let’s create a new method here to abstract the use of a post request. In this post request, we’ll provide the URL and the JSON body as parameters, so the file will be something like this:

package org.example.services;

import com.fasterxml.jackson.databind.JsonNode;
import io.restassured.RestAssured;
import io.restassured.builder.RequestSpecBuilder;
import io.restassured.http.ContentType;
import io.restassured.response.Response;
import io.restassured.specification.RequestSpecification;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;

import javax.annotation.PostConstruct;

@Slf4j
@Service
public class YourApiService {

    private RequestSpecification spec;

    @PostConstruct
    protected void init() {

        // On init you can set some global properties of RestAssured
        RestAssured.useRelaxedHTTPSValidation();

        spec = new RequestSpecBuilder().setBaseUri("https://reqres.in").setBasePath("/api").build();
    }

    public Response postRequest(String endpoint, JsonNode requestBody) {

        return RestAssured.given(spec)
            .contentType(ContentType.JSON)
            .body(requestBody)
        .when()
            .post(endpoint);
    }
}

Show code in Github Gist

Note: We’ll return the full response to be able to validate what we want within the test itself.

As you can see in the file above, we also take advantage of the built-in RequestSpecification that Rest-assured has to set the baseURI and basePath for this service. This is a smart way to configure your service because if you have more than one service in our test framework, each of them can have its setup and host.

Step 4: Add a test case

First things first, let’s add the proper annotations to be a spring boot JUnit 5 test class.

@ExtendWith(SpringExtension.class)
@SpringBootTest
@TestInstance(TestInstance.Lifecycle.PER_CLASS)

After that, let’s add a constructor method and assign the Service to be used in our test as a class variable.

private final YourApiService yourApiService;

public ApiTest(YourApiService yourApiService) {

    this.yourApiService = yourApiService;
}

Now we are good to start adding the test cases here. Let’s do that.

The postRequest method expects two parameters:

  • the endpoint we want to send the data as a String;
  • the request body as a JsonNode.

The first thing we want to do is create an object to send in the request body of our request. We’ll take advantage of the jackson-databind library to help us with the object mapping.

@Test
public void testCreateUser() throws JsonProcessingException {

    ObjectMapper mapper = new ObjectMapper();

    String body = "{\"name\": \"Luiz Eduardo\", \"job\": \"Senior QA Engineer\"}";
    JsonNode requestBody = mapper.readTree(body);
}

Now, we need to make the request and validate what we want. Let’s add that to our test case. The final results should be something like that:

package api.test.java.tests;

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;
import io.restassured.response.Response;
import org.example.services.YourApiService;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInstance;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit.jupiter.SpringExtension;

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.equalTo;
import static org.hamcrest.Matchers.is;

@ExtendWith(SpringExtension.class)
@SpringBootTest
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
public class ApiTest {

    private final YourApiService yourApiService;

    public ApiTest(YourApiService yourApiService) {

        this.yourApiService = yourApiService;
    }

    @Test
    public void testCreateUser() throws JsonProcessingException {

        ObjectMapper mapper = new ObjectMapper();

        String body = "{\"name\": \"Luiz Eduardo\", \"job\": \"Senior QA Engineer\"}";
        JsonNode requestBody = mapper.readTree(body);

        Response res = yourApiService.postRequest("/users", requestBody);
        assertThat(res.statusCode(), is(equalTo(201)));
    }
}

Show code in Github Gist

Note: Bear in mind that this is just the first iteration, we’ll improve the code to keep the responsibilities within the respective classes.

What we’ve seen so far:

  • The project’s basic setup
  • How to structure the project
  • How to abstract the requests in the service layer
  • The first functional test case

This is the end of part 1 of this series of articles. The next part will cover:

  • A short refactor on the object mapping
  • Improve the response validation
  • Property files

See you soon!

Photo by Nubelson Fernandes on Unsplash

Andreas Rau – How pilots communicate

… and what we as Software Engineers/ Designers and Businessmen can learn from it

TLDR

In this article you will learn about miscommunication pitfalls in aviation and that the same pitfalls occur in software development, design, and business. We will dive deeper into topics like the aviation decision-making (ADM) process. Have a glance at intercultural communication. How it dictates the way we speak and understand our world. Further an introduction to my own personal experiences and how you can sabotage the productivity of your organization effectively.

In the end, we will apply the ADM to foster and improve your communication.

How miscommunication can trigger disasters

On 25th January 1995, the Avianca flight from Bogota, Colombia, to JFK Airport in New York, was running out of fuel. Air traffic control (ATC) at JFK kept the airplane in a holding position until their plane’s fuel tank was running dangerously low. When revisiting the conversation between the airplane and the ATC at no point in time the word “emergency” or “mayday” was communicated by the pilots. The captain reportedly told the first officer to “tell them we are in an emergency”. instead of letting ATC know that the airplane is in a serious situation, the word “emergency” was not communicated. Instead, the first officer told ATC “We’re running out of fuel” “With air traffic control unaware of the gravity of the problem, the plane crashed just nine minutes later. Out of the 158 people on board, 73 died, including the pilot and the co-pilot.”

The complexity of reality

The Austrian philosopher, Ludwig Wittgenstein already shared with the world in 1921 in his famous book “Tractatus logico-philosophicus”.

“Ordinary language is imperfect and cannot capture the full complexity of reality.”

From this, we can derive that even under calm conditions the human language fails. In the before shown example, it gets even worse under stressful conditions.

From Aviation to Software Development

First of all a disclaimer. I am a software developer and paragliding pilot. I am well aware that in airline aviation serious mistakes can endanger passenger lives and software development in most cases does not. What I am interested in, are the circumstances of mistakes and the diversity of people involved as well as their communication. When I was revealed how many aviation accidents happened because of miscommunication I started to question if the same situations occur in my day-to-day job and even in my private life. In both worlds, we face time-critical decisions. We both need to react to events that happen while we are executing tasks. I see only a few differences. One of them is that there are more decisions and events to consider in aviation. This means that there are more of them in a shorter amount of time. Both worlds make decisions. In software development, those decisions and their effects as well as their execution by 3rd parties take more time than in aviation. Think about this statement for a moment. Compare a 2h flight with all the decisions that you might need to take as a pilot to a software development sprint of two weeks.

I am a paragliding pilot, so nothing close to a real pilot, but in my experience, the amount of decisions I have to take in a 2h flight compared to a two-week sprint is about the same. In the next part, we will dive deeper into how the aviation industry takes decisions.

The aeronautical decision-making (ADM) process

The airline industry has identified a process that every aircraft pilot has to obey. Aeronautical decision-making (ADM) is a five-step process that a pilot needs to conduct when facing an unexpected or critical event. Adhering to this process helps the pilot to maximize his success chance.

  1. Start to identify your situation, this is the most important step. Accurately detecting it enables you to make correct decisions and raise the probability of success.
  2. Evaluate your options and in my experience, there are often more than I expected to be in the beginning.
  3. Choose from your generated options while accessing the risks and viability.
  4. Act according to your plan.
  5. Evaluate if your action was successful and prepare for further decisions. You will always have further decision points where you need to start the process of ADM again.

This process is only one of many more in aviation.

Let’s apply this to a software bug.

  1. Identify your situation
    • What is the real cause for the bug?
    • Is it reproducable, part of my product scope or not?
    • Did this bug occur because of our code changes or of dependency updates?
    • Is this bug on live systems?
    • Can I resolve the bug?
    • Do I need help?
    • Can I get more information?
  2. Evaluate your options
    • Patch the bug with a new version.
    • Ask for help.
    • Investigate further
    • Decline because it’s a feature and the user is using it incorrectly.
  3. Choose
    • Let’s assume the bug is on a live system and needs to be fixed asap -> Patch the bug with a new version.
  4. Act
    • Please enter your routine for fixing a bug here
  5. Evaluate if your action was successful
    • Is the live system running as expected and was the bug resolved?
    • Should we establish a standardized process to fix bugs?
    • Did I resolve the bug in time? If not practice time management.
    • Is there anything we can do to mature the product?
    • Feedback to QA.
    • Share your insights.
    • Improve test procedures.

This is an easy example to illustrate how the ADM process can be applied to software development. A lesson I learned from paragliding and software development is to always finish your plan even if the circumstances change during your action. Trust in your abilities and execute your plan. If you followed the previous steps correctly your actions cannot be severely wrong. Given that the information you based your analysis on was correct.

Which language we use is an important part of correctly communicating with each other, let’s have a look at aviation English next.

Aviation English

Pilots and crew, regardless of their own native language or any other languages they speak, travel across the world. They have to be able to communicate with every airport and every ATC they face, on a daily basis. This was a challenge to solve, which occurred with the rise of civil aviation in the mid-20th century. There was already an unspoken agreement in place. The language of the sky at that time was Aviation English. Now Aviation English is, as misleading as it sounds not the English language that we know. In fact, it is a separate language compared to what is spoken on the ground. Even native English speakers have quite a long road to learn it ahead of them. It uses standardized phraseology in radio communications to ensure aviation safety. Since the manufacturing, as well as the operation of air crafts, was dominated by English-speaking countries. The International Civil Aviation Organization (ICAO) slowly but steadily understood one thing.

Good processes and procedures themselves will not solve the issue.

In 1951 they suggested that English should be the de facto international language of civil aviation. Let me emphasize that ICAO in 1951 only suggested, that English should be the language of the sky. It took them 50 more years, in 2001, to actually determine English as the standardized language of air transport. With said standardization, they published a directive. It stated that all aviation personnel, including pilots, flight attendants, and aircraft controllers must pass an English proficiency test and meet the requirements. Before that, language skills were not checked in any standard way.

Now let that sink in for a moment.

Tech/Design/Business English

In Tech, Design and Business we do have our own set of languages. I am not talking about programming languages. Try to explain to your grandma/grandpa what exactly was decided in the last SAFE PI planning. You can substitute PI planning with almost every other meeting we have in our company. Now ask for honest feedback: “Can you summarize what I just told you?” Be prepared, it might be the case, that your elderly relatives are very kind to you and try to avoid the task you just gave them. But they will most likely not be able to summarize what you have explained to them. I already have issues trying to explain such things to my parents. I can already sense while speaking, that my parents won’t understand a word.

Although you and I were using English as a language. Our terminology, acronyms, processes, and neologism makes Tech/Design/Business English a very complex language.

¿Habla español?

I had the luck to work with many great people in my career so far and I am more than grateful for every one of them. Nevertheless, I discovered a couple of things for myself over the years. We are all working in the field of Information Technology, Design, and Business. We are all speaking the same language and share the same enthusiasm and skills. And still, we are different. We are all shaped and formed during our private and professional lives in ways one can only imagine. We all have a wide range of different religious, social, ethnic, and educational backgrounds. Living close to our families or far away from them. These differences became more and more visible to me with the amount of time I have spent with them. Differences in how colleagues perceive what you are trying to tell them. Differences in how people value their pursuits and sometimes sacrifice their benefits for the sake of the group. Differences in how authorities communicate with subordinates and vice versa. And these are only the people that I had the chance to work with. You have made your own experiences and shared time with so many more great souls.

What we are now tapping into is the field of intercultural communication. Gert (Gerard Hendrik) Hofstede (Dutchman, born on October 3, 1928, Haarlem, Netherlands) is a Dutch sociologist who proposed an indicators set that determines the various people’s cultural characteristics based on research conducted in the 1960-70s. The subject was part of my studies for one semester. At that time my brain did not understand the extent of the topic and how important it will be for my future life. Intercultural communication describes the discipline that studies communication across different cultures and social groups. In other words, how culture affects communication. There is an impressive amount of research done in the field of intercultural communication which investigates topics like:

  • Collectivist versus Individualistic
  • High Context versus Low Context
  • Power Distance
  • Feminity versus Masculinity
  • Uncertainty Avoidance
  • Long-term Orientation versus Short-term Orientation
  • Indulgence versus Restraint

All of them are worth investigating and I encourage you to do so. I have gathered further readings which should get you started.

Personal

On top of every culture, there is you, you how you perceive the world around you, and you, how you make sense of everything which is shaping you. Your personal touch might very well steer you into a counter course of what your culture tried to induce into you for the entirety of your childhood and more. I hereby am not suggesting that you are all rebels. I want to highlight that the personal level of communication can be far off from how the folks back in your hometown used to talk. If you haven’t already met a vast variety of people during your school time you will definitely do so in your professional life. In Software Development I have had the chance to work with many great people from all over the world. Although at some point already familiar with the concept of intercultural communication I often unknowingly said or did something I thought would be appropriate at this exact moment in time… it wasn’t. Having the basics of intercultural communication in mind is necessary but not sufficient. Get to know the person you are talking to and discover a new level of communication.

Interim

We have learned a couple of things about communication, let’s take a second look at the introductory example. The first officer, in disregard of what the pilot told him, made a severe mistake in not properly communicating the extent of the situation. Maybe, in her/his culture, it is common to understate issues and it can be rude to talk about severe issues or problems directly. Nevertheless, the situation required clear and fact-based information. Correct identification of the situation was therefore not possible. All further steps in the aeronautical decision-making process of the ATC were from then on based on false information and we all know the outcome. I often find myself in meetings where colleagues or superiors introduce me to a brand new process that will revolutionize how our company works, solve all the problems and issues at once and make us all happier. Thanks to good marketing everybody is excited and eager to implement the new processes with huge costs in time, money, and motivation only to find out that in the end, it didn’t work — again. I do not want to sound pessimistic, I want to tell you my perspective. Looking into software development and all the processes we have, I want to learn from aviation and invest more time and effort into educating our colleagues on how to properly and fruitfully communicate in a standardized and organized way.

Important factors for this, in my opinion, are honest, transparent, and truthful communication where hidden agendas or intercultural communication pitfalls are avoided. And to make one point clear, more communication is not equal to better communication. I think based on this foundation, processes can be fruitful.

Lost in translation

An enterprise company operating in multiple countries spread over multiple continents. What is the first thing that comes into your mind? For me, it is a rich and diverse project team over as many time zones as possible. During my early career, I was exposed to a trend in IT where teams could not be diverse enough. I know many companies which still steer 100% in this direction, but I also know many who are not. What I am trying to do here is to make you as a reader think. Think about your current circumstances, where are you working? Who are your colleagues? Do you work effectively together? Is communication easy for you or is it a burden? Do you have the feeling that meetings actually create useful artifacts or are they mostly a waste of time? Ask yourselves these questions and assess. I can only speak for myself and I have observed both. In my work, a rich and diverse team can accelerate me, but there have also been times when it slowed me down. When looking at the example I showed you earlier. Aviation English is a language that was an agreement on communication but it was not part of any training or checks. It is important to say, that this has nothing to do with the people per se. When I came to college, in Germany, I had the opportunity to choose if I wanted my studies and lectures in German or English. I was motivated and although my mother tongue is German, I wanted my studies to be in English. This was exciting to me and silly young me thought it would be good to already study in English since the language of IT was English. Now I really regret my decision. During all of my studies, I was confronted with a lot of bad English. Many interesting topics got lost in translation, simply because the lecturer was not proficient enough in her/his language skills. Please do not get me wrong here, my English at that time was not better either. I am just trying to make the point that the content of a message can be severely harmed when not communicated properly. During my career, I often did applicant interviews and had to clearly state my veto. The applicant might have had the best CV, and great experience, but bad English skills. In the IT industry, we have the great opportunity to have rich and diverse teams. This is a circumstance not exclusive to IT but it is still in my opinion a gift we should be thankful for. To make sure we respect and maintain said privilege I have a suggestion. I am suggesting that if we put so much emphasis on what technologies an applicant knows, for how many years she/he has worked with tech stack a, b or c. We should also check thoroughly if her/his English skills are proficient enough to communicate properly in a big and diverse company. We should offer and also expect and check from new hires to improve their language skills, if necessary. Language should never be a limiting factor. Coming from IT and especially web development, I have to deal with accessibility day in and day out. For me, it is easy to understand that digital tools and devices are about inclusion. In my opinion, it is the same with language.

Let’s take this a step further. A good colleague of mine introduced me to an amazing article on some second world war CIA practices.

How to effectively sabotage your organization’s productivity

The CIA created the “Simple Sabotage Field Manual” in 1944 on how everyday people could help the allies weaken their country by reducing production in factories, offices, and transportation lines. There is a wonderful article from the business insider which highlights that. Despite being written in 1944 these instructions are timeless. I am sharing with you the selected list of instructions from the business insider article, filtered for communication. See if any of those listed below remind you of our organization, your colleagues, or even yourself.

Organizations and Conferences

  • Insist on doing everything through “channels.” Never permit shortcuts to be taken in order to expedite decisions.
  • Make “speeches.” Talk as frequently as possible and at great length. Illustrate your “points” by long anecdotes and accounts of personal experiences.
  • When possible, refer all matters to committees, for “further study and consideration.” Attempt to make the committee as large as possible — never less than five.
  • Bring up irrelevant issues as frequently as possible.
  • Haggle over precise wordings of communications, minutes, and resolutions.
  • Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision.

Managers

  • Hold conferences when there is more critical work to be done.
  • Multiply the procedures and clearances involved in issuing instructions, paychecks, and so on. See that three people have to approve everything where one would do.

Employees

  • Work slowly.
  • Contrive as many interruptions to your work as you can.
  • Do your work poorly and blame it on bad tools, machinery, or equipment. Complain that these things are preventing you from doing your job right.
  • Never pass on your skill and experience to a new or less skillful worker.

I highly encourage you to read the full business insider article for some more bitter-sweet laughs.

Foster your communication

Although being funny to read, the sad truth is that some of these instructions are common practice in our organization. I advise you to take this list into your notes, bookmark the article, read through it frequently, and ask yourself: Do my communication behaviors fall into the same categories? If yes, no worries! Everybody has to start from somewhere. Remember the ADM process:

  • Identify your situation and ask yourself: Am I sabotaging my company? It’s important, to be honest here! (Remember: Accurately detecting it enables you to make correct decisions and raise the probability of success)
  • Evaluate your options, there are plenty! Seek feedback from people you trust and ask them for honest feedback on your ways of communication, do an Udemy course. Heck, maybe even join a debating club!
  • Choose from your generated options while accessing the risks and viability.
  • Act according to your plan.
  • Evaluate if your action was successful and prepare for further decisions.

This is not easy – but it can be done. You can do it!

Now to bring this article to an end let’s look at the last dimension of communication.

Are you talking to me?

I often find myself in situations where I talk about colleagues and superiors rather than talking with them. Talking about colleagues is easy, but with most things in life, the outcome of easy is not great. It takes courage to work on yourself and even more to reach out for help. There is no effortless solution, be honest and ask yourself if you really want to change something about how you communicate and how you are perceived while communicating. This article is at most only a catalyst that will hopefully ignite your own journey.

Recap

We have learned how two, at first sight, completely different professions share many fundamental communication skills. We have had a look at the aeronautical decision-making process, what intercultural communication is, that processes are only as good as the material we put into them to be processed, how to effectively sabotage your company and what you can do to foster and improve your communication.

We touched on many topics today and I hope this article touched you personally in at least one of them. If you now think about what you have read in the last couple of minutes I feel already successful in my educational mission and if you remember only one thing then something along the lines of this:

‘Don’t worry the worst mistake you can make, is to not communicate at all.’

Further readings

As promised here you have a small collection to further educate yourself about the topics in this article.

Full blown ADM

Aviation English

Understanding Intercultural Communication

Gert Hofstede – Intercultural Communication

Business insider – How to sabotage your organizations productivity

Workplace Communication


Photo by Avel Chuklanov on Unsplash

Meet Me Where I Am – Re:think Teamwork 

Mural Webinar with Priya Parker

I attended the Re:think Teamwork Webinar hosted by MURAL and the instant I listened in, Priya Parker captured my unconditional attention. How are we shaping our gatherings in a time of hybrid or fully remote working?

“Whether a group is gathering online or offline, group dynamics exist. Through thoughtful design and facilitation, you can shape them.”

Priya started by talking about the misconception that “Powerful gatherings are the shaping of things”. – which in this case is erroneous. We should look rather at the meaning of “Powerful gatherings come from shaping of people and interactions”.

Often the form or template we use to gather and interact does not serve the modern need of a gathering. When hosting and/or facilitating a meeting the work that is done beforehand contributes to meaningful collaboration. It’s said that 90% of the success of what happens in the room, happens before anyone enters it.

Ask yourself:

  • What is the need?
  • Why are we gathering?
  • Who do we might bringt together to serve the need?
  • How are the people feeling? How do I want those people to feel?
  • What do I need to do, in order to make the guests/attendees feel safe enough and brave enough to collaborate?

“Communication and Connections are not synonyms.”

Why is inviting people to engage so important for connection? We often have the assumption that the purpose of a gathering is obvious and shared. That is why you have to prime your guests. What does that mean? Priming your guests can be something small and simple, but that already encourages people to engage beforehand with the purpose of the gathering. Prepare an invitation, name your gathering, don’t call it just “meeting”. The guests already play a big part in starting a dialog by accepting or declining an invitation.

Something as simple as a reminder stating the agenda for the upcoming event or asking to share their current challenges or expectations before the actual gathering contributes to understanding how your guests identify. Are my guest’s introverts? Do they experience social anxiety? Are they open, extroverted, and so on? People want to be relevant and valuable guests and not feel like they are wasting their time by attending or having to feel uncomfortable and out of place.

Her book “The Art of Gathering” covers the following pillars:

  • Decide why you’re really gathering
  • Close doors
  • Don’t be a chill host
  • Create a temporary alternative world
  • Never start a funeral with logistics
  • Keep your best self out of my gathering
  • Cause good controversy
  • Accept that there is an end.

the importance of a proper closing

“When you open a world, you need time to also close that world”.

By closing your gathering you create a sense of safety and give your guests time to mentally and physically prepare for the event on their busy schedule.

Priya Parker is an outstanding storyteller and she had wonderful insights about how we can improve our collaboration to have meaningful and purpose-driven gatherings. Thank you for that Priya!

I highly recommend her gathering guide (it’s free!) and I am officially a fan!

I hope this quick summary of the conversation between Priya and Laïla von Alvensleben offered some food for thought. Feel free to ping me if you like to have more links or insights into the attended webinar.

Our top 5 topics in august by the tech practice circle

Summertime = vacation time. And we also need a well-deserved vacation. Nevertheless, some subjects were surfed and shared by our developers. This time, topics from the following areas are included: Open source, Rocket science, Tailwind, Chrome DevTools features, and Quality Assurance.


Javascript is rocket science after all! Working on complex systems, with endless lines of javascript and websites with millions of users a day, can be pretty exciting. If something goes wrong and a service is down for a while, that’s bad and not the user experience we want to provide for our users. Fortunately, though, we don’t do rocket science. So it was surprising for us to learn that the James Webb Space Telescope uses Javascript to control the telescope. Read the details in the article from the verge. It made me kind of proud that being a javascript developer can be rocket science.


Use Tailwind Without Tailwind In the article, Helmuth highlights the benefits of using tailwind, or what you can learn by taking a closer look. Tailwind is not part of our preferred tech stack, but it’s great to have the opportunity to look over the edge. As you can imagine, the reaction and attitude regarding Tailwind have been somewhat divergent. That’s the great thing about being able to disagree.


Chrome Devtools Recorder Recording user flows is a totally exciting feature. Not only can you record and replay flows to debug your application, but you can also export them and share them with others to track the exact error. This improves bug descriptions immensely. You can also export them with the respectively installed plugins in formats of common testing and performance tools. The individual recorded steps can of course be manipulated and additional ones added.


“uncurled” by Daniel Stenberg Daniel Sternberg writes about his experiences from over 30 years in the open source world. The inventor of Curl and open source enthusiast of course makes his work freely available and invites collaboration by using GitBook. Recommended reading for all who are interested in open source that wants to get an insight into his attitude, projects, what he thinks about funding, and how the open source world has changed over time.


5 Effective Steps to Align Testing with DevOps Our Quality Assurance team is already top notch and I read many things that are already implemented at Mercedes-Benz.io. Nevertheless, the article gives some interesting impulses on how to set up your QA team and your processes.


I would also like to draw your attention to the articles published on our blog by our esteemed colleagues.

Ricardo Brilhante has written an excellent text about AGILITY: IS FAILING AN OPTION? I don’t want to foreshadow how he answers this but we have “The Failure & Innovation Award” in our company for a reason.


We also have another part of the ARTICLE WRITING series, this time with a part about: FEEDBACK AND HOW WE INTEGRATED IT WITH A DEVELOPER </STYLE> Have a read and learn how to deal with feedback while writing and how we support that at Mercedes-Benz.io.


A heartfelt thank you to all who encourage discussion and distribute wisdom by sharing these stories. Hang loose and stay curious! Photo by Robert Bye on Unsplash.

JOIN OUR TRIBE OF DIGITAL ENTHUSIASTS

View job openings

Tons of topics in June from tech practice

It was a heated June and a lot of hot topics were discussed among our developers. We want to let you participate in a few of these subjects. Among them are interesting topics from all kinds of areas like AI-supported programming, the StackOverflow survey 2022, HTTP3, and lots of frontend-related subjects like the Vue 2.7 release, HTTP 103 status, abortController, CSS has() support and performance improvements. (Photo by Umberto on Unsplash).

GitHub Copilot uses OpenAI Codex to suggest code and entire functions in real-time, right in your editor. It has been on our radar for a while, and opinions vary somewhat. Especially now that the service has become paid. Have you taken a look at it yet? What are your experiences with it?

Colleagues from our sister company Mercedes Benz Tech Innovation gave an interview about Kubernetes. In it, they explain why Mercedes-Benz is working with 900 Kubernetes clusters. The German automaker runs a huge fleet of Kubernetes clusters to support a variety of project teams around the world.

The author of the article “7 Habits of a Successful Software Tester” guides us through his most important behaviors that one should have as a software tester. With this, we can be very reliable in MB.io and we consider especially the part of steadfastness as important.

Brace yourself HTTP/3 is coming. A few days ago the IETF finally published the official and final HTTP/3 specification. So be ready for our applications to be delivered even faster to the user. If you want to read up on HTTP/3 and get some benchmarking info, you can do so in this article.

In the article “AbortController is your friend” many useful variations of using an abort controller are shown. A quick summary of the whole article is also available in a 2 minute video at the beginning of the article. So get inspired quickly.

The world has changed a lot with Covid-19 and so has our life as developers. We are privileged at MB.io to be able and allowed to do our work from home. In his talk at JSConf, Antonio from Contino talks about stories that describe these changes and what he has learned from them. He shares some tips on how to apply them so that you can manage this new way of life just as well.

The Vue.js team has published that some Vue 3 features are now backported to Vue 2.7 so that also Vue 2 users can benefit from them. This is news that we at MB.io are very happy to hear because we work a lot with Vue and so migration can happen gradually and more easily.

A long-awaited fix for the CSS Level 4 selector has() is now available. With the new version of Chrome 105. Has() can be used to select elements that contain a specified content. This allows infinite useful use cases which otherwise would not be implementable purely with CSS.

An article on style scoping versus shadow DOM: which is faster? has piqued the interest of our developers. The article triggers a discussion about whether we should move away from attribute selectors in our Design System. See for yourself the detailed explanations and performance measurements under a wide range of scenarios.

Similar to the previous topic, the following topic is also about performance and you know, performance is key. With the new HTTP 103 status code 103 – early hints it looks like a way to speed up the preloading of additional sources. Setting resource hints on file requests and some adjustments to your server settings does the trick. Read here what else has been changed with chrome 103 and learn more about the early hints here.

Stackoverflow publishes the result of their annual survey and it is as always very exciting to read. You learn not only about the users of StackOverflow but also about their behavior, preferences, technologies, demographics, … and also payment.

I found especially exciting:

  • How do developers learn
  • Which sources do they use
  • Which programming languages do they know
  • Favorite IDE’s
  • Which tools, frameworks, etc are most loved and want to be learned
  • Salary ranks and changes in the industry to the year 2021 At the same time, I think this survey is a source of inspiration if you are interested in new tools and frameworks, etc, and want to try them. It’s also nice to see that many of the top topics can be found at MB.io. We are at the pulse of time.

Recommended reading for all.

I would also like to draw your attention to the articles published on our blog by our esteemed colleagues.

3 easy remote team building techniques Take a look at this crisp article from Jan Paulus that outlines why team spirit is so important and how you can boost it in your team.

The importance of being proud I was very touched by how in this article about pride month, two of our colleagues share their experiences as part of the community in our industry. I am happy that they have found a company in MB.io where everyone is treated equally.

A big thank you to those who keep stimulating discussion and spreading knowledge by sharing these topics: Claudio, Nuno, Goncalo, Porfirio, Nuno, Nils, Ruben, and Goncalo.

My top 3 Mac OS menu bar apps

MacOS gives us many different tools to keep us productive. You may end up using your Mac very differently from others. In this article, I will share a few apps and ways that help me make the most of it. This is going to be an article series and I will start by sharing what is in my menu bar.

macOS Menu bar

The menu bar sits at the top of the screen and it has two main sections, left and right. The left side shows your current application menus, and it can’t be customized. However, all the remaining space on the right can be customized and used to install additional applications. Keep in mind that the left side has higher priority and if needed, it will cover the right side. What you can see on the right side will depend on screen width and how many menus the current application has.

These are the apps I have installed in the menu bar

1. Stats

Stats – macOS system monitor in your menu bar

I love Stats due to its aesthetics and level of customization. It helps me keep an eye on CPU, Network, and Battery levels. You can configure more metrics in case you need them. I use the Battery metric from Stats as it shows only the percentage vs the built-in battery indicator which shows icon plus percentage and therefore takes double the space. You can use this guide to hide the MacOS default battery indicator.

2. Itsycal

Itsycal is a tiny menu bar calendar. If you want, it will display your events as a companion to the Mac Calendar app.

Sometimes, every second counts, therefore I enable the seconds’ display on the Digital Clock menu bar. However, the built-in date display takes too much space. This is where Itsycal comes in. You can configure it to show Day, Date, or Month and choose a dark/light theme in case you want your Date to stand out. On top of this, once clicked, it shows a calendar month view, which comes in handy when I need to quickly check the dates without opening a calendar app.

3. HORO

Horo is the timer app you need for your menu bar. It’s easy to use, fast and gives you exactly what you need.

This one I love because of its simplicity. I can quickly set a timer or start a stopwatch. Once the timer runs out, there is an audible alert to remind you it’s over. This comes in pretty handy when I’m coding and cooking, a dangerous combo by the way 🙂

Missing piece =)

I wish I could share another app that perfectly fits into the menu bar, and that would be a weather app. There are some great options, but they are not free. This is why I started my own project to make a simple and free Weather app for your menu bar. But, more on that in the upcoming posts.

extra tips

In case you want to reorder those menu bar apps, hold down the CMD key and drag the app with your mouse into the desired place. In case you keep those default apps, make sure to check out System preferences -> Dock & Menu Bar and customize the options to your liking. For example, I removed Spotlight and Siri as I don’t use them from the menu bar. No need to have that clutter over there. If you want to see what other cool menu bar applications exist, check out this curated directory of MacOS menu bar apps. In case you are a Javascript developer, you might want to apply your skills to create your own menu bar app using xbar.

SUMMARY

In this article I shared how I customize my menu bar. In the following articles, I will share further customizations and apps I have in my setup. Things like window manager, Spotlight replacement (not Alfred btw), productivity apps, browser extensions, etc.. So if you find this content interesting, make sure to follow our blog and share it with your friends.

The importance of being proud

Every year, June comes around and the rainbow is everywhere. Logos, t-shirts, posters, social media, TV, clothes stores, you name it. There are many variations of the Rainbow Flag, with the most popular being the six-color version designed by Gilbert Baker in the 70s and a plethora of others representing different sexual and gender identities. For someone outside of the LGBTQIA+ community (and even for some within it), it can be a bit overwhelming. For many, Pride month is just a celebration, with pretty parades and maybe some protests, lots of colors and happy people, rainbows everywhere, political speeches, LinkedIn posts, and some logo changes. But for those that are part of the community, it’s more than that. It’s a celebration of who we are. It’s an affirmation that we are proud of who we are. And it’s a way to show the world why that is important. That’s why our Data Anlayts’ Pedro and Inês took the opportunity to give us an idea of their experiences in their professional life so far.

Pride in the Workplace – Pedro

My first internship was at a multinational telecommunications company here in Lisbon (too little did I know about how important this internship would be later, but we’ll get to that). This is a company that, like many others, does a lot of things during Pride month, like handing out rainbow-colored merch, social media posts, etc.

I never felt that the company culture there was discriminatory or close-minded; however, I worked closely with a colleague who would often explain to me why he thought gay marriage shouldn’t be allowed, why transgender people shouldn’t be allowed to transition, or why he didn’t think children should learn about the LGBTQIA+ community. Mind you, he didn’t know I was gay, we would just be talking about something and these topics would come up. He also told me he thought a guy who worked on the same floor as we had only gotten far in his career because he was gay, and the company wanted to “use him” as a token of progressiveness.

My internship ended and I left the company. I never told anyone I was gay.

My second internship was at an established, large Portuguese company. This company doesn’t tout its progressive culture to the seven winds, so I wasn’t expecting much. When I got there, almost every day some of my colleagues would make jokes about women, comment on women’s bodies, joke about gay people, etc. They would also often tell me that the new generations didn’t know how to take jokes and that if some gay guy entered the team, they would probably get in trouble. As a young worker desperate to start my career, I stayed silent and never said anything.

My internship ended and I left the company. I never told anyone I was gay.

My first real job was at a consulting firm. Again, this company changes its logo for Pride month, and… that’s it. On my very first day there, one of my new colleagues made a transphobic joke.

After 6 months, I quit the company. I never told anyone I was gay.

Photo by Pedro Pacheco

Finally, I came to MB.io. To be honest, I didn’t know much about MB.io’s stance on Pride and the LGBTQIA+ community, but from my previous experiences, I knew I should probably stay quiet and silently nod if someone started talking about romantic partners, give an awkward laugh if someone made a homophobic joke and, all in all, just stay quietly on my corner and do my job.

However, one of the first people I met here was Inês. She had worked at the same telecom company I had been an intern at. There, she befriended one of my closest friends and eventually referred her to MB.io, and then my friend referred me. See, I told you the internship would be important.

Inês was not only incredibly nice and welcoming, but she was also openly lesbian. I still remember feeling my heart skip a beat when she casually mentioned having a girlfriend. It was a true “ah!” moment that made me realize it was okay for me to be openly gay at my job. I could finally participate in conversations about romantic partners without having to hide the fact that I have a boyfriend. I could finally befriend people at my workplace without the fear of hearing a homophobic or transphobic joke. I could finally talk to my colleagues without having to debate my right to marry the person I love.

The difference was astounding. I remember getting nervous afterward about casually mentioning I had a boyfriend, wondering if the others wouldn’t be as welcoming as Inês. But every time I said it to someone else, no one made any comments on it. They just kept talking to me without a problem. It was like a weight had been taken off my shoulders, and I could finally breathe again.

Pride in the Workplace – inês

As Pedro, my first work experience was not the most welcoming one. I worked for a consulting company where I casually heard homophobic and racist jokes every day. Where the thought of being out of the closet at work was never ever something I considered. If you are not part of the community, it might be hard for you to understand how hurtful it can be to hear people talking about their weekend plans with their romantic partners, or about dates, whatever, and just quietly keep your mouth shut and hope no one asks you directly.

I left that company after 9 months and no one there knew I was gay.

My second job was at the telecommunications company where Pedro also did his internship. The difference from my previous job was huge. This was a company that actually commemorated Pride every year, and I never heard any specifically homophobic comment. It was a fairly open and progressive culture. However, I didn’t know anyone there that was openly LGBTQIA+. I’m sure there were plenty, in such a large company, statistically, there had to be. But not in my work circle.

I made some close friends there, so in the final months of working there I did come out to those friends and was not actively hiding my sexuality from anyone at work, but I wasn’t fully comfortable, since I was still, to my knowledge, “the only gay in the village”.

Photo by Inês Correia

Fast forward to MB.io – during the recruitment process I met many people that gave me the impression of an open, innovative and progressive company culture, and I had decided that in my next job I would be fully out, as a matter of principle and honestly because I felt comfortable enough in my career to know that if I encountered homophobia or an environment that didn’t align with my principles I could just leave and find a job elsewhere.

MB.io has a rite of passage for new joiners. In your first week, you need to select three objects that represent yourself and present them to the entire company, so that everyone can learn a bit more about the person, beyond a name and work title. I felt this was a great initiative, and it also made my life much easier, because I simply mentioned my girlfriend during my presentation and immediately came out to 150+ people. I didn’t know at the time if MB.io was truly an accepting and open workplace, but since then I can say that I’ve met more openly LGBTQIA+ here, than in almost any other place in my life. For me, this really shows the positive environment that exists in MB.io, where all these people feel comfortable enough to be themselves openly, and so that when a new joiner, like Pedro, was at the time, joins the company, they can see themselves represented in their colleagues, and be emboldened to be their true selves openly at work.

pride at Mb.io

These are the true markers of open and welcoming company culture. Not rainbow logos, vapid LinkedIn posts, empty statements. It’s the people that make the culture, not these facades. And, most importantly, it’s the people who aren’t afraid to be who they are, who are willing to step up and set an example, and who are brave enough to forge the path for others. Without Inês, I probably would have never “come out” at work. It’s because of her and so many others who were brave enough to show their colors that we are now writing this article.

This is why Pride is important. Why representation is important. We all look to those in our social groups to understand how we should behave within that group. When we were at those companies, even though we kept our heads down there, we were out and proud of our friends because they gave us social cues that told us it was okay for us to be who we are around them.

So, if you are not a part of the community and struggle to understand why June is so colorful, we hope you understand a bit better now. At MB.io, we organized meetups in each of our office locations for people to get together and attend the Pride parades. We also prepared internal pages with songs, books, movies, TV shows, and short videos with LGBTQIA+ themes, as well as external resources for those looking to donate to organizations or just get information about the topic. We are also preparing internal trainings to better educate people and a joint donation between employees and organizations.

Thankfully, we are now at a place where we can write this article and have it published for all to see. A few years ago, we would’ve never even dreamt about it, and all it took was one person and a company culture that is truly open and welcome to all. So, if you are reading this and you’re wondering how you can truly celebrate Pride in your company, know that, beyond whatever initiative you might be planning, it’s the people who make a difference.

More articles about Diversity Diaries will be released soon. Keep an eye out to find out more!

3 easy remote team building techniques

In this article, our frontend engineer Jan Philipp Paulus introduces 3 simple methods to help your team build up or strengthen their bond. You can pick up the techniques without further requirements. (Photo by Sigmund on Unsplash).

Why a good team spirit is important

🤩 Motivation: colleagues will be more motivated when there is an overall better spirit in the team.

🤝 Trust: colleagues will start to gain and foster trust in each other  

💬 Communication: with more trust, colleagues will start communicating and interacting more with each other.

💡 Knowledge: the more communication occurs, the more knowledge will be shared within your team.

📈 Performance: in the end, everything mentioned above can potentially lead to overall better team performance.

Disclaimer

Remote team building is not a replacement for in person team building and will most likely not be as effective as it is face-to-face.

Pro tip 💪 Try to incorporate a mix of in-person and remote team building techniques into your team building strategy.

the techniques

👩🏻‍💻 Create an off-topic channel

Create a channel for your team in which everyone can post random memes, images (especially of dogs or cats), recipes, and music. This channel can be an alternative to the chats that would usually happen at the coffee machine. You can even start small competitions in which everyone posts a picture of their desk and then votes for the cleanest and messiest. These are some ideas, but the options are endless. Be creative!

👾 Host virtual game nights

You might be skeptical if you’ve never attended a virtual game night, but they are a fun way of getting to know your colleagues. Depending on the game, you will be able to see the strengths and weaknesses of your colleagues. Understanding these will help you to get a better picture of the person you’re working with.

Pro tip 💪 To get everyone into the right mood, try to kick off the evening with an ice breaker. tscheck.in is a good starting point if you are looking for ice breakers.

Among the many options, here are some games I can recommend:

  • Among Us
  • Remote Work Bingo
  • Draw Something
  • Never Have I Ever (SFW)
  • skribbl.io

☕️ Have virtual lunch or coffee dates

A wonderful way of getting to know your colleagues is to set up virtual lunch or coffee dates. Plus they usually don’t take much time to plan and execute. You could even install apps on Teams or Slack that will randomly pair up team members every week.

Pro tip 💪 Try to avoid starting the conversation with work-related topics. Instead, try to find out what the other person likes to do in their spare time. Finding common ground makes it easier to get a conversation started.

wrapping up

We hope these three techniques gave you a rough overview on how to start remote team building.
Give them a try and feel free to experiment with more promising methods.

TRENDING TOPICS IN MAY FROM TECH PRACTICE

Our developers have been discussing interesting topics again and we have picked out a few topics for you. Among them, are articles that we recommend to each other about new trends in web development in the world. The Frontend Circle was once again particularly active. (Photo by Sharon Pittaway on Unsplash).

Cypress 10 is out! 

Cypress app was completely redesigned to better integrate with the overall development. Including some new features such as:

  • View the latest Git status in the spec list
  • Ability to change browsers from within the Cypress app
  • and what can not be missing: Automatic migration from previous Cypress versions

In addition, component testing in this version is a great innovation. It is made available to the general public for the first time and the team has many plans for it.

Thinking tools and frameworks

Untools is a collection of thinking tools and frameworks to help you solve problems, make decisions, and understand systems. Such as the Minto Pyramid, Eisenhower Matrix, or Issue trees.

The definition of each tool and framework is provided. Step by step it is explained how to use them and practical examples are given. In addition, there are further sources to go even deeper. Very inspiring for all who want to deal with problems in a structured way.

Mercedes-Benz is now a bronze sponsor of Vue

contribution to this great FOSS project we all use every day. At Mercedes-Benz.io we’ve adopted Vue.js as the company’s main frontend framework. It is being used in tons of products from us. Mercedes Benz AG sponsors many open source projects and this sponsorship was fortunately initiated by our colleague Claudio.

SAP Commerce 2205 release

Of strong interest to our SAP Commerce Engineers are the updates to the SAP Commerce 2205 release. Which introduces the following new features and enhancements:

  • Intelligent Selling Services for SAP Commerce Cloud
  • UI Themes, Branding, and Profiles
  • Headless Commerce and B2B PunchOut

Articles by MB.ioneers

You don’t need a JS Library for your components

Helmut has posted his first article on Medium. This one is about developing native Web Components. Take 10 minutes and you will learn how to create and integrate a web component including links to examples. You will also be able to read about experiences, caveats, and solutions to the most common problems in native web component development.


Physical well-being & how important it is

In this personal story, our Program Lead Christian Diener gives us interesting food for thought on how to focus on ourselves and the time in which we are physically active. And by the way, Christian is a real running machine.

STAY CURIOUS

Thanks to all of you who share your knowledge within our company and expand our horizons.

How our Software engineers exchange ideas and have fun

The Covid-19 pandemic has changed a lot in our lives. When it comes to working at Mercedes-Benz.io we have adopted a flexible collaboration model. This brings more freedom, better work-life balance, and so much more. With remote, it has been more difficult to know our fellow MB.ioneers on a deeper level. It made me miss the face-to-face interaction and collaboration. I think nothing beats getting everyone together.

So, in the backend circle, self-organized as we are, we just went for it and organized an offsite with the goals to exchange knowledge and experience, getting to know one another, and connecting.

And what better place to do this than Nazaré, the capital of the biggest waves in the world (well, don´t get spooked by it, there are also calm waves to enjoy a beach day), a place where Garrett McNamara in 2011 set, at the time, a world record on the biggest wave surfed and, home of the Mercedes-EQ Lounge.

WHY THE MERCEDES-EQ LOUNGE?

As you might have heard Mercedes-Benz is committed to a sustainable future and the Lounge is a perfect example of that. The Mercedes-EQ Lounge is a 100% sustainable place, designed using recycled and reused materials. It includes an electric circuit that comes from the reuse of four battery modules from one of the first units of the 100% electric Mercedes-Benz B-Class. The modules now store the energy captured by photovoltaic panels and power the whole building. The Lounge additionally has four charging stations for electric cars and offers the perfect environment for us to debate about our future, drive conversations and share our experiences.

So, to us, it is a match made in heaven.

THE EVENT

We gathered in our Lisbon office and set course to Nazaré. Lucky us, we were able to get our hands on two Mercedes-Benz EQVs for our travel. During the morning at the hotel, we had our “Product Roulette” in which everyone presented not only themselves but also their product teams:

  • Who was part of the team and stakeholder.
  • What is the product and its purpose.
  • How does the product work (tech stack and the business concerns it focuses on).

Did I mention the activities? Does a high-speed voyage, drifting in the water, and doing water-force defying maneuvers sound exciting? How about the opportunity to go by boat to the Nazaré Canyon and hear how those giant waves are formed?

We had the opportunity to do it all. This would not be an offsite without some cool activities. All powered by Mercedes-EQ Lounge together with Nazaré Water Fun. It was an afternoon packed with water, sand, fun, and adventure. After dinner, we enjoyed a walk by the beach for a fruitful chance to not focus on work but get to know our colleagues.

THE FOLLOWING DAY, WE SURFED THE KNOWLEDGE SHARING WAVE.

We went to the Lounge for our well-known Exchange.io format where everyone can casually share knowledge or just open a discussion on certain topics. It could be a training to introduce a new framework, technique, or any other topic which is interesting for us. We do this regularly at the Backend circle and the Architecture and Technology circle. For this session we had a wide array of topics:

  • Internal marketplace to share ideas and find collaborators for projects, that can be suitable in an Inner Sourcing approach.
  • Custom alerting system that warns tenants when having misconfigured settings. Helping them reduce a lot of errors.
  • – Reactive Programming with Spring WebFlux and Kotlin Coroutines;
  • HTTP library for Common Backends aimed at addressing repetitive concerns across all our products and re-use code.
  • Brainstorm on cross-cutting topics and issues in our current software landscape followed by how we want to address them

With our Backend Offsite we were able to do a lot.

Firstly, the opportunity to take a unique test drive, in a spacious, comfortable, quiet and with excellent autonomy Mercedes EQV. Secondly, to visit the amazing town of Nazaré. Thirdly, to get to know the Mercedes-EQ Lounge and feel its purpose. In the same way Mercedes-EQ was designed with reusable materials, we took our learning of our common technical issues to re-utilize solution across our teams. Finally, all of us got to know one another better.
We look forward to having another event like this and, who knows, next time it could be you going with us…