Namen sind nicht nur Namen für Namen

In Märchen dreht sich viel darum, dass der, der etwas benennen kann, damit auch macht über das benannte Ding ausübt. Beispielsweise Rumpelstilzchen, das besiegt ist, nachdem sein Name bekannt wurde. Ein gezähmtes Tier binden die Märchenhelden für immer an sich, in dem sie Ihm einen Namen geben.

Mit Namen und Sprache darf man nicht schlampig sein. Wer das ist, verschenkt nicht nur Macht und steht dumm da, sondern erschwert auch Kommunikation. Wer nicht zu benennen weis, wird nie ein Märchenprinz.

Wir sind ständig in einem schöpferischen Prozess und müssen ständig Dinge benennen. Sei es Kopfleuchten, Touble Tickets, Variablen, Kundenprojekte oder Subversion Branches. Das ist jedes mal eine kreative Aufgabe und wie bei so vielen Sachen kann man das üben. Allerdings kommt die Übung nicht von selbst: man kann Dinge auch 10.000 mal immer gleich gut oder schlecht machen, wenn man sich nciht aktiv bemüht, besser darin zu werden.

Dinge zu Benennen ist immer Kommunikation.

Dass bedeutet, wann immer man etwas benennt, kommuniziert man mit anderen Menschen. Was will ich den anderen sagen? Wenn ich zwei Verzeichnise “huShop-4531″ und “hushop-4567″ nenne, was sage ich über die Software in diesen Verzeichnissen? Was sage ich über der Bedeutung, die ich der Tatsache beimesse, dass andere sich für das, was ich da Treibe interessieren könnten? Was sage ich über meine eigene Arbeit?

Wenn ich einen Terahertzpersonenscanner “Nacktscanner” nenne, was sage ich darüber, wie ich zu den Menschen, die dieses Gerät benutzen solle stehe? Wie wichtig ist es mir wohl, was die Nutzer beim Durchschreiten des Geräts denken?

Was sagt mir eine commit message wie “Added shop Revision 3968. Take care!”?

Was sagt ein Ticket Betreff wie “offener Auftrag”? Sind offene Aufträge ein Problem?

Was sage ich mit einer Mail wie “Hallo liebe Kollegen, unser treue Diener Drucker Printy braucht eine neue Trommel – DANKE.”? Danke wofür?

Was sagen Funktionsnamen wie do_the_thing() oder was sagt es über den Autor aus wenn ein Python Docstring zur Funktion add_fiive() lautet “This function adds five”?

All das ist Kommunikation und hat immer mit dem Autor und seinen Lesern zu tun. Und an all dem kann man meiner Meinung in sehr vielen Berufen sehr gut ablesen, wie gut jemand in dem ist, was er macht. Und natürlich, ob er daran arbeitet besser darin zu werden. Wenn jemand konstant Dinge schlampig benennt, dann ist es selten, dass der Rest der Arbeit gut ist.

Softwareentwicklung und Systemadministration sind neben dem Erstellen von “Rechenvorschriften” für Computer zu einem sehr großen Teil Kommunikation. Mit unseren Kunden – d.h. den Nutzern der Systeme – und untereinander. Mit den Leuten, die in 10 Jahren etwas, was wir gebaut haben, debuggen müssen. Mit den Leuten, die auf dem Fundament, was wir gelegt haben, etwas aufbauen sollen. Mit den Leuten, die eine Aussage darüber treffen müssen, ob unser Code dies und jenes kann. Mit den Leuten, die unseren Code lesen um besser programmieren zu lernen.

Jenen Namen, dem wir einem Ding geben ist etwas, der uns und dem Ding lange anhängen wird. Etwas, auf das wir stolz sein können, oder etwas das unser unüberlegtes Dahergetippe dokumentiert.

Donald Knuth hat vor 25 Jahren gut ausgedrückt, wie ein Wechsel der Blickrichtung auf das Programieren zu besseren Programmen führen kann:

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. (Donald Knuth)

Aber anstatt mehr und mehr Programmieren als Kommunikation aufzufassen, werden wir auch in der klassischen Kommunikation immer schlampiger.

Es mag schwierig sein, klar zu sagen, was etwas ist und was man will, aber das ist kein Grund nicht ständig zu versuchen besser darin zu werden.

  • cklein

    Was sagt mir eine commit message wie “Added shop Revision 3968. Take care!”?

    Viele Mitteilungen sind nur sinnvoll, wenn man sie im Kontext betrachtet. Unmittelbar davor wurde erwähnt, dass jemand die aktuelle Revision des Projekts, bzw. sogar das Repository selbst, in einen Zustand gebracht hat, in dem es nur noch gelöscht wurden konnte um es dann nochmal neu einzustellen.

  • http://md.hudora.de/ mdornseif

    Das mit dem Kontext ist ein guter Punkt!

    Insbesondere: hat der Sender sich um den Kontext des Empfängers Gedanken gemacht oder ist die Mitteilung nur aus dem Senderkontext heraus verständlich?

  • http://www.armin-gerhardts.de/ Armin

    Lustig, gestern habe ich auch etwas veröffentlicht zum Thema “Dinge beim Namen nennen”. Es trifft Deinen Tenor zwar nicht völlig, aber es geht in die Richtung:

    http://www.kite-cafe.de/kiting-is-no-fun/Entfaltung.html

blog comments powered by Disqus