Story 3: After days of preparation and a long flight, we finally landed on the Moon. We will face the first and maybe one of the biggest challenges when traveling: language barriers!
The tourist group consists of people from different countries. Even we have an international language, English, barriers will always exist because of different cultures, knowledge, or skill set. Alternatively, how can we facilitate communication with Moon’s citizens who have no idea about our language but their own one?
At Cốc Cốc, our SysAdmin team helps developers to move their services from bare-metal to containers. They care about applications and container images, we will then help to manage manifests of Kubernetes deployment units and provide backing services in the new ecosystem. Since we want to encourage all development teams to change the way that we deploy our products for years to something new and fresh, we need a big time-consumed effort to understand each one requirement and needs. The first challenge just appears. The more we communicate the more we have trouble understanding each other.
Container, docker, docker-compose, Kubernetes,…
The most obvious example of a language barrier is people speaking languages native to different regions. In the same way, as we’re all have a certain level of experience with containers but someone only works with docker and its toolset, such as docker-compose, while the other one starts right away with a cutting-edge and fancier toolset, like Kubernetes, Containerd,… There are a few other types of language barriers.
- Proficiency: Your field and skill set may involve a lot of technical languages. When you speak to people outside your domain, you get lost in translation.

https://twitter.com/memenetes/status/1180992680173563905
- Technical: People can technically speak the same language, but the gap in technical knowledge can create misunderstandings. Technical linguistic barriers come with the use of the technical terms by experienced workers, which newcomers and outsiders typically struggle to understand.

- Cultural: When speaking to other departments, it’s important that each one can communicate information in terms that everyone else can understand to ensure we’re all aligned on our common goals. If sysadmin doesn’t understand what the developer is doing, and the developer has no idea what the infrastructure team is dealing with, we’re all in deep trouble.

https://blog.openebs.io/ive-become-a-chairman-of-cloudbyte-openebs-28f26435afe
Some tips to fully understand each other
Use plain language: When you’re trying to communicate a technical problem to your co-workers outside of your department, everyone should get in the habit of using plain language whenever possible. Creating a culture in your workplace of speaking simply and explaining all issues as straightforwardly as possible is key.

https://cloud.google.com/kubernetes-engine/kubernetes-comic
- Use an interpreter whenever you give instructions to a newcomer in the other team. There may be someone who speaks both languages fluently enough to transmit your message.
- Use visual methods of communication: Explain the subject with pictures as much as possible.

- Use repetition: As with any new concept, most people don’t learn something the first time they hear it. They need to hear the same message over and over. Don’t expect people to learn anything after being told once.

- Ask for clarification: Avoid assuming you’ve understood what’s been said.

- Frequently check if people understand what you meant. Check both that you’ve understood what’s been said and that others have fully understood you.
So what’s your understanding on this process? - Just be patient!
Yet another foreign language — YAML
Nowadays, YAML represents itself as Ain’t Markup Language but originally was Yet Another Markup Language. It aims to serialize data in an easily readable format for humans. I’m actually a fanboy of YAML and Ansible for years.
The Kubernetes resources are preferably created in a declarative way, thus making use of YAML.

The key to a good declarative language is that it does a good job of describing a data/process in simple, finite terms with little room for subjective variation.
In comparison with JSON, another popular data-representation language:
- It doesn’t use a delimiter: it’s lightweight, easy to understand, and makes reading eye-comfort. You don’t have to worry about closing brackets or quote marks.
- It treats lines as information: it fits into any source control system, making version and change tracking easier than JSON. Imagine the effort you need to track changes in a single-line JSON document. There is no such representation way in YAML.
- It’s a superset of JSON: Whatever JSON/YAML code you have, you can parse both JSON and YAML code with a single parser or convert to each other without any problem.
- It supports comments!!!
However, not every human, such as some of my teammates — part of the tourist group, loves it as I am. Imagine you look at hundreds of lines of Kubernetes manifest in YAML format and try to figure out what is wrong. It won’t be a pleasant experience with a lot of indentation levels. It’s pretty hard to scan and make sense of its structure by your eyes.
An extra precaution while writing YAML code: even if you mismatch a single space while indentation, your code can stop working. Most of the time you won’t get an error at all because the indentation is just right but a valid YAML doesn’t mean a valid configuration. It will be even worse when a group of people works together on a YAML file but they are on different sides of the space-vs-tab debate.
Also, there are many ways to represent data in YAML and make a data hierarchy: scalar, collections, multi-line collections, lists/dictionaries, multi-line formatting. So it is complex for processing.

Some tips for YAML haters
Make your editor do the work
Whatever text editor or IDE you use always has plugins to make dealing with syntax easier. I found a very useful one for my favorite code editor, VSCode, called indent-rainbow to deal with indentation pandemic.

Do not add more complexity to YAML
At Cốc Cốc, we’re using Kustomize instead of Helm for a reason
Kustomize lets you customize raw, template-free YAML files for multiple purposes, leaving the original YAML untouched and usable as-is.

Language barriers can be a challenge, but working with people of different cultures and backgrounds is what drives creativity and success. Don’t let these barriers stand in the way of embracing everything we’re trying to archive in our organization.
References
https://guides.co/g/the-seven-barriers-of-communication/37696