Software Berater Logo Software Berater #neuland seit 1993

Zwei Regeln für meine Arbeit

Zwei Regeln, sie alle zu knechten: Eigentlich geht es darum, wie ich mir selbst Orientierung verschaffe. Ich versuche allerdings immer wieder, auch meine Kollegen für diese Regeln zu begeistern.

Braucht man Regeln? Vielleicht nicht zuviele, aber ein paar wenige erleichtern die Orientierung. Bei der Arbeit habe ich zwei Grundgedanken, die ich immer wieder hervorkrame. Mit Sicherheit bin ich meinen lieben Kollegen schon reichlich damit auf die Nerven gegangen, aber die Ideen finden immer wieder Anwendung. Ich weiss nicht mehr, wo ich die genau herhabe, irgendwie sind die im meinem Kopf “Allgemeingut”. Sollte es jemand besser wissen, würde ich mich über einen Hinweis freuen.

Die Baumhaus-Regel

Wer es nicht ohne fremde Hilfe ins Baumhaus schafft, darf darin keine Vorschriften machen.

Gerade im Konzern gibt es eine Menge von Leuten, die gerne dazu bereit wären, Regeln für andere zu machen. Über die Erstellung von Software. Über Werkzeuge. Über Prozesse und Methoden. Zur Verwendung von Tools. Die Liste ist schier endlos. Das Problem dabei: Um sinnvolle Regeln zu formulieren, bedarf es genauer Kenntnis der Sache, über die man Regeln formuliert. Damit ich zB gute Regeln für Entwickler mache, brauche ich die Kenntnisse eines Entwicklers. Ich muss Entwickler sein, oder wenigstens mal gewesen sein. Für Ingenieure, Juristen und Bäcker gilt gleiches, und für alle anderen.

Das besagt die Regel: Nur wenn ich im Themengebiet eigenständig, sicher und gewandt bin, macht es Sinn, dass ich dort Regeln aufstelle. Wenn ich es nicht allein “ins Baumhaus” schaffe, dann habe ich darin auch nichts zu sagen. Eat your own dogfood geht in die gleiche Richtung, die Idee von best practices auch. Nur durch Übung und Anwendung kann ich die Regel sinnvoll formulieren.

Für mich bedeutet das, dass ich mich heraushalte, wenn es darum geht, anderen Vorschriften zu machen, es sei denn, ich bin “vom Fach” und bereit, alle inhaltlichen Fragen kompetent zu beantworten. Ich überlasse das Regeln-aufstellen lieber denen, die sich damit auskennen, und halte mich dann auch an deren Ergebnis.

Die Zeltplatz-Regel

Verlasse den Zeltplatz mindestens so sauber, wie du ihn vorgefunden hast.

Wenn irgendwo Müll herumliegt, hebe ihn auf. Wenn etwas verbessert werden sollte, trage dazu bei. Beteilige dich daran, den Zeltplatz für alle Menschen nach dir zu einem besseren Ort zu machen. Ich will jeden Tag ein kleines bisschen daran arbeiten, dass der Zeltplatz in Schuss bleibt.

Für Entwickler ist der Code unser Zeltplatz. Begriffe wie “Software erosion”, “code smell” oder auch “technical debt” zeigen, wie wir das gedankliche Modell eines Projektes in Bezug zur realen Welt setzen: Code wird nicht vom Wind angegriffen, stinkt nicht und stellt auch keine finanzielle Schuld dar - und doch sind die Begriffe sinnvoll und beschreiben Effekte, die durchaus nachvollziehbar sind. Ich füge dem den Gedanken hinzu, dass Code unser virtueller Lebensraum ist. Wir verstehen uns als Gemeinschaft und stehen gemeinsam dafür ein, unseren Lebensraum zu schützen. Nennt es selbstlos oder altruistisch, es ist das Gegenteil von “not my job”. “Keine Zeit” ist kein Gegenargument, denn häufig sind es wirklich nur ein paar Handgriffe, die man im Vorbeigehen erledigt, um etwas Müll aufzuheben. Es kostet oft kaum Zeit, etwas zu verbessern, selbst wenn es nur eine Kleinigkeit ist.

Die beiden Regeln begegnen mir im (Arbeits-) Leben sehr häufig. Ich will anderen keine sinnlosen Vorschriften machen, und auch selbst nicht von solchen betroffen sein. Es soll nur wenige, aber sinnvolle Vorschriften geben. Aus der geringen Anzahl leite ich aber nicht ab, dass man egoistisch tun sollte, was einem gerade in den Sinn kommt, im Gegenteil: Die Lücke wird gefüllt von meiner inneren Motivation, “das Richtige” zu tun. Jeden Tag ein kleines Stückchen besser.