3 personal development “mobile” apps you need but can’t buy

April 2022 is official Well-Being Month here at Mercedes-Benz.io. With that, we hope to inspire our MB.ioneers to focus on themselves and their mental and physical well-being by preparing some initiatives around this subject. In this article, our People & Culture expert Paulo has been thinking about how often we stop to reflect on how we deal internally with our experiences. As well as how regularly we observe the sensations and emotions that are circulating within us and how often we consider the ways we interact with the people around us.

What if you had a mobile app that could sort this all out for you? Here’s what those three “mobile apps” would look like if you could search them in your app store

1. Emotion in action

It enables us to invest focus and energy on results and it offers us the choice to opt out of the mental paralysis which is the result of destructive self-judgement. To observe, without judging, our own minefield. With this tool, we can build a plan for life in which we act proactively, and align with our own goals. We can even share with family and close friends; put our emotions in motion.

2. Self-Discipline 3.0

Ideal for procrastinators, this app is the final call in the evaluation of our day-to-day habits. It assesses the respective qualities of our activity and using a database of the finest teachings from the world’s most famous thinkers and philosophers provides us with tips on how to achieve our goals. Its main feature is something special: when so much as the thought of a destructive habit is detected, it places the user into a “reflection bubble.” The reflection bubble insulates us from all external stimuli and immediately triggers an email, listing the consequences of carrying out the habit in question. The only drawback of this app is that it quickly drains the battery, especially in cases such as those where multiple destructive habits can cause the reflection bubble to remain permanently active.

3. Self-Reflection

In addition to helping us to reflect on the image we have of ourselves in our minds, this application identifies beliefs and behavior patterns that are boycotting the release of potential. On selecting a variety of dramas from your past, Self-Reflection immediately provides three different perspectives of each situation that we can learn from, so we can choose to move forward in our lives.

The cherry on top is this app’s Airplane Mode function. Any time we begin to feel distressed we can simply click this button. Routine observation and investigation are activated immediately by any mental anguish or physical pain. At the end of this process, the following message is displayed: “Do you accept and truly embrace the suffering within you?”

If the answer is yes, the process is finalized. Should the answer be no, we have the option to continue in Airplane Mode as necessary. This application can be used simultaneously with Self-Discipline 3.0.

Conclusion

It does not benefit us to subdue the hustle and bustle of day-to-day life. We need to listen to the messages we receive from our bodies when we decide to stop and reflect. To sit back and share what we’re feeling. The emotions and feelings that we experience can and should be shared with a safe inner circle of family and friends; or even with strangers, depending on the situation.
We all have the courage within us to allow vulnerability, to observe the impact it has on the reality surrounding us, and above all, the impact our feelings have on ourselves, and in our lives.



Tech Practice Top 5 news in March

Some exciting topics were shared by our developers in our MS Teams chats this month. Among them are topics like alternative interviews, the fragility of open source, CSS functions, learning by playing, ES2022, and an interesting automation tool.

What’s new in es2022?

There are a few new features for ECMA script in 2022 and this article provides explanations and examples of the following changes:

  • Class Fields
  • RegExp Match Indices
  • Top-level await
  • Ergonomic brand checks for Private Fields
  • Accessible Object.prototype.hasOwnProperty
  • Class Static Block
  • Error Cause

Soon the new ECMA script version will be released. So make sure you know what’s going on. On GitHub you can keep an eye on the latest proposals for ES.Next.

CSS functions

In this short and crisp article some CSS functions are explained exemplarily. If you want to keep your application lean and avoid javascript where possible, you should consider these. Attr(), calc(), max(), min() are covered.

A more detailed description can be found on CSS tricks.

CSS skill game

https://flukeout.github.io/#Playfully and visually you get in this small application all CSS selectors explained. Even those that you might not use so often and you can be inspired for meaningful use. The whole thing is played through in a few minutes and is totally fun. Now I’m hungry for apples and cucumbers.

Keptn

In this short video Tutorial you get an insight into a new tool called KEPTN to Automate your Multi-Stage Continuous Delivery and Operations. Exciting if you want to have a look at new tools and their capabilities to compare them against your current tools and their features. In this case with included Lighthouse test and Quality Gates. Furthermore, it is open source and easy to try out.

Be careful with open source usage

In March, there was another example of the vulnerability of open-source software. Its impact on the whole VUE community was huge. In the article you can read the history and the effects of the node-ipc case. Such effects of security incidents in the open-source dependencies further confirm the need to properly manage and quickly respond to the risks of open source dependencies.

BONUS

Explain the First 10 Lines We conduct technical interviews when you apply to be a developer with us and we are always interested in improving the experience. An exciting introduction to a technical Interview in the application process is described in this article. To get some basics and their understanding. This introduction allows for more exchange and a basis for a further interview. Maybe you will experience something similar in the future when you apply for a job at Mercedes-Benz.io.  

Articles by MB.ioneers

The Psychology of remote work and 16 tips to make it work

Hidayat has once again contributed to our blog and in “The Psychology of remote work and 16 tips to make it work” he sheds light on the impact of working from home on our psyche and how we can behave to improve collaborative work.

Article Writing: How you learn more from yourself than from reading a book

I was also able to write another in which I will give you some motivational benefits that you can experience when you dedicate yourself to writing articles and in which phases of writing you can benefit from them.

Thanks to all of you who share your knowledge within our company and expand our horizons. Ruben, Alexandre, Jorge, Claudio, Andy, and Christian you are great. Stay Curious!

The psychology of remote work and 16 tips to make it work

This article was originally published at https://heydaroff.info.

Remote working will more likely stay in long term. If not hundred percent, it will definitely push many companies to adopt a hybrid model. With the COVID hit, tens of millions of people had to move their workplaces to their living places, to their homes. In multiple studies (mostly by management consulting companies) it is estimated that more than 20 to 25 percent of the workforce could work three to five days a week remotely. Obviously,  remote work at the moment is only possible the people whose work does not require physical output. There are many dimensions impacted by the workforce going remote, such as counter-urbanization, “to-go” delivery vs. restaurants, commercial real estate, and so on. These are all business-side changes, however, there is as well a direct impact of remote working on human psychology.

photo by Sigmund

Onsite vs. remote

Obviously working onsite has quite a few benefits. When working in an office, social interaction is inevitable. We meet a lot of colleagues, we talk to them, we go to lunch or we do coffee breaks with them. If we have ad-hoc and urgent questions, you can simply go to your colleague’s desk and ask, namely, the information flow is fast. Moreover, the office is a dedicated place for working, which means that our work-life split is pretty explicit, when leaving office work ends, when coming to office work starts. Another benefit of the office is its infrastructure setup. Usually the office desks, chairs are quite comfortable, there are rooms for social hangout, kitchen with always filled fridge, sometimes you can even find beer tap in the office (the reason I love our Berlin office).

On the other hand, remote working is as well quite attractive. When working from home, we don’t have to wake up 3 hours in advance to get ready and go to the office. I cannot believe how much time we’re losing for commuting and how remote working saves that time for other activities. Another side-advantage of not commuting is that you can choose when to start working since there is no location/logistics dependence of starting to work. The location independence also means that you can travel anywhere, anytime you want, and continue working from there. I do not like Berlin weather in winter, thus I prefer to move to Algarve, Portugal, and work from there for the next few months. This type of independence is extraordinarily beautiful. Another benefit of the home office (HO) is the cost-saving on both employees as well as on the employer side. If I can work from home, then I do not need to pay a ridiculous amount of money for rent just because I live in Berlin city. Instead, I can find an apartment a little bit outside the city or maybe even move back to beautiful Freiburg city and pay half the amount for rent. On the other side, there is no need for companies to offer a 24 hours alive office space anymore that costs a lot not just monetarily but also environmentally.

However, the biggest benefit is our flexibility in shaping our work-life balance, if done correctly. Otherwise, the psychological debt of remote working can be a deal-breaker. Let’s have a look at it from a neuroscience perspective.

how does remote affect our psychology?

Some neuroscience studies suggest that our brain, besides being a central command center, is as well of a logistic center. The largest nerve in our body, the Vagus nerve carries information from our guts, through our hearts, our face, our ear canal to our brain. This nerve brings sensations from the body to the brain and carries the command feedback back to the organs. It regulates the facial muscles, influences our breathing heart rate, and is involved in how we perceive, react to and recover from stress. Neuroscientist Steven W. Porges Ph.D., in his Polyvagal Theory of Emotion, suggests that when we enhance our connection with other people, we trigger neural circuits in our bodies that calm the heart, relax the gut, and turn off the fear response. Every time we interact with people, the vagus nerve, also called our social engagement system, is in active mode. Like other muscles in our body, when activated it exercises.

When we are working remotely, we heavily decrease our human-to-human interactions, at least in the real world. Without this interaction, our vagus nerve, as it does not exercise anymore and becomes passive, starts to atrophy. When we are lonely, our brain alarms us, saying “help, we are losing our ability to connect with other humans which is very necessary to survive. Please interact with others”. Since we have not practiced solitude, the next reaction to the presence of loneliness is fear. With this fear, we become more conservative to any threats and become more self-isolated. So starts the evil cycle that starts to weaken our connection to others, accelerates the atrophy, and pulls us into depression, anxiety, and further loneliness. Physiologically as well, it’s experimented that after some period of isolation and environmental monotony, our brain mas shrinks.

More specifically remote working, there are a few psychological issues that arise, such as Placelessness, nowhereness, non-visibility, reduced creativity. As mentioned above, when we work onsite, we have a dedicated physical workplace, which is perceived and influenced by our Global Positioning System (GPS) neurons that code our navigation behavior. Bringing the workspace interaction to remote video conferencing virtual interaction, our GPS neurons, mirror neurons, self-attention networks, spindle cells, and interbrain neural oscillations get affected. This in return affects our identity and cognitive processes, such as social and professional identity, leadership, intuition, mentoring, and creativity.

Another famous phenomenon is Zoom fatigue, which is basically having the sense of tiredness, anxiety, and fatigue like discomforts. The reasons for the Zoom fatigue are non-optimal functioning of technology (“sorry, my internet cut out”, “we cannot hear you”, etc.), and a significant increase of cognitive resources to understand the meaning of others’ verbal communication since there are very reduced nonverbal cues.

how to start remote and async collaboration

So, remote working can be dangerous in long term, right?! So given that we will stay mostly remote, what should we do about it? Metaverse, VR based virtual workplace concepts could help, but we are still quite far from there. What we can do is to mitigate the psychological damage by integrating interaction and perception of having a place into our remote setups. For every new change, idea, or challenge there is a simple process that should work:

  1. Continuously monitor and identify what doesn’t work anymore or can be improved
  2. Make adjustments by doing small experiments
  3. If the adjustment advances the situation, keep it and move to the next issue. If the change won’t be successful, come up with another experiment.

TIPS FOR REMOTE & ASYNC WORK

This is a list of mixed practical tips that I could come up with. It could be more structured, but enough cognitive workload for this post.

Get rid of most non-value-adding meetings – Since we already saw that meetings over videoconferencing tools is brain consuming, we do not want to overload people with random updates, non-relevant meetings. How? use your intuition. Do you need their input? Is this urgent? Should everyone be involved? Could your question be answered via email or chat? If you could answer these questions, then you have your answer to the question of if you should invite them to a meeting. There is a nice guiding post from doist on this.

Set up minimal explicit expectations about sync communications – when inviting people to meetings, make sure you have the purpose, agenda, and the expected outcome of the meeting explicitly written. and do decline the meetings where this information is missing. When writing people in chat, make sure you provide the purpose of your message: Keyword FYI for just update post or the keyword INPUT/ACTION REQUIRED for input-requesting messages can be helpful to understand the intention of your message.

Have a structured messaging ecosystem – your messaging tool should have a structure for an efficient communication flow. Work-related stuff should be clustered into topics channels. In order not to disturb everyone for every reply, write the comments and thoughts inside threads, which people can turn off the notifications for if they are not interested. Have a hangout/random/fun channel for non-work related stuff. Think twice before @mention’ing the whole channel, if it is not a relevant post for everyone. Have profiles tagged with their roles and other necessary information (location, product/project, contact preference).

Communicate updates mostly async – If it is just an update that does not require any input from people, make it async. Create weekly digest practice where the week’s main goals are documented as well as what people focus on individually. Have a diary-like daily standups instead of meetings. For the daily standup, we tweaked the practice a bit by making it asynchronish, namely, we pre-fill the stand-up for the day and if there are discussion items, then we meet up. The time we save from sync stand-up meetings, we use for virtual hang out to talk about our day.

Log all important information & decisions in a single, easy to find place – All official communications about important updates and decisions should be easy to find by both internal and external stakeholders.

Pair-Programming Practice – to stimulate the human-to-human interactions, encourage pair-programming, sparring sessions among team members. it should not be just limited to the developer team, but rather extend it to other units as well.

Provide remote setup support – in order to ensure the physical well-being of the employees, companies should provide remote setup support. Subsidizing internet connection, providing ergonomic desks and chairs, having a holistic communication tech stack are a few practical supports organizations give to their employees. Obviously, regular IT support is a must as well.

Dedicated roles & accountabilities within an organization to foster remote & async – as for every other initiative, a DRRIver (direct responsible role or individual) with specific accountabilities should steer the implementation of the remote & async.

Some meetings should stay in sync mode – One-on-Ones, important decisions, kick-offs, brainstorming events should stay sync. Sync meetings create human-to-human connections and foster engagement, brainstorming, and creativity.

Organize quarterly onsite team retreat – As mentioned already, remote working may potentially create a disconnected feeling. Moreover, when new people join the team, they cannot create personal bonds virtually, due to the lack of visibility of body language, eye contact, physical interaction space, and more. Therefore, investing in regular retreats should connect the team and create a long term bond among team players.

Weekly Sync Hangout Meetings – Another meeting series you want to set up in sync modus are weekly virtual hangout. It could be an after-work drink&chat session or a midday coffee break with the whole team. This type of social activity contributes to the connection among team members.

Prepare templates for every communication type – to create efficient async communication and well-written documentation, it’s important to enable everyone in the organization to write better and more structured. One important means to enable people is giving them the training to improve their writing skills. Another simpler, faster, and more efficient method is to provide templates for every type of documentation, such as decision making templates, post-mortem templates, sprint planning/review/retro templates, conflict analysis templates, etc.

Start as soon as possible – Only way to be successful is to start experimenting as soon as possible. Instead of creating a perfect framework, come up with the earliest testable version, implement it and get feedback, and iterate further. You can start with the direct team and make it as simple as replacing some recurring meetings with an async substitute.

Have a KPI for tracking the success of every experiment – know what to measure and measure it. You need to first understand what the successful outcome looks like at the end, choose a metric that will show your progress towards that success target. It could be burndown, OKR, employee satisfaction, or something else. Make sure to have a metric that is aligned with your outcome success defined.

Don’t respond to messages or emails instantly & suggest others not to do it either – Put it as a status in your messaging tool, send it as an auto-reply to all emails or make it your profile picture. Communicate to people that you’re at the moment busy doing “deep work”. Responding instantly to any communication requests shows that you’re available to be requested on ad-hoc. Dedicate yourself to a time block every day for “focused productive work”. If people request feedback as soon as possible, just reply back saying “I am currently focused on X task, thus I’d need to get back to you after X days.” Just tell them that you’re busy, that’s it.

Focus on outcome oriented performance evaluation – Evaluate the individual performance based on outcomes, not on the number of hours worked. Each person should have a specific outcome they steer or a goal they’ve set up to achieve and they should be evaluated on the success rate of their outcome/goal.

One of the main values of the Agile Manifesto suggests we should value “individuals and interactions over processes and tools”. Going remote is confirmed to benefit employers and employees to be more efficient. To ensure the long-term robustness of the remote working, we should pro-actively experiment with new ideas and, based on the feedback loop, iterate further or move on. When doing these experiments, our top priority should be the satisfaction of individuals, including employees, customers, and stakeholders in general.

Top 5 news of February

We have again picked out some exciting tech topics for you. In this list, you can find a colorful bouquet of news from quality assurance, accessibility, Vue.js, design patterns, code understanding with extensive tutorials, videos, tools, and references to upcoming conferences. Be inspired.

Denigma is a tool that, supported by machine learning.

It can be used to understand unfamiliar programming constructs. The application translates code into understandable English. It may be a way for non-programmers to understand complicated code or assist with the documentation. I definitely had fun translating my code.

Vue.js is our favored frontend framework at Mercedes-Benz.io

This is why we are constantly upskilling ourselves. This can be done internally or on professional e-learning platforms. In addition, you can learn by yourself by watching the youtube channel of LearnVue.co where you can find everything from fundamental Vue knowledge to the latest developments. The entire tutorial series is free and is constantly expanding. Maybe something to bookmark for you to stay up to date.

The QA Global Summit’22 took place from 15-16 February 2022.

It is an online summit and is addressed to QA Engineers. We refer to a conference recording of the junior track in two parts. That’s 12 hours of content available for free. The videos are about test automation, the tester role, testing solutions, and live coding sessions are available too. So there should be something for all QA interested.

Patterns.dev is a catalog of patterns to increase awareness by Addy Osmani and Lydia Hallie. 

This project addresses the implementation, benefits, and pitfalls of common design patterns. It is a good source for those who want to brush up on their knowledge of design patterns. All articles are very well explained and illustrated with examples.

Axe-con is a conference on digital accessibility. 

It is aimed at developers, designers, business users, and accessibility experts of all experience levels. The Virtual Conference will be held from March 15-17, 2022. Tickets for participation are for free. Grab the chance to learn something on the topic of accessibility.

Articles by MB.ioneers

Our colleague Hannes has published a very comprehensive article on the topic of pair programming on our blog. In Pairing is Dairing he explains the advantages, refers to criticism, as well as describes how to implement pair programming and which tools can support you.

In times of remote work, coordination with colleagues has not become easier and calendars are flooded with appointments. In his article, “How to ditch meetings that prevent productivity”, Hido explains the effect on productivity and describes how to increase it again. For this, he gives guidance on how to decide which meetings to attend and how to politely decline them.

Thanks to all of you for sharing your knowledge within our company and expanding our horizons. Eliamar, Claudio, Christian, Miguel, Joao, and Nuno you are great.

Pairing is daring

WHY PAIR PROGRAMMING SHOULD BE IN EVERY TEAM’S TOOLBOX

Pair programming is old news for most developers. It’s quite possible that you “paired” with a colleague before and might have had some good and some bad experiences. In this blog post, you will get a quick overview of pair programming. You will learn that there are lots of benefits and potential downsides. Additionally, there are some hints on the process and pitfalls to keep in mind. Finally, you will find a quick overview of remote collaboration tools.

BENEFITS OF PAIR PROGRAMMING

According to a study conducted by a Microsoft Research team [1], participating developers reported “fewer bugs”, the “spread of code understanding”, and “higher quality of code” as the main benefits of pair programming.

Fewer Bugs

In many work areas, the four-eyes principle allows teams to spot errors early on. Developers usually conduct code reviews before code goes out to production. Think of pair programming as giving a programmer a second pair of eyes. They might spot bugs right away, leading to reduced friction down the road. The earlier you spot a bug, the easier it is to fix.

@Saad Bin Akhlaq: After a pairing session, I have more confidence in pushing the code since 2 engineers have already gone over it.

Spread of Code Understanding

According to the Agile Alliance, a team that applies pair programming will gain “better diffusion of knowledge among the team, in particular when a developer unfamiliar with a component is pairing with one who knows it much better.” You will notice a “better transfer of skills, as junior developers pick up micro-techniques or broader skills from more experienced team members.” Furthermore, the Microsoft study highlights that “there is never only one person in the team who knows all the code”.

In the paper “The Costs and Benefits of Pair Programming” [2] by Alistair Cockburn and Laurie Williams, they claim that “if [a] pair can work together, then they learn ways to communicate more easily and they communicate more often. This raises the communication bandwidth and frequency within the project, increasing overall information flow within the team.”

@Jobrann Mous: I especially enjoy a pairing session when I am exposed to different topics, codebases, and coding practices.

Higher Quality Code

The authors of the Microsoft study state that pair programming helps to improve code quality “through more extensive review and collaboration.” Also, “‘Programming out loud’ leads to a clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys”, says the Agile Alliance.

In addition to that, a quantitative study at the University of Utah [3] showed that pairs not only completed their programs with superior quality, but they consistently implemented the same functionality as the individuals in fewer lines of code.

Critique of pair programming

In the same study from Microsoft, developers listed cost efficiency, scheduling, and personality clash as their biggest problems when applying pair programming.

Cost efficiency

Management most likely is in doubt about the efficiency of pair programming. In the Microsoft study “the number one problem reported with pair programming is cost. Two people are being paid to do the work of one.” On paper, you halve the allocatable time of two developers. But there are studies suggesting that pair programming actually increases time spent by only 15% (and not 100%), while at the same time reducing the error rate by 15%. [2] Occasional pairing programming will balance out the cost with the benefits.

Scheduling

Yet another meeting? Calendars are already full and scheduling meetings is a pain? Pair programming will not improve the situation. If scheduling a spontaneous pairing session is hard, your team should review the number of meetings in general.

What worked well for the cross-functional engineering teams of Bertha and Mercedes Me Service apps, is a fixed pairing slot every two weeks. The engineers begin the 2 hours slot with a short alignment, check who is available, and what topics they can pair on. Then the pairs (or sometimes groups of more than two) start their sessions.

During sprint planning for Bertha, we schedule pairing sessions to tackle tickets with high estimations together.

The backend team of Reach Me is doing it differently. Instead of scheduling anything, they start their day with a Teams-call which they keep running in the background for most of the day. It simulates a being-together-in-the-office feeling and allows for spontaneous conversations, some of which lead to pair programming sessions.

Personality clash

Pair programming is not the best work mode for every problem. While some of us are happy to collaborate on a task and align with a colleague, others need alone time. They want to play around with different possible solutions, sketch something, etc.

Most programmers tend to shy away from collaborative tasks. They want to be on their own while coding. Practice (and constant nudging) is your only chance to convince introverted people to pick up pairing more often.

There are also big differences in the way people articulate themselves. Pairing a person who thinks longer before answering with a fast speaker might end up in a one-sided conversation. It’s important to give everyone enough space. You don’t need to rush anything.

It is an acquired taste

You sometimes hear “I need to get this done, I don’t have time for a pairing session”. Or “it will take me half the time explaining the issue to my colleague before being productive”. Please reconsider. True, pair programming comes with a cost. You have to set it up, agree on a work mode, explain the context. It adds cognitive overhead. Practice can mitigate most of that. If you are getting used to pair-programming it becomes a standard way of working within your team. Doing so will feel normal, and you will consider it for more and more assignments. Jumping on a pairing session with someone lacking the context should be the outlier.

HOW TO DO PAIR PROGRAMMING

4 simple tips for pair programming. Just give it a try.

Agree on topic and scope

There should be a common understanding of what the problem is, and a general direction of how to tackle it. Keep reminding each other when you are deviating too far from your goal. It’s easy to get lost. Now you have someone helping you to focus!

Pick your role, switch them

Usually, when sitting next to each other at one desk, there is one keyboard to share. This puts the person on the keyboard in a different position than the person next to them. The person who types – the “driver” – is more concerned about the coding details, types, syntax, formatting. The person off the keyboard – the “navigator” – can think about the bigger picture, e.g. abstraction layers, dependencies, potential refactorings, etc.

That situation changes when you are leveraging remote collaboration tools. All participants can now write to the current codebase, they can be “drivers” and “navigators” at the same time.

Regardless of the setup, you should keep all participants engaged by flipping through the two roles. This allows everyone to contribute to the lower-level and big-picture problems.

Acknowledge different pairing situations

You should always be aware of the circumstances and the setting of each session.

@Svitlana Piddubna: “Not all tasks are equally good for pairing, so I think it works best when someone sees a ticket that could be a good one for pairing and offers to work on it together”

Are you and your pairing partner on the same page about the issue? Can you both focus on the issue at hand? Does the schedule suit both of you?

Plan enough breaks beforehand. This allows accommodating for individual daily routines, habits, speed of thought, etc. Especially during a pandemic, we need to pay special attention to a flexible schedule (eg: no daycare!). Some people need their time thinking through things alone. Take a break from the session when needed. Pair programming doesn’t mean you are bound to each other for the whole session.

Consider also the implicit or explicit power dynamic within a pair. An example: You are the most experienced developer in your team. Your pairing partner is a junior member with knowledge of the context, but lacking coding experience. As a senior, you have the responsibility to motivate, acknowledge, and drive the conversation positively. Don’t be condescending, don’t turn it into a lecturing lesson. You only get the inspiration of your counterpart flowing when it is a mutual experience.

Programming out loud

Reflection is an important step in learning. You are allowing your brain to streamline your thoughts on a topic. More often than not, only when attempting to write down or articulate, do you realize that you haven’t understood a problem. Now imagine you are articulating and reflecting on your current assignment. You gain an improved understanding of the topic and your pairing partner gains insights into your thought process.

The Agile Alliance advised, that “‘Programming out loud’ leads to a clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys.”

PRO TIP: Think of TV chefs and how they orate every detail of their process.

Remote pair programming

The obvious downside of remote pair programming is the fact that you can’t grab the keyboard and switch between navigator and driver. The “navigator” is not looking at the same monitor as the person who “drives”. To overcome these barriers, a variety of tools can help.
The easiest and most intuitive solution is simple screen-sharing. If you need more elaborate features, look at tools like JetBrain’s Code With Me and Microsoft’s Live Share. They come with plenty of features to accommodate for a sophisticated pairing session.

Microsoft Teams

At Mercedes-Benz.io the main tool for remote collaboration is Microsoft Teams. Its screen sharing feature already allows for a great remote pairing environment. You set up a call, share your screen, and go. There is even a function to take over the controls of the shared screen. This can be helpful when a topic is hard to articulate or to switch roles between “driver” and “navigator”.

JetBrains Code With Me

The Code With Me service [4] allows any JetBrains IDE user to share and open up their codebase for collaboration with remote colleagues. It works across almost all their IDEs (Android Studio coming soon). You can give your colleagues instant access to your current project. Up to 10 developers can join one session, and collaborate on one codebase. Especially for a mob-programming session, this is quite a valuable solution. Each participant can choose to either sync with (or follow) the “driver” and see what they are seeing, or work on their code area, all within one session.

Visual Studio Live Share

Visual Studio and Visual Studio Code offer a similar service, Live Share [5]. You can start a collaboration session and share a link to it for others to join. You have fine-grained control over the permissions the session members get.

Conclusion

Pair programming is an important tool in the arsenal of software engineering teams. It’s a great way to share knowledge, reduce friction, and increase communication bandwidth. Most of us are currently working remotely. Introducing collaborative work methodologies like pair programming helps you to cope with that. Remote collaboration tools like screen sharing make it super easy to do. Now that you know more about pair programming, try it out more. You will be surprised about the positive outcome!

Reference

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/esem-begel-2008.pdf
[2] https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
[3] https://web.archive.org/web/20041129085715/http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF
[4] https://www.jetbrains.com/code-with-me/
[5] https://visualstudio.microsoft.com/de/services/live-share/

Running multiple versions of a Stencil design system without conflicts

Microfrontends and reusable Web Components are state-of-the-art concepts in Web Development. Combining both in complex, real-world scenarios can lead to nasty conflicts. This article explores how to run components in multiple versions without conflicts.

Microfrontend Environments (MFE)

In an MFE different product teams work on separate features of a larger application. One team might be working on the search feature, while another team works on the product detail page. Ultimately, all features will be integrated together in the final application.

These features range from being very independent to being closely coupled to other features on the page. Generally speaking, teams try to work as independently as possible, meaning also that they can choose which package dependencies or even frameworks they use – and which versions thereof.

Custom Elements

Web Components are a popular way of sharing and reusing components across applications and JavaScript frameworks today. Custom Elements lie at the heart of Web Components. They can be registered like this:

customElements.define('my-component', MyComponent);

You’re now ready to use <my-component> in the DOM. There can only be one Custom Element for a given tagName.

The Problem

Let’s imagine the following situation: The MFE features should reuse certain components, more specifically they should reuse the Web Components provided by the Design System (DS). The DS is being actively developed and exists in different versions.

As each feature is independent, different teams might use different versions of the Design System. Separate features are developed in isolation and work fine with their specific version of the DS. Once multiple features are integrated in a larger application we’ll have multiple versions of the DS running. And this causes naming conflicts because each Custom Element can only be registered once:

Feature-A uses <my-component> in version 1.2.3 and Feature-B uses <my-component> in version 2.0.0 

Oops! Now what? How do we address this problem? Is there a technical solution? Or maybe a strategic solution?

Forcing feature teams to use the same DS version

One way to address this issue is to let the “shell application” provide one version of the DS. All integrated features would no longer bring their own DS version, but make use of the provided one. We no longer have multiple DS versions running.

While this might work in smaller environments, it’s unrealistic for many complex environments. All DS upgrades would now need to be coordinated and take place at exactly the same time. In our case dictating the version is not an option.

The Design System

The problem is common when reusing Custom Elements in a complex MFE. It’s not specifically created by Custom Elements but it’s one that can be addressed by making small adjustments in the right places of the Custom Elements.

Our hypothetical Design System called “Things” has been built with Stencil – a fantastic tool for building component libraries. All components are using Shadow DOM. Some components are quite independent like <th-icon>. Others are somewhat interconnected like <th-tabs> and <th-tab>. Let’s check out the tabs component and its usage: 

<th-tabs>
  <th-tab active>First</th-tab>
  <th-tab>Second</th-tab>
  <th-tab>Third</th-tab>
</th-tabs>

You can find the full code of the components in their initial state here

A Stencil solution

The first thing we’ll do is enable the transformTagName flag in our stencil.config.ts:

export const config: Config = {
  // ...
  extras: {
    tagNameTransform: true,
  },
  // ...
};

This allows us to register Custom Elements with a custom prefix or suffix.

import { defineCustomElements } from 'things/loader';

// registers custom elements with tagName suffix
defineCustomElements(window, {
  transformTagName: (tagName) => `${tagName}-v1`
});

Great! Feature teams can now register their own custom instances of the components. This prevents naming conflicts with other components and each feature time can work a lot more independently. Alternatively, the “shell application” could provide version-specific instances of the DS.

<!-- using v1 version of the tabs component -->
<th-tabs-v1>...</th-tabs-v1>

<!-- using v2 version of the tabs component -->
<th-tabs-v2>...</th-tabs-v2>

Let’s imagine having 2 versions available. Feature teams can now pick from the provided options without having to provide their own custom versions.

We’re not done, yet

Looking at <th-tabs-v1> we can see that the icon component is no longer rendered. And the click handler even throws an error! So what’s going on here?


Wherever a component references other components we’ll potentially run into problems because the referenced components might not exist.

  • <th-tab-v1> tries to render <th-icon> internally, but <th-icon> does not exist.
  • <th-tab-v1> tries to apply styles to the th-icon selector which no longer selects anything
  • on click, <th-tab-v1> calls a function of <th-tabs>, but <th-tabs> does not exist
  • <th-tabs-v1> provides a method setActiveTab which no longer finds any <th-tab> child element

For every reference to another custom tagName we need to consider that the tagName might have been transformed using transformTagName. As transformTagName executes at runtime our component also needs to figure out the correctly transformed tagNames during runtime. It would be great if Stencil provided a transformTagName function that we could execute at runtime. Unfortunately, that’s not the case. Instead, we can implement a (slightly ugly) solution ourselves.

transformTagName at runtime

export const transformTagName = (tagNameToBeTransformed: string, knownUntransformedTagName: string, knownUntransformedTagNameElementReference: HTMLElement): string => {
  const actualCurrentTag = knownUntransformedTagNameElementReference.tagName.toLowerCase();
  const [prefix, suffix] = actualCurrentTag.split(knownUntransformedTagName);
  return prefix + tagNameToBeTransformed + suffix;
};

This function is not pretty. It requires 3 parameters to return a transformed tagName:

  • tagNameToBeTransformed: tagName that we want to transform, i.e. th-tabs
  • knownUntransformedTagName: untransformed tagName of another component, i.e. th-tab
  • knownUntransformedTagNameElementReference: reference to element with that untransformed tagName, i.e this.el

Usage example:

transformTagName('th-tabs', 'th-tab', this.el); // 'th-tabs-v1'

Note that this.el is a reference to the host element of the Custom Element created by the Element Decorator

Fixing our components

Using our transformTagName function we’re now able to figure out which tagName transformation needs to be considered during runtime.

TypeScript call expressions 

A Custom Element tagName may be referenced in querySelector(tagName)closest(tagName)createElement(tagName) or other functions. Before we call these, we need to find out the transformed tagName.

// Before
this.tabsEl = this.el.closest('th-tabs');

// After
const ThTabs = transformTagName('th-tabs', 'th-tab', this.el);
this.tabsEl = this.el.closest(ThTabs);

JSX element rendering

// Before
public render() {
  return <th-icon />
}

// After
public render() {
  const ThIcon = transformTagName('th-icon', 'th-tab', this.el);
  return <ThIcon class="icon" />;
}

Please note the .icon class, which will be required for the next step.

CSS Selectors

// before
th-icon { /* styles */ }

// after
.icon { /* styles */ }

Wrapping it up

And we’re done!

With a few small changes, we’ve adjusted the codebase to support running multiple versions of the same Custom Elements. This is a huge step for complex Microfrontend Environments. It gives feature teams more freedom in choosing the versions they want to use and releasing them when they want to release. It avoids couplings of features or feature teams. It also reduces coordination and communication efforts.

Find the code of the referenced example project in this Github repo. The second commit shows all required adjustments to support tagName transformations.

Performance considerations

Loading and running multiple versions of the same components at the same time will come with a performance cost. The amount of simultaneously running versions should be managed and minimal.

The top five articles of January from tech practice

We hope you had as good a start to the new year as we did. In the new year, we have news fodder again and therefore prepared small snacks for you to digest. #

UPCOMING CONFERECES

– Not only reading but attending conferences is also a great way to absorb new knowledge. Getting a good overview of upcoming conferences and finding the right ones for you is important. Dev.events created a helpful list from different tech areas. The list can be filtered by country and preferred technology. Pick the right one for you.


FOR ALL DILIGENT DIAGRAM ARTISTS 

– there is an extension for draw.io diagrams for visual studio code. This is worth its weight in gold if you want to manipulate values and diagrams programmatically or collaborate with others.


NOT ONLY VISUAL STUDIO CODE IS EVOLVING 

–  Jetbrains is also working on improving the user experience. That’s why they have a new editor currently in the preview phase called Fleet. The IDE promises lightweight, flexibility, collaboration, language inclusion, and much more. Check out the features in detail or subscribe to the updates once the IDE is available after the preview phase.


THE HISTORY OF THE <div> ELEMENT 

– the article shows the misuse and spans the arc to the semantically correct use of elements. Of course also the resulting advantages in terms of accessibility.


A NEW FUNCTION structuredClone() 

– will soon be supported by most browsers. It creates deep copies of objects. This blog post explains how it works.

BONUS
Are you still using git stash, new branch, and git stash apply then? Optimize your workflow and check out git switch.

ARTICLES BY MB.IONEERS
Hido has written another great article on the topic of remote work. There he illuminates this with a psychological eye and gives you tips to use at home. Check it out.

Andre wrote an article about what has been concerning us for a long time. He offers a solution on how to realize the execution of multiple versions of a stencil design system without conflicts. Check it out.

Enjoy reading and stay curious.

TECH PRACTICE: TOP 5 ARTICLES OF OCTOBER

For us, it is important to share interesting tech articles related to programming and our work environment.

In our October list, you find valuable insights from the areas of frontend development, mobile development, and quality assurance. Get inspired by the news we have gathered for you!

THE TOP FIVE OF OCTOBER:

1. An Interview With Elad Shechter on “The New CSS Reset”
2. This article discusses the benefits of Shift Left Testing in the software development lifecycle and the key considerations on how to maximize the success of a product by using this approach.
3. VS Code introduces a lightweight version of vscode.dev that runs entirely in the browser. Coding can thus also be done via a smartphone. Clicking on the “.” button in any public repository will open the vscode browser version for comfortable multi-editing of the files. What do you think, will you make use of it?
4. Apple introduces Tech Talks 2021, live online sessions for developers offering the opportunity to talk directly with Apple experts for receiving personal advice.
5. In this article, you find exciting and fun things we can do with CSS for common UI challenges.

BONUS

1. Netflix developers are pretty good at writing articles on their own tech blog. Have a look. 
2. This article in particular is recommended for people who want to get to grips with image formats in a very excessive way.

Stay curious.

A big thank you to Claudio, Gabriel, Ruben, and Christian who regularly share interesting news with us.

TECH PRACTICE: TOP 5 ARTICLES OF SEPTEMBER

For us, it is important that we share what we discover interesting in the world. Which articles we read especially in relation to programming and our work environment. Therefore, we actively share articles with you.

The result is a list of the top five articles created from the interactions with the articles shared by you as MB.ioneers.

TOP FIVE OF SEPTEMBER:

1. What if we can just play games and learn something new while playing? Find out here with a very extensive list of web applications with which you can learn through play.

2. An article that deals with the difference between the variable types “any” and “unknown”, explains them with an example and shows the advantages. https://dmitripavlutin.com/typescript-unknown-vs-any/

3. Attention! Be careful when using the dot operator and reflect on whether destructuring the values is possible and makes more sense.

4. What are pitfalls when using NPM or how do you deal with upgrades?

5. It’s this time of the year again that open source maintainers love because of Hacktoberfest! It’s usually a nice time of the year to look to contribute to OSS because everyone is doing, so maintainers are usually very active in approving and interacting with your PRs. Start actively participating in the open-source community and find the first simple steps here!

But please read for yourself and stay curious.

BONUS ARTICLES

by Roman Guivan who has just started a multi-part Pixi.js game tutorial. follow him on his journey.

and Barbara Jöbstl with a Unix command cheat sheet which is perceived by the community as very complete.

A big thank you to all those who actively share articles with their colleagues at MB.io. You guys are great.

TECH PRACTICE: TOP 5 ARTICLES OF AUGUST

For us, it is important that we share what we discover interesting in the world. Which articles we read especially in relation to programming and our work environment. Therefore, we actively share articles with you. As an example, we have now done this in the FE circle and taken the interactions with the postings in MS teams as an indicator of interest. The result is a list of the top 5 articles that is still very frontend heavy but this will change in the future.

TOP FIVE OF AUGUST