Technisches Schreiben: (nicht nur) für Informatiker [Taschenbuch]

Dieses Buch ist ein schmankerl' für alle die schon technische Artikel geschrieben haben, oder planen einen zu schreiben.

Der Autor zitiert gerne Teile aus verschiedensten technischen Arbeiten, und zeigt damit, wie man es gerade nicht machen soll. Anschließend gibt er eine - seiner Meinung nach - bessere Formulierung und erläutert das aufgetretene Problem.

Ausdrücklich verweist er darauf, daß dieses Buch in vielen Fällen nur seine Meinung wiedergibt, und das jeder Leser angehalten ist, sich seine eigene Meinung zu bilden.

Es bleibt zu bemerken, daß dieses Buch ist kein vollständiges Lehrbuch ist. Aber es gibt einem dutzende gute Hinweise, mit denen man an seinem eigenen Schreibstiel arbeiten kann.

Sehr empfehlenswert!

Der Titel des Buches ist viel zu allgemein. Der Autor betrachtet ausschließlich die akademische Seite der Informatik und auch nur die deutsche Sprache.

Wie der Autor auf S. 130 sagt, sind Anforderungsdefinitionen, Spezifikationen, Programmdokumentation, Handbücher, Bedienungsanleitungen usw. nicht im Rahmen des Buches.

Das Buch ist damit für den Arbeitsalltag eines Informatikers in der Industrie nur eingeschränkt brauchbar. In weiten Teilen des Buches geht es eher um korrektes Deutsch und um einem dem Verfasser genehmen Stil.

Bei "Amerikanismen" nimmt der Autor schon eine ziemlich starke Position ein. Für "Heap" sollte man "Halde" und für "Stack" den "Stapel" verwenden. Mein Lieblingswort damals, als ich mich mit der logischen Programmierung beschäftigte, war die eingedeutschte Version "unifizieren". Das sollte ich nach Meinung des Autors nur noch im Passiv gebrauchen (S. 101).

Diesen Standpunkt kann sich der Autor als Professor sicherlich erlauben, denn er kennt die Problematik in der freien Wirtschaft nicht.

Ich habe jetzt über 10 Jahre als Unternehmensberater (ich sage jetzt mal nicht "Consultant", weil das ja ein Amerikanismus ist) in Projekten gearbeitet. Ich habe die Erfahrung gemacht, dass die in der Hierarchie höher stehenden Leute, also die für das Projekt verantwortlichen Führungskräfte (die "project owner" mit den "business cases" und den "responsibilities") sehr empfänglich für "Buzzwords" sind. Wenn ich da jetzt mit meinen 40+ Jahren in einem Projekt anfange, die meisten Begriffe einzudeutschen, sehe ich die Gefahr, dass man mich für veraltet hält oder denkt, das ich nicht auf dem aktuellen Stand bin.

Vielleicht ist das aber auch ein "Generationenproblem". Der Autor nennt viele "Modewörter", die ich bisher für gutes Deutsch gehalten habe, wie z. B. "in etwa", "kein Problem" und "deutlich". Sprachen unterliegen Änderungen und mir persönlich macht es nichts aus, Wörter aus dem Englischen zu übernehmen. Ich werde weiterhin die Stacks und die Heaps verwenden.

Eine große Schwäche hat das Buch auf der didaktischen Seite: Als Beispiele werden nur einzelne Sätze oder Absätze und keine größeren Kapitel oder Arbeiten genannt. Es wird nicht ein Beispiel eines guten Fachaufsatzes oder einer guten Diplomarbeit gezeigt oder ein Link (ja, ein Amerikanismus) dazu genannt.

Ich habe auch schon Bücher über das Schreiben von Romanen, z. B. "Wie man einen verdammt guten Roman schreibt" von James N. Frey oder von Drehbüchern, z. B. "Writing Screenplays That Sell" von Michael Hauge gelesen. Bei diesen Büchern hat man nach dem Lesen zu mindestens einen Startpunkt und weiß in welche Richtung man weiterarbeiten muss. Man kennt auch die nach Meinung der Autoren guten Romane bzw. Drehbücher und kann sich hier Tipps holen. Kunstkritiker mögen der Meinung sein, dass man mit solchen Schritt-für-Schritt-Anleitungen keine künstlerisch wertvollen Werke schaffen kann, aber das ist beim technischen Schreiben auch nicht das Ziel.

Und daher bin ich ein wenig verwundert, dass der Leser im Buch von Peter Rechenberg keine Schritt-für-Schritt-Anleitung bekommt, wie er beim Verfassen vorgehen sollte, worauf er zu achten hat, etc. In dem Buch gibt der Autor eine Menge Tipps, aber diese sind über die einzelnen Kapitel verteilt. Es werden auch ein paar wichtige Stellen als "Lehren" hervorgehoben, leider gibt es hierzu keinen Index oder eine Liste, die alle diese "Lehren" enthält.

Wenn man von diesem Buch profitieren will, sollte man also die inhaltlichen Grundlagen des technischen Schreibens bereits herrschen und schon ein paar Arbeiten gelesen haben. Dann kann man auch von den vielen Tipps des Autors, z. B. zur Vereinfachung von Schachtelsätzen oder zur Vermeidung von Schaumschlägerei, profitieren.

Mein Vorschlag für den Titel des Buches ist "Gutes und korrektes Deutsch für Diplomarbeiten und Dissertationen (die von älteren Professoren bewertet werden)".

Der Author lässt sich mit Genuss über stilistische Fehler anderer Authoren aus. Wirkliche Hilfe gewinnt man durch das Buch kaum. Die Übungsaufgaben schärfen den Blick für falsche Wortwahl und unklare Ausdrucksweise.

Es gibt Kapitel über Gliederung, richtiges zitieren, etc. Aber sie sind so kurz, dass sie nicht ausreichen und auf weitere Literatur zurückgegriffen werden muss (wie zitiert man z.B. Quellen aus dem Internet?).

Der Bezug zur Informatik ist hauptsächlich dadurch gegeben, dass die Beispiele aus entsprechender Literatur kommen.