Ego-Programmierer schaden dem Team v.a. langfristig. Kurzfristig mögen sie dem Team erstmal Beschleunigung verschaffen, weil sie gewisse Programmierfertigkeiten besitzen und erstmal Probleme lösen. Langfristig muss ein Team diese kurzfristige Erleichterung aber teuer bezahlen, weil der Ego-Programmierer die technische Schuld der Codebase mit schwer bis gar nicht verständlichem Code erhöht. Wie aber erkenne ich solche Ego-Progammierer? Folgende Checkliste speist sich aus teuer erkaufter Erfahrung:

Dem Ego-Programmierer genügt es nicht, die Realität einfach abzubilden, weil das seine lächerlichen Kollegen auch gerade noch so hinbekommen. Erst durch zusätzliche möglichst abstrakte Entitäten mit Namen wie IntermediatorFactory, TransactionalBuilderObject, ConnectionSingleton, CompositeAdapterClass, ServiceMediatorController, usw. läßt es sich vom Programmierpöbel abheben. Ohne die Gang of Four fehlte ihm die Rechtfertigung eine verständliche Codebase in SEINE Codebase zu verwandeln. 

Schreibt ein durchschnittlicher Programmierer aus Zeitmangel oder 14-Uhr-Loch-Blut-Im-Hirn-Mangel schwerverständlichen Code, entschuldigt er sich bei Dir. Nicht so der Ego-Programmierer: er grinst dich blöd an. Und mit blöd meint er dich.

Der Ego-Programmierer packt möglichst viele Gedankengänge in eine Codezeile – weil er’s kann.

Der Ego-Programmierer verwendet häufig Abkürzungen als Bezeichner, weil nur Anfänger sprechende Namen benutzen.

Während sich die Welt schon mit 3 Schichten geschlagen gibt, läuft der Ego-Programmierer erst zur Höchstform auf, wenn sein Debugger auf einem Call-Stack mit 20+ Schichten anhält.

Der Ego-Programmierer schreibt weder Kommentare noch eine Dokumentation, weil’s einfach vor dem Chef nicht gut rüberkommt, wenn die Urlaubsvertretung auch etwas hinbekommt.

Der Ego-Programmierer denkt gar nicht daran, alles Überflüssige wegzulassen – er hat nun mal geniale Gedanken, die sich irgendwie im Code spiegeln müssen …