Die Wissenschaft des Impostorphänomens in der Softwareentwicklung: Warum es mehr als Selbstzweifel ist

TESTE_DICH · Wie gut kennst du diese Forschung?

1. 01 Pauline Clance und Suzanne Imes prägten 1978 den Begriff 'Impostorphänomen', um was zu beschreiben?

   Eine klinische Störung, die nur Menschen mit geringer tatsächlicher Fähigkeit betrifftLeistungsstarke Personen, die trotz Erfolgsbelegen glauben, Betrüger zu sein, und Angst haben, entlarvt zu werdenEine bewusste Selbstbehinderungsstrategie zur ErwartungssteuerungÜbermäßiges Vertrauen in die eigenen Fähigkeiten im Vergleich zu Gleichaltrigen

   Clance und Imes beschrieben ein Muster bei leistungsstarken Personen, die trotz objektiver Kompetenzbelege ihren Erfolg intern eher auf Glück oder Täuschung als auf Fähigkeit zurückführen — und dauerhaft fürchten, als Betrüger entlarvt zu werden. Quelle ↗

2. 02 Was sagt uns der Dunning-Kruger-Effekt über die Beziehung zwischen Fähigkeitsniveau und Selbsteinschätzung der Kompetenz?

   Hochkompetente Personen schätzen ihre Fähigkeiten konsistent und genau einFähigkeitsniveau ist unabhängig von selbst eingeschätzter KompetenzGeringkompetente überschätzen ihre Kompetenz, während Hochkompetente ihre oft unterschätzenNur Personen in ihrem ersten Berufsjahr schätzen ihre Kompetenz systematisch falsch ein

   Kruger und Dunning fanden eine systematische Asymmetrie: Leistungsschwache überschätzen ihre Kompetenz (ihnen fehlen die metakognitiven Fähigkeiten, die eigenen Lücken zu erkennen), während Leistungsstarke ihre unterschätzen — was Impostorzweifel bei höheren Fähigkeitsniveaus häufiger, nicht seltener macht. Quelle ↗

3. 03 Was identifizierte Googles Project-Aristotle-Forschung als den einzeln stärksten Prädiktor für die Effektivität von Ingenieurteams?

   Durchschnittliches Senioritätsniveau der TeammitgliederPsychologische Sicherheit — die Überzeugung, interpersonelle Risiken ohne Strafe eingehen zu könnenGemeinsamer physischer Standort in einem BüroAnzahl der Jahre, die das Team zusammengearbeitet hat

   Project Aristotle analysierte 180 Google-Teams und fand, dass psychologische Sicherheit — ob Teammitglieder sich sicher fühlten, Risiken einzugehen und voreinander verletzlich zu sein — jede andere Variable, einschließlich Talentlevel, als Prädiktor für Teamleistung und -effektivität übertraf. Quelle ↗

4. 04 Was fand Lee et al.'s Studie von 2024 über Code-Review-Angst bei Softwareentwicklern?

   Sie ist nicht von allgemeiner sozialer Angst zu unterscheiden und hat keinen spezifischen IngenieurkontextSie betrifft nur Ingenieure in ihrem ersten Jahr, die noch keine Glaubwürdigkeit aufgebaut habenSie ist ein messbares, eigenständiges Konstrukt, das mit Vermeidungsverhalten assoziiert und signifikant mit dem Impostorphänomen korreliert istSie verschwindet, sobald Ingenieure positives Review-Feedback ansammeln

   Lee et al. fanden, dass Code-Review-Angst von allgemeiner sozialer Angst unterscheidbar, mit Umfrageinstrumenten messbar ist, Vermeidungsverhalten wie das Verzögern der Code-Einreichung vorhersagt und signifikant mit Impostorphänomen-Werten korreliert — was sie zu einem spezifischen beruflichen Stressor macht, nicht nur allgemeiner Nervosität. Quelle ↗

5. 05 Was hat die ICSE-SEIS-2024-Studie von Guenes et al. über das Impostorphänomen in der Softwareentwicklung festgestellt?

   Es ist selten und betrifft hauptsächlich Entwickler, die aus fachfremden Bereichen umgestiegen sindEs wird nur dann zum Problem, wenn Ingenieure Aufgaben jenseits ihres aktuellen Fähigkeitsniveaus zugewiesen bekommenEs ist bei allen Senioritätsstufen, Teamgrößen und Bildungshintergründen verbreitet — ein Berufsmuster, keine individuelle EigenheitEs ist am häufigsten bei Ingenieuren, die remote ohne tägliche Standups arbeiten

   Die Studie von Guenes et al. 2024 auf der ICSE-SEIS war die erste groß angelegte empirische Messung des Impostorphänomens speziell bei Softwareentwicklern, die es über Senioritätsstufen, Teamgröße und Bildungshintergrund hinweg fand — was strukturell verankerte, was oft als individueller Selbstzweifel behandelt worden war. Quelle ↗