Zehn Dinge, die Programmierer nerven

Programmierer sind eine ziemlich besondere Gruppe. Weil sie über lange Zeiträume mit Computern arbeiten, neigen sie dazu, ähnliche Persönlichkeiten und Temperamente zu entwickeln. Natürlich haben sie als Menschen von Natur aus ihren eigenen Charakter und ihr Temperament. Jetzt möchte ich Ihnen zehn Dinge zeigen, die Programmierer verärgern können. Einerseits können wir sehen, was Programmierer gemeinsam haben; andererseits können wir auch ihre Schwächen sehen. Wie auch immer, ich hoffe, diese können Ihnen in Ihrer täglichen Arbeit hilfreich sein.

Zehnter Platz: Code-Kommentare

Code-Kommentare sind eigentlich eine gute Angewohnheit. Wenn erfahrene Programmierer Neulinge betreuen, sagen sie ihnen immer, sie sollen Code-Kommentare schreiben. Also folgen Neulinge natürlich dem Rat der erfahrenen Programmierer. Sie missverstehen jedoch möglicherweise, wofür Code-Kommentare gedacht sind, und deshalb sehen wir in Programmen oft Kommentare wie diesen:

Immer wenn Sie solche Kommentare sehen – die nur kommentieren, was, aber nicht warum –, werden Sie sicher verärgert sein. Wer hat diese Kommentare geschrieben? Es geht Ihnen erst besser, wenn Sie sie finden und ihnen ordentlich die Meinung sagen. Kommentare sollten anderen Ihre Absicht und Ihre Gedanken mitteilen, nicht die Syntax des Programms erklären. Das dient der Lesbarkeit und Wartbarkeit des Codes. Solche Kommentare, die nur um des Kommentierens willen gemacht werden, sind überhaupt keine Kommentare – sie sind eine Provokation, und es versteht sich von selbst, dass sie andere verärgern.

r = n/2;  //r是n的一半
 
 //循环，仅当r- n/r不大于t
 while ((r-n/r) <=t){
     //… …
     r = 0.5 * (r-n/r); // 设置r变量
 }

Neunter Platz: Unterbrechungen

Genau wenn ein Programmierer in das Nachdenken über einen Algorithmus vertieft ist oder beim Schreiben von Code eine plötzliche Eingebung hat, ist es eine sehr schmerzhafte Sache, von anderen unterbrochen zu werden. Wenn die Unterbrechungen anhalten, kann das jemanden sofort reizbar machen. Die Person, die unterbricht, ist in einer solchen Situation sehr unhöflich. Die unterbrochene Person ist wie ein Funktionsaufruf – wenn er zurückkehrt, muss er den Kontext an der Stelle der Unterbrechung wiederherstellen. Natürlich sind Menschen keine Computer, und die Wiederherstellung des Kontexts ist normalerweise ein schmerzhafter Prozess. In extremen Fällen müssen sie möglicherweise von vorne beginnen, um ihren Gedankengang wiederzufinden, und sich dann langsam zurück zur Unterbrechungsstelle vorarbeiten.

Deshalb habe ich einige Programmierer gesehen, die, wenn sie Ruhe brauchen, ohne gestört zu werden, entweder an einen Ort gehen, wo sie niemand finden kann, oder ein Banner über ihrem Schreibtisch aufhängen, um alle zu warnen – „Ich führe gerade das Kernelprogramm aus, kann nicht unterbrochen werden, bitte nicht stören, danke!“ Das zeigt, wie kostspielig es für einen in die Arbeit vertieften Programmierer ist, unterbrochen zu werden. Natürlich sind viele Menschen genervt davon, unterbrochen zu werden.

Achter Platz: Anforderungsänderungen

Das bedarf wohl keiner Erklärung. Solange man Programmierer ist, fühlt man sich bei Anforderungsänderungen oft hilflos. Ein- oder zweimal mag akzeptabel sein, aber ständige Änderungen kann man nicht ertragen. Es heißt, agile Entwicklung habe eine Methodik, die Programmierer Anforderungsänderungen genießen lässt – wer weiß, ob das stimmt. Aber heute verlangen sie von dir, einen Schreibtisch zu bauen, morgen verlangen sie, den Schreibtisch in einen Esstisch zu verwandeln, übermorgen in ein Doppelbett, am nächsten Tag in eine Hütte, und dann die Hütte in einen Wolkenkratzer. Seufz, jeder wäre genervt. Diese Leute können in einer 30-minütigen Besprechung jede Entscheidung treffen, aber die Dutzenden Programmierer hinter ihnen müssen Hunderte von Stunden harter Arbeit investieren. Wenn ich es wäre, bräuchte ich vielleicht auch ein mythisches „Grass Mud Horse“, um meiner Wut Luft zu machen.

Das zeigt jedoch auch, dass Programmierer nicht wissen, wie sie mit Nutzern kommunizieren sollen, und dass Nutzer nicht wissen, wie sie mit Programmierern kommunizieren sollen. Wenn ein Projekt keinen Vermittler (wie einen PM) hat, der koordiniert, dann kann das ganze Projekt wie „ein Huhn, das mit einer Ente spricht“ sein – sowohl Nutzer als auch Programmierer werden sich gegenseitig ärgern. Wenn wir ein paar Dinge auflisten würden, die Nutzer ärgern, würde die eingleisige, rein technische Denkweise der Programmierer wahrscheinlich unter den Top fünf landen.

Siebter Platz: Manager, die Technik nicht verstehen

Gibt es nur wenige Beispiele dafür, dass Laien Experten führen? Ein Wort des Vorgesetzten – ob richtig oder falsch – ist immer richtig, und wir müssen gehorchen, selbst wenn es die dümmste und irrigste Entscheidung ist. Programmierer fürchten sich eigentlich nicht vor Managern, die Technik nicht verstehen; am meisten fürchten sie Manager, die Technik nicht verstehen, aber vorgeben, sie tiefgehend zu verstehen. Am ärgerlichsten ist es, wenn man die Autorität des Vorgesetzten mit fundierten Argumenten infrage stellt und der Vorgesetzte einen als Außenseiter behandelt. Seufz, wenn man an so einen Vorgesetzten denkt, kommt einem nicht nur das Fluchen, sondern auch die Lust auf, ihm eine zu verpassen.

Tatsächlich ist ein Manager nur ein Unterstützer des Teams; er sollte dem Team helfen und seine Probleme lösen, anstatt Befehle zu erteilen. Management ist wirklich einfach: Wenn du es verstehst, hilf mit, es zu tun; wenn du es nicht verstehst, vertraue deinen Untergebenen und lass sie es tun. Das Schlimmste ist ein Manager, der Technik nicht versteht und seinen Untergebenen nicht vertraut. Seufz, das ist wahrlich der Schmerz eines Programmierers.

Sechster Platz: Benutzerdokumentation

Benutzerdokumentation sollte eigentlich nicht so furchteinflößend sein. Diese Dokumente halten alle möglichen Themen im Zusammenhang mit der Software fest, die wir entwickeln. Da wir nicht wissen, über welche Computerkenntnisse unsere Benutzer verfügen, müssen wir beim Verfassen solcher Dokumente davon ausgehen, dass der Benutzer nichts weiß. Also müssen wir das umfassendste Dokument in der klarsten und schönsten Sprache verfassen. Selbst eine Copy-and-Paste-Operation muss möglicherweise in fünf oder sechs Schritte unterteilt werden; sogar eine IP-Adresskonfiguration muss Schritt für Schritt vom Startmenü aus beschrieben werden. Für Programmierer: Sie verwenden die von ihnen entwickelte Software während der Entwicklung fast täglich, und am Ende haben sie vielleicht die Nase voll davon, aber sie müssen diese Dokumente trotzdem von den einfachsten Teilen an schreiben. Natürlich ärgert sie das leicht, und wenn Programmierer solche Dokumentationen fertigstellen, kann das sehr schlechte Ergebnisse liefern. Daher sollte solche Benutzerdokumentation von speziellen Dokumentationsmitarbeitern erstellt und gepflegt werden.

Fünfter Platz: Keine Dokumentation

Wie im vorherigen Punkt erwähnt, mögen Programmierer es von vornherein nicht, Dokumentation zu schreiben, und weil technische Leute im Allgemeinen nicht besonders gut im Ausdruck und Schreiben sind, ist die Dokumentation, die sie schreiben, auch schlecht. Das kann man wahrscheinlich an der Dokumentation in der Open-Source-Community erkennen. Andererseits sind unsere lieben Programmierer am meisten von fehlender Dokumentation genervt. Natürlich ging es beim vorherigen um Benutzerdokumentation; hier sprechen wir von Entwicklungsdokumentation, wie Design-Dokumente, Funktionsspezifikationen, Wartungsdokumente und so weiter. Aber im Grunde sind sie alle gleich. Wie auch immer, einerseits mögen unsere Programmierer es nicht, Dokumentation zu schreiben; andererseits wird sich über unsere Programme beschwert, weil sie keine Dokumentation, zu wenig Dokumentation oder schwer verständliche Dokumentation haben. Heh, es scheint, als gäbe es auch beim Beschweren Rekursion. Es heißt, agile Entwicklung könne die Dokumentation in der Softwareentwicklung reduzieren; sie sagen, sie könnten Code schreiben, der wie Dokumentation und Diagramme aussieht – wer weiß, ob das stimmt. Allerdings habe ich zu viele Programmierer gehört, die sich über zu wenig Dokumentation oder schlechte Dokumentation beschweren. In dieser Hinsicht haben Programmierer es nur sich selbst zuzuschreiben.

Vierter Platz: Bereitstellungsumgebung

Obwohl Programmierer Software entwickeln, wissen wir nicht, in welcher Umgebung unser Programm bereitgestellt oder installiert wird – zum Beispiel Unterschiede in Netzwerken, Unterschiede bei RAID, Unterschiede im BIOS, Unterschiede bei Betriebssystemen (WinXP vs. Win2003), ob Antivirensoftware vorhanden ist, Kompatibilität mit anderen Programmen, ob das System Schadsoftware oder Viren enthält und so weiter. Natürlich, solange Ihre Software einen Fehler hat, ob es das Problem Ihres Programms oder das Problem der Umgebung ist, ist es alles Ihr Problem, und Sie müssen es alles lösen. Deshalb programmieren Programmierer nicht nur einfach; oft müssen sie auch ein anständiger Systemadministrator sein. Wann immer schließlich bestätigt wird, dass die Ursache des Problems die Umgebung ist, können Programmierer Groll empfinden.

Dritter Platz: Problemberichte

"Meine Software funktioniert nicht", "Das Programm hat einen Fehler". Wann immer wir solche Problemberichte hören, fühlen Programmierer immer Schmerz, denn solche Berichte sagen überhaupt nichts aus, und trotzdem müssen sich Programmierer mit dem Fehler befassen. Es gibt keine klare Problembeschreibung, keine Erklärung, wie man das Problem reproduziert, und es kann sich ein wenig anfühlen, als würde man verhört. Schlimmer noch, manchmal kommt es mit einem herablassenden, schimpfenden Ton. Natürlich sind Programmierer im Allgemeinen willensstarke Menschen, die weder auf Zuckerbrot noch auf die Peitsche reagieren, also wenn jemand ein Problem in einem solchen Ton meldet, reden sie meist zurück, und dann kommt es natürlich zu Unannehmlichkeiten. Deshalb brauchen wir immer noch eine Kundendienstabteilung, die hilft, die Kommunikation zwischen unseren Programmierern und Benutzern zu überbrücken.

Zweiter Platz: Programmierer selbst

Was Programmierer ärgert, können immer noch Programmierer selbst sein. Programmierer "verachten einander". Sie sind im Grunde arrogant und eingebildet und haben immer das Gefühl, die Besten zu sein. Unter Programmierern streiten sie sich fast jeden Tag, und wenn sie erst einmal anfangen, streiten sie sich, bis ihnen das Gesicht rot wird und der Hals anschwillt. Sie ärgern sich ständig gegenseitig.

Unterschiedliche technische Meinungen. Zum Beispiel: Linux vs. Win, VC++ vs. VB, Vi vs. Emacs, Java vs. C++, PHP vs. Ruby, und so weiter, und so weiter. Sie streiten über alles.
Erfahrene Programmierer schauen auf Neulinge herab. Es gibt immer einige Programmierer, die auf andere herabschauen, mit Arroganz und Zurechtweisung sprechen. Wenn Neulinge Fragen stellen, verhalten sich die Erfahrenen oft gleichgültig und reagieren nicht.
Sie wahren nicht das Gesicht anderer in technischen Angelegenheiten. Ich weiß nicht warum, aber Programmierer geben anderen nie Gesicht. Wann immer sie hören, dass jemand eine bestimmte Technologie missversteht, weisen sie gerne lautstark in der Öffentlichkeit darauf hin, nutzen die "Fehler" anderer, um ihre eigene "Gelehrsamkeit" zur Schau zu stellen und die "Unwissenheit" anderer zu beweisen.
Sie lieben es zu verachten. Tatsächlich ist nichts auf dieser Welt perfekt; es gibt Vor- und Nachteile, und Fehler zu finden ist zu einfach. Programmierer schauen besonders gerne auf andere herab. Egal um was es geht, sie sehen immer lieber die Schwächen anderer als deren Stärken. Ihre häufigen Sprüche sind "zu schlecht", "nicht gut" und so weiter.

Programmierer, die lange Zeit mit Computern zu tun haben, schreiben Code, den der Computer immer ernsthaft ausführt. Mit der Zeit entwickeln sie eine Persönlichkeit, die auf alles herabschaut, ohne zu erkennen, dass viele Dinge in dieser Welt nicht wie ein Computer sind, bei dem die bloße Angabe der richtigen Anweisung ihn korrekt laufen lässt. Wann werden Programmierer reif...

Erster Platz: Der Code eines Programmierers

Egal wie schön und klassisch du dein Design und deinen Code damals auch fandst, wenn du nach einer Weile zurückblickst, wirst du unweigerlich das Gefühl haben, dass du töricht warst. Wenn du natürlich den Code eines anderen warten musst, musst du seinen Code verfluchen, während du ihn wartest. Erinnerst du dich noch daran, wie stolz du dein Design und deinen Code mit anderen diskutiert und wie perfekt du sie bezeichnet hast? Doch innerhalb von zwei Jahren kann ein frisch graduierter Mitarbeiter, der deinen Code wartet, Mängel darin aufzeigen und dich völlig das Gesicht verlieren lassen. Hehe. Natürlich denken manche Leute immer, ihr eigenes Design und ihr eigener Code seien das Beste, aber das betrachtet die Dinge aus einer relativ statischen Perspektive. Die Welt der Programmierung verändert sich sehr schnell. Viele Dinge werden uns erst vertraut, nachdem wir sie getan haben, und erst nachdem wir vertraut geworden sind, wissen wir, was bessere Methoden sind – das ist ein allmählicher Prozess. Wenn du also mit den Dingen immer vertrauter wirst und zurückblickst auf die Designs und den Code, die du früher geschrieben hast, wirst du unweigerlich das Gefühl haben, wie oberflächlich und töricht sie waren. Natürlich kann es sein, dass du beim Betrachten der Designs und des Codes anderer Leute auch anfängst zu fluchen.