5 Tips for a Workshop to improve Collaboration between Front- and Backend Developers

In agile cross-functional teams, front- and backend engineers are working together on a project. Each person has a T-shaped skill set. This means that in addition to their core competencies, each team member also has a rough understanding of other areas of work. The idea behind this is that everyone can work on their own tasks as well as support other team members in their work.

Of course, this requires many agreements, especially regarding the interface between the two functional teams. Information is formatted as JSON inside the backend and must be accepted and processed in the frontend. Frequently, the question “Is it safe making changes to our backend or could it break the frontend?” pops up. In the course of the conversation, the question occurred: “What do you actually do with all the JSONs in the frontend?”

Here, some uncertainties seem to exist about the respective work. Admittedly, as a frontend engineer, I don’t know how JSONs are created inside the backend. Is it important for me as a frontend engineer to know how this works exactly? And, in return, how much understanding should a backend engineer have about frontend processes?

These questions led to a common idea: A workshop about ReactJS designed for backend engineers. In the following I’ll put together five tips and learnings on how to prepare for this workshop, which will help you to improve your cooperation in the long run.

Tip 1: Collect ideas for a better understanding of each other’s work.

What is the best format to remove uncertainties about the work of other team members? What do backend engineers might want to know? Do they need a basic understanding of frontend work in general or is it enough to cover one or two specific topics?

You can’t answer these questions by yourself. Talk to your other team members, only then will you find out exactly what your team needs. Once you’ve got a feel for this, you’ll have to select tools for the workshop. Will it be a pure lecture with the aim of imparting knowledge, or will it be a concrete task for your participants, according to the motto “Learning-by-Doing”?

Tip 2: Get to know your target group

The first step is to find out who is interested in participating in the workshop. For how many people are you preparing the workshop? What level of knowledge do the participants have about the topic, i.e. how much experience do they already have with frontend topics?

It is beneficial for the workshop itself to discuss expectations in advance. This can give the whole thing a different direction and helps to keep the goal of a better cooperation in mind.

Tip 3: Remember the times when you were a newbie

Remember the time you started learning something new. What helped you? Or to put it another way: What wasn’t helpful at all? What would have helped you to understand the subject more easily and what do you wish you had known when you started?

My experience so far has been that it is often not very helpful to mention the technical terms right at the beginning. These are neither helpful nor beneficial for the actual understanding. Instead, explain a fact, if possible, in simple and above all in your own words. If you have the feeling that your audience has understood the fact, you can use the technical terms and summarise what has already been explained including the terms.

In conversation with the backend engineers, the following question occurred: Where do they start looking if they ever get into the situation of having to open a frontend project and, for example, look for the reason why a button doesn’t respond to a click? With this scenario as a starting point, I thought about what you would need to know to tackle the problem. I therefore decided that it would not make sense to explain the setup for a frontend project from the beginning. I don’t have to explain what Webpack is or what advantages and disadvantages yarn has over npm. It is more important to know how the project is roughly structured, what a component looks like and how the developer tools in the browser can help.

So, my tip is: Think about what might be too abstract for your audience and what kind of knowledge might be useful for the problem. Work out methods to simplify complex topics. Comparisons are best for understanding. For example, explain a situation to a person from the backend in advance and ask if there is anything comparable in the backend. This may make it much easier for one or the other.

In addition, I decided to integrate a practical task into the workshop. Therefore, it is worthwhile to browse through tutorials for beginners. How are the relevant topics explained for beginners? You don’t have to come up with your own tasks if others have already thought about this question.

Tip 4: Find the right tools

Sooner or later the question will arise how you can best present the information you want to share. I decided to use a classic presentation tool at first, but since I also want to show a lot of code, I decided that MDX Decks would be good for it. I was recommended the tool by a colleague and had a lot of fun learning how to use it. It is amazingly easy to set up and use. I particularly like the fact that I can design my presentation with mdx-deck using my own components written in JavaScript and React and show code examples with syntax highlights.

Tip 5: Start not only one, but several test runs

In preparation for my workshop I talked to many people about it. That by itself helped enormously. I asked my backend engineer colleagues what they expect from the workshop and what they want to know. Afterwards, I also asked the frontend engineers the following questions:

• What do you think is relevant?
• Which topics are absolutely necessary and what can I leave out?
• What sources do they have to educate yourself, like good blog or Twitter posts, with tips and tricks around the topic?

That’s how I for example found the content of Samantha Ming on Twitter with short and figurative explanations about JavaScript-related topics.

After all this preparation, it’s still important to first test the content of the workshop. Let other frontend engineers take a look at it to eliminate possible mistakes.

Then it is time to practice the content of the workshop in front of a backend engineer in a one-on-one conversation. In my experience, mostly everyone was open to listen to my presentation and their feedback was really helpful. I also noticed a great interest in the topic, which in turn gave me pleasure and motivation for my task. I have been able to work on my explanations and presentation slides and have always listened to all the questions of my conversation partners. This helped me a lot. The questions made clear which topics needed more explanations and which were already covered.

The questions also provided new ideas which I by myself would not have come up with at all. As an example: Someone asked me about inheritance techniques in React. I thought it would certainly work, but would you want that? Is there a use case for it? So, after the conversation I had to read for myself how it behaved. I also found an explanation in the official ReactJS documentary:

„At Facebook, we use React in thousands of components, and we haven’t found any use cases where we would recommend creating component inheritance hierarchies.“

Conclusion

I can say that the exchange with other people was probably the most rewarding experience during my preparation for the workshop. The questions that were asked, especially by the backend engineers, also gave me new impulses. They taught me to keep an eye out for explanations and to question why we do certain things in the frontend. I also came across interesting and worthwhile facts which I included in the workshop. This workshop definitely improved our teamwork in the long term.