Wenn ich erzähle, dass ich Software Engineer und Journalist bin, gibt es diesen kurzen Augenblick des Überlegens bei meinen Gesprächspartnern. „Interessante Kombination“, lautet dann die typische, überraschte Reaktion. Denn die Parallelen fallen nicht sofort auf. Am Ende sind sich beide Professionen aber viel ähnlicher, als die meisten vermuten.
„Ein Satz, ein Gedanke!“ Nach diesem Credo strukturiere ich alles, was ich schreibe. Bei einem Artikel ist es der einzelne Satz, bei Quellcode ist es die Programmzeile und in Architekturen etwa eine Komponente. Auch die jeweils nächst höhere Strukturinstanz folgt dem Ein-Gedanke-Prinzip. Mehrere Sätze ergeben einen Absatz, dem ebenfalls wieder ein einzelner Gedanke innewohnt. Gleiches gilt für das Codeäquivalent eines Absatzes, dem Funktionsblock, oder für Kapitel und Klassen, für Abschnitte und Module.
„Einer muss sich plagen, der Schreiber oder der Leser“, ist ein weiteres Credo. Der Leser steht für mich immer im Mittelpunkt. Ich schreibe nicht, um mich selbst darzustellen. Ich schreibe, um den Lesern etwas zu vermitteln, ihnen einen Mehrwert zu liefern. Der Text muss folglich so strukturiert und verfasst sein, dass die Zielgruppe ihn gut und einfach lesen kann. Auch hier schließt sich der Kreis zum Software Engineering. Code ist nicht für den Kunden oder Anwender gedacht, sondern für die Entwickler, die ebenfalls an einer Software mitarbeiten. Der Code muss deshalb so geschrieben und strukturiert sein, dass jeder andere Entwickler ihn gut und einfach lesen kann. Code sollte nicht als Selbstdarstellungszweck fungieren.
Auch andere Methoden und Konzepte lassen sich in das jeweils andere Fachgebiet übertragen. Die Zielgruppenanalyse der Publizistik entspricht dem Requirements Engineering, das Devops-Mindset und Continuous Delivery passen zum Betrieb inhaltslastiger Webseiten, Versionskontrollsysteme wiederum stellen eine hervorragende Basis für die kollaborative Textarbeit dar.
Bei msg kann ich meine beiden Professionen – Software Engineering und Journalismus – perfekt kombinieren. Einerseits bin ich als IT Consultant in Kundenprojekten unterwegs, plane und entwickle Anwendungen. Andererseits veröffentliche ich Artikel und halte Schulungen zu eben jenen Themen, mit denen ich mich tagtäglich beschäftige. Obwohl ich dabei mitunter den Kontext wechseln muss, bleiben die Methoden und Tools nahezu identisch. Ich profitiere also in jedem Kontext aus beiden Welten.
Ein eklatanter Unterschied existiert dann doch: Sprache und Code sind zwar gleichermaßen deterministisch. Während Code allerdings für sich selbst spricht, durch penible Linter und Compiler geprüft wird, unterliegen Texte stets einer Interpretation durch die Leserschaft.
Viele Grüße,
Mark