Der Dunning-Kruger-Effekt
Kurz gesagt: inkompetente Menschen tendieren dazu ihre und fremde Leistungen nicht (kompetent) einschätzen zu können. Daher überschätzen sie sich selbst meist, während sie andere unterschätzen.
An den eigenen Fähigkeiten zu zweifeln bedeutet also unter Umständen, dass man durchaus Kompetenz darin aufweist (vgl. auch das Imposter-Phänomen).
Larry Wall, der Erfinder von Perl, hält Faulheit, Ungeduld und Selbstüberschätzung durchaus für Tugenden beim Programmieren: Faulheit motiviert (Oxymoron?) dazu bei Programmierung, Dokumentation und Tool-Auswahl möglichst effizient zu arbeiten. Ungeduld soll dazu führen, dass man nicht nur das Benötigte erarbeitet, sondern zukünftige Anforderungen auch schon berücksichtigt. Selbstüberschätzung nimmt die Angst davor, große Projekte überhaupt in Angriff zu nehmen.
Passig und Jander sehen noch in weiteren Untugenden Vorteile: Dummheit sorgt dafür, dass der Code leichter (für Fremde) verständlich ist. Spaghetticode kann nur schreiben, wer sich viel im Kopf behalten kann. Unwissenheit hilft bei einem Paradigmenwechsel (z.B. damals hin zur objektorientierten Programmierung) flexibel zu bleiben. Wer nicht in erlernten Denkmustern verhaftet ist, tut sich leichter beim Umsteigen. Vergesslichkeit sorgt dafür, dass Code besser kommentiert und dokumentiert wird. Vielleicht erstmal nur für sich selber, aber das hilft Fremden dann wiederum den Code zu verstehen. Fehlendes Durchhaltevermögen: Code der in einer Nachtschicht zusammen geschustert wird, wird höchstwahrscheinlich eh am nächsten Tag verworfen. Eine gute/kreative Lösungsidee sollte besser reifen, bevor Code dafür geschrieben wird. Prokrastination hat den angenehmen Nebeneffekt, dass in der Zwischenzeit andere die Entwicklung voran treiben und das Problem des prokrastinierenden Programmierers von einem Kollegen oder der Community bereits gelöst ist. Auch entwickeln sich die Tools und man selber weiter, so dass am ende vielleicht eine schnellere und bessere Lösung herauskommt (vgl. TED-Talk von Adam Grant und meine Anmerkungen dazu). Ekel vor dem eigenen Code ist gut, weil man ihn bereitwilliger verwirft, wenn sie entweder die Anforderungen ändern, oder andere (erfahrenere/bessere) Kollegen ins Boot kommen. »Wer seinen Code für perfekt hält, lernt zu wenig dazu. Die Zusammenarbeit mit anderen ist produktiver, wenn die Beteiligten nicht in ihren eigenen Code verliebt sind.« Ehrgeizlosigkeit: sogenannte Maximizer, also Programmierer die nach dem besten streben, sind laut Glückforschung nicht so glücklich wie Satifsicer, die sich auch mit weniger zufrieden geben. Trägheit kann man umkehren, und so kann sie helfen guten Code zu schreiben. Als Beispiel: globale Variablen (Warum die nicht so gut sind). Wenn immer nur lokale Variablen genutzt werden, verhindert die Trägheit, dass globale eingeführt werden.