Ohrstöpsel und "Mikrotechniken".

Sobald meine Ohrenstöpsel kaputt oder verloren gehen, laufe ich hinaus und kaufe ein neues Paar. Sie helfen mir sehr, meine Ruhe zu bewahren und produktiv zu sein.

Mikrotechniken sind kleine Dinge, die die tägliche Arbeit schneller machen. Wie bindet man am schnellsten seine Schuhbänder, wie kopiert man eine Spalte in der Tabellenkalkulation, wie eine Methode von einer Klasse zu einer anderen, woran merkt man, dass der Terminplan ausser Kontrolle gerät? Wie legt man seine CRC Karten am besten auf den Tisch, so dass sie einfach veränderbar sind? Ich sammle solche Mikrotechniken andauernd und bemerke, dass andere superproduktive Leute das auch tun. Kent Beck hat einen Knopf in seinen Smalltalk Debugger gesetzt: "Methode einfügen". Sobald er im Debugger eine "MethodNotUnderstood"-Fehlermeldung bekommt, drückt er einfach auf diesen Knopf. Das erspart vielleicht 45 Sekunden Klicken und Tippen. Der grosse Gewinn sind aber nicht die 45 Sekunden, sondern die Tatsache, dass sein Gedanken- und Arbeitsfluss nicht unterbrochen wurde. Zack, war die Methode da und er musste sie nur noch ausfüllen.

Wenn man sich hier und da einige solcher Unterbrechungen einspart, kann eine Mikrotechnik-bewusste Person in einer halben Stunde viel mehr leisten als jemand anders. Das macht oft gerade den Unterschied zwischen der Erfüllen und dem Nicht-Erfüllen einer Aufgabe innerhalb einer bestimmten Zeitspanne aus. Ich habe einmal einem Projektmanager geholfen, der sich mit Tabellenkalkulationen nicht gut auskannte. Nachdem ich das Werkzeug und die Abkürzungen kannte, erstellte ich in wenigen Minuten eine brauchbare Projektvorlage, die er überhaupt nicht erstellt hätte, da er dafür einige Stunden hätte investieren müssen.

Für mich sind APL, LISP, Simula und Smalltalk ganz oben, nicht nur, weil man wenig Energie aufwenden muss, um etwas zu erreichen, sonder viel wichtiger, weil man ein Repertoire an Ausdrücken aufbauen kann, mit dem das Arbeiten im Lauf der Zeit schneller und einfacher wird. Ich führe Prolog nicht in der Liste, da es zwar mit vielen Fähigkeiten beginnt, diese sich aber nicht weiter entwickeln. Ein Jahr, nachdem ich mit Prolog begonnen hatte, schrieb ich noch auf dem gleichen Ausdrucksniveau wie zu Beginn. Das passiert mit den anderen Sprachen nicht. Mit Smalltalk kenne ich mich am besten aus, deswegen ist es immer noch meine Lieblingssprache. Ich bin sicher, es gibt andere Sprachen mit ähnlichen Eigenschaften, die ich nicht gelernt habe.

Rexx ist eine andere Sprache, die für prozedurale Programme sehr schnell, einfach und ausdrucksstark ist. Die objektorientierten Versionen von Rexx waren nicht so angenehm.

Nichts schlägt vorgefertigte Routinen und Codegeneratoren. GUI-Designer sind die beeindruckendsten Codegeneratoren, die ich kenne. Sie erlauben es einem, Code großzügig zu "verteilen", um sehr viel Spezifikation mit sehr wenig Aufwand zu erhalten. Ich habe ab und zu Programmierer Ähnliches mit Datenbanken machen sehen: Datenmodelle steuern sowohl das GUI als auch das Datenbanklayout. Leider sind diese schwer zu verallgemeinern. Tabellenkalkulationen leisten auch sehr viel Rechenarbeit bei sehr wenig Benutzeraufwand.

Deprimierend ist, dass ich keinen Produktivitätssprung "voraussehe". Ich hoffe, dass noch weitere Gebiete aufgetan werden, in denen Codegeneratoren eingesetzt werden können, zum Beispiel für ferngesteuerte Funktionserzeugung oder Zugriffsmöglichkeiten, für Drag-und-Drop Datenbankoberflächen, sogar Mini-Sprachen zum Erzeugen von Testszenarien. Ob das passiert hängt davon ab, dass Einzelpersonen die richtigen Erfindungen machen.

Die meisten Programmierer werden zu oft unterbrochen. Sie sollen an 3 bis 8 Projekte gleichzeitig arbeiten und rotieren im Kreis, wenn sie von einem Projekt zum anderen wechseln. Dann müussen sie noch den Status für jedes Projekt melden und haben keine Zeit mehr für Fortschritte.

In den produktivsten Gruppen, die ich gesehen habe, arbeiten Programmierer an 1 bis 1.3 Projekten gleichzeitig. Sie sitzen da, wo sie sowohl in Ruhe arbeiten als auch nach Bedarf Fragen und Antworten stellen können. Sie arbeiten an relativ kleinen Aufgaben und machen diese vollständig fertig, bevor sie etwas anderes tun.

Im Moment denke ich, dass es noch mehr Rauschen als Signal ist. Ich freue mich darauf, widerlegt zu werden :-).

Programmieren basiert auf Fertigkeiten. Die meisten Programmierer lernen tippen und die Sprachsyntax und denken dann, für den Rest ihres Lebens ausgelernt zu haben. Gute Programmierer erweitern ständig ihre Fähigkeiten, indem sie nicht nur die neuesten Technologien erlernen, sondern auch bessere Arbeits- und Denkgewohnheiten und bessere Techniken. Lernt und verwendet zum Beispiel:

• Wie man ein Programm "ableitet", um Randprobleme zu vermeiden (das Buch von Gries, The Science of Programming, ist gut),
• wie man effektive Unit-Tests schreibt (beginnend mit dem Herunterladen und dem Tutorial von JUnit),
• wie man "verantwortungs-basiert" designt, mit und ohne CRC-Karten,
• wie man ein kurzes und trotzdem effektives Benutzerszenario schreibt,
• wie man eine Mini-Sprache für Testfälle schreibt,
• wie man eine Applikation automatisiert testet,
• wie man Updates monatlich ausliefert,
• wie man einem Manager erklärt, was man getan hat und tun wird,
• und eine der Dutzend anderer Sachen, die dich effektiver machen.