I grew up in Trier<\/a>, 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 \u2013 something that I am still grateful for! Based on my interests, I decided to study phonetics<\/a> \u2013 a branch of linguistics that deals with the sounds of human speech. Apart from linguistics and communication theory, my studies also involved applied physics<\/a> (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\u2019s computer pool, using the Bourne shell<\/a>. Other than that, I mostly worked with a DOS and Microsoft Windows environment at university, and some specialized systems for signal processing.<\/p>\n Analysis of Speech Signal incl. Fast Fourier Transformation<\/p>\n 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 \u2018voiceprints<\/a>\u2019, further studies 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<\/a> \u2013 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!<\/p>\n Knowing that I had found \u2018my\u2019 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<\/a> or XML and was published into multiple output formats using single-source publishing. I got 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!<\/p>\n 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 \u2018palpable\u2019 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.<\/p>\n 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.<\/p>\n It took me some time to get used to this new world and to its broader dimensions: We do not work on the Q.T., but in the open, and we are members of a much larger community around the world. Being part of this ecosystem taught me a lot about how communities work \u2013 and about myself. It also changed my mind-set: I have come to appreciate the \u2018release early, release often\u2019 dictum. Feedback at an early stage can be really helpful. And more than once I made the experience that the whole is more than the sum of its parts, especially when working in this great team that I\u2019m 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 rewarding. It adds new perspectives and helps to analyze and solve problems more efficiently.<\/p>\n 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. I always loved listening to music, and enjoy dancing and going to concerts. But the switch from listening<\/em> to music to making<\/em> music happened about 10 years ago, when I first got hold of a drum. It was during an event called a \u2018drum circle<\/a>\u2019, 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.<\/p>\n Gahun Drum<\/p>\n In 2015, my husband and me became certified \u2018drum circle facilitators<\/a>\u2019. During our free time, we organize drum circles in the tradition of Arthur Hull<\/a> \u2013 similar to the one we stumbled into many years ago. We also did a community drum circle at the openSUSE<\/a> Conference in Nuremberg 2017.<\/p>\n At SUSE, there are several bands and music projects going on, many of which originated during Hackweek<\/a>. One of last year\u2019s projects was an acapella ensemble<\/a>. 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 had so much fun singing together that we continued the project afterwards (and are in search of more \u2018harmonists\u2019 who would like to join us). Making music with others has added another dimension to my life for which I am very grateful!<\/p>\n <\/p>\n Share with friends and colleagues on social media<\/p>\n![\"\"](\"https:\/\/www.suse.com\/c\/wp-content\/uploads\/2018\/08\/taroth_web-184x300.png\")
This article has been contributed by Tanja Roth, Technical Writer at the SUSE Documentation Team. <\/em>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.<\/em><\/p>\nThe Early Years<\/h2>\n
![\"\"](\"https:\/\/www.suse.com\/c\/wp-content\/uploads\/2018\/10\/speech_signal-300x213.png\")
<\/p>\nFrom Phonetics to Steelworks<\/h2>\n
From Mechanical Engineering to IT<\/h2>\n
Step into the Open Source World<\/h2>\n
What Would Life Be Without\u2026?<\/h2>\n
![\"\"](\"https:\/\/www.suse.com\/c\/wp-content\/uploads\/2018\/10\/gahun_film-300x179.jpg\")
<\/p>\n