The Brains Behind the Books – Tanja Roth

This article has been contributed by Tanja Roth, Project Manager at the SUSE Documentation Team.  It is part of a series of articles focusing on SUSE Documentation and the great minds that create the manuals, guides, quick starts, and many more helpful documents.

The early years

I grew up in Trier, Rhineland-Palatinate, Germany, a city famous for its well-preserved Roman and medieval buildings. At school, I was interested in both languages and natural sciences. As an adolescent, I did not have any particular career aspirations and my parents did not push me in any specific direction – something that I am still grateful for! Based on my interests, I decided to study phonetics – a branch of linguistics that deals with the sounds of human speech. Apart from linguistics and communication theory, my studies also involved applied physics (analyzing speech signals), medical details (learning how speech is produced, perceived, and neurophysiologically processed) and some computational linguistics. During two courses in programming languages I first came into contact with UNIX: I needed to upload my programming homework via FTP from the university’s computer pool, using the Bourne shell. Other than that, I mostly worked with a DOS and Microsoft Windows environment at university, and some specialized systems for signal processing.

From phonetics to steelworks

Had anyone told me at that time that I would work in information technology later on, I would not have believed it! But instead of treating patients with language and speech disorders or helping to identify blackmailers based on their ‘voiceprints’, further studies (and coincidence) led me to the field of technical communication. I got my first insights into technical writing as a working student in a company that constructed cold-rolling mills – very exciting! Cold-rolling mills are used to produce metal sheets and foils. The mills have gigantic dimensions and are usually customer-specific, built from many components that are manufactured at different sites around the world. Unfortunately for this reason, it was impossible for me to see a cold-rolling mill in action. I could only study some components that were manufactured on site. For the product documentation, we had to heavily rely on blueprints, interviews with the engineers and the results of the obligatory hazard analysis. For legal reasons, the documentation for the cold-rolling mills had to be provided in printed format. The complete set of documentation for each rolling mill required several shelves!

Knowing that I had found ‘my’ vocational field, I moved on to a service provider for technical documentation. This allowed me to ramp up my knowledge about technical communication and project management in a very short time. I worked with customers in different industries, using highly standardized documentation processes and workflows. All of the documentation was written in SGML or XML and was published into multiple output formats using single-source publishing. I received an excellent training on the job at this service provider, but in some projects I also had to jump in the pond and learn to swim. Looking back, both has helped me a lot for any subsequent jobs!

From mechanical engineering to IT

My next job as a technical writer in information technology showed me that documenting software is an entirely different beast. Software is far more volatile than larger machines or mechanical parts. Mechanical parts are ‘palpable’ and allow you to analyze their main functions even when looking at a work-in-progress versions of them. However, bugs during the alpha and beta phase of software development can easily keep you from installing or trying out the software altogether. This makes it sometimes hard to come up with a useful draft documentation during the early stages of the product. In addition, software often comes with a lot of last minute changes. This can be a real challenge, especially if the documentation needs to be localized and thus has to be handed off to the translators well in advance of the release date of the product.

Step into the open source world

When I started to work for SUSE in 2005, it was my first contact with the open source environment, which is quite different from a proprietary software environment. For example, in proprietary software, you usually have full control over the terminology to use within your product and your documentation. In the open source environment, certain terms may already exist in the upstream community or documentation. You cannot start from scratch and have to find compromises. Also, open source communities are self-organizing entities to a large degree – a lot of things work differently, including decision-making processes.

Being part of the community

It took me some time to get used to this new world and to its broader dimensions, because we do not work on the Q.T., but in the open. And we are part of a much larger community around the world. Being part of this ecosystem taught me a lot about how communities work – and about myself. It also changed my mind-set: I have come to appreciate the ‘release early, release often’ dictum because feedback at an early stage is often really helpful. More than once I have made the experience that ‘the whole is more than the sum of its parts’, especially when working in this great team that I’m part of. I love my documentation colleagues for always sharing their spirit and for their creativity and knowledge. We often have different points of view, but everybody contributes their expertise and we work well together as a team. In addition, collaborating with people from all over the world and from different backgrounds is really rewarding. It adds new points of view and helps to analyze and solve problems more efficiently.

What would life be without…

As most of my daily work requires a lot of research, analytical thinking and sitting in front of a computer, music and sports are part of my work/life balance. Diving into rhythms is one way for me to relax, practicing yoga or spending time in nature are others. I always loved listening to music, and I enjoy dancing and going to concerts with my husband. But the switch from listening to music to making music happened about 10 years ago, when I first got hold of a drum. It was during an event called a ‘drum circle’, where everybody can participate and contribute to the common groove. Shortly afterwards, I started to learn playing drums and percussion. The following pictures show me building and playing an African drum.

Gahun Drum

… drums and music?

In 2015, my husband and me became certified ‘drum circle facilitators’. During our free time, we organize drum circles in the tradition of Arthur Hull – similar to the one we stumbled into many years ago. We also did a community drum circle at the openSUSE Conference in Nuremberg 2017.

At SUSE, there are several bands and music projects going on, many of which originated during Hackweek. One of last year’s projects was an a capella ensemble. Going from polyrhythmic drumming to singing in harmony was quite a leap for me, but I decided to give it a go. We performed three songs during the final Hackweek presentations. And we had so much fun singing together that we continued the project afterwards (and are in search of more ‘harmonists’ who would like to join us). Making music with others has added another dimension to my life for which I am very grateful!