Gibts ne Lösung außer sich nen anderen zum Testen suchen?

Nein.
Wenn du etwas für andere als dich entwirfst, dann müssen es auch andere als du testen.

Daher hilft nur Fuzzi-Testing (also Daten (auch sehr ungewöhnliche) generieren lassen und durch das Programm schicken) und natürlich irgend welche Leute her zerren, vor das Programm setzen und beobachten was die machen.

Wenn man ein Programm geschrieben hat und es das macht, was man will, wenn man es mit den richtigen Daten füttert, dann ist man erst mal zufrieden.

Das ist schon der falsche Ansatz. Beim Testen sollte man nicht versuchen zu zeigen, daß as Programm mach was man will sondern um jeden Preis versuchen Wege zu finden das es Dinge macht die man _nicht_ will. Und man sollte sich erst zufrienden geben wenn man tatsächlich Fehler gefunden hat, denn per Theorie gibt es keine fehlerfreie Software

Oder um es mit einem Zitat aus Murphies Law zu sagen:

If everything seems to be goign well, you obviously dont know what the hell is goign on.

Das hat nichts mit Psychologie zu tun. Da du das Programm programmiert hast, weißt du wie du es zu bedienen hast.

Das hat sehr viel mit Psychologie zu tun, dazu gibt's sehr interessante Fallstudien, gängig kennt man das auch als "Betriebsblindheit". Natürlich spielt der von Dir genannte Effekt der "postiven Erwartungshaltung" auch eine Rolle, aber es geht etwas tiefer.

Lemma daraus: ein Programmierer eines Moduls/Programms ist der schlechtestmögliche Tester für dieses Modul/Programm. Jede x-beliebige andere Person ist besser geeignet.

XP nutzt diesen Effekt sogar konstruktiv aus (Pairprogramming dient ja gerade der Abstellung dieser Blindheit mit einer sehr kurzen Regelschleife, also sofortigem Eingriff).

Es hat zum Teil damit zu tun, daß man in der Tat die eigene Konstruktion nicht beschädigen will, und bei eigenen Schwächen nun mal selbst gerne ein Auge zudrückt - man weiß um die Schwäche einer Lösung, und testet dort nachsichtiger. Ein Außenstehender kennt das gar nicht, und bohrt daher gnadenlos in den Wunden herum.

Ganz allgemein empfehle ich dazu - im Sinne von Selbsterkenntnis ist der beste Weg zur Besserung:

Die Psychologie des Programmierers | ISBN: 3826614658

Auch wenn dieses Buch über die Thematik des Testens hinaus geht, werden diese und ähnliche Probleme behandelt.

Es hat zum Teil damit zu tun, daß man in der Tat die eigene Konstruktion nicht beschädigen will, und bei eigenen Schwächen nun mal selbst gerne ein Auge zudrückt - man weiß um die Schwäche einer Lösung, und testet dort nachsichtiger. Ein Außenstehender kennt das gar nicht, und bohrt daher gnadenlos in den Wunden herum.

Dem kann ich nur zustimmen. Eines der größten Probleme mit Programmierern im allgemeinen ist, daß viele es persönlich nehmen wenn man behauptet "Ihr" Code habe Fehler. Allein die Andeutung wird bereits als Beleidigung ausgelegt. Aus der selben Geisteshaltung heraus brauchen sie "Ihren" Code ja auch nicht richtig zu testen, denn sie wissen ja genau was er tut...

Ich kann mich an Situationen erinnern wo ich Tage gebraucht habe um einen anderen Programmierer davon zu überzeugen, daß sein Code tatsächlich ein Problem erzeugte. Erst als ich es ihm sozusagend schwarz auf weis beweisen konnte war er dann bereit den Fehler mal genauer anzsuchauen udn siehe da, 10 Minuten später war er sogar beseitigt... Ich weis noch genau was er sagte: "Der Code ist getestet, der macht kein memory leak." (es war ein memleak so groß wie ein scheunentor, im Schnitt 400 MB innerhalb weniger Stunden)

Ich denke, wenn man ein wirklich guter Programierer werden will, muß man zwei Dinge überwinden:

- Man muß akzeptieren das man Fehler macht und sich darauf konzentrieen, diese Fehler zu finden anstatt sich darauf zu konzentrieren selbige zu leugnen und zu vertuschen.

- Man muß aufhören Kitik am Sourcecode als persönlichen Angriff auf sich selbst zu betrachten. Vielmehr ist Kritik der Katalysator für die persönliche Weiterentwicklung.

Ich denke erst wenn man beginnt die eigenen Fehler zu akzeptieren und in Folge dann daran arbeitet diese wirklich zu beseitigen, und damit meine ich auch die Fehler in den eigenen Denkstrukturen, erst dann kann man ein wirklich guter Programmieer werden.

Katzen hüten | ISBN: 3826613260

Bißchen leichter zu lesen.

- Man muß aufhören Kitik am Sourcecode als persönlichen Angriff auf sich selbst zu betrachten. Vielmehr ist Kritik der Katalysator für die persönliche Weiterentwicklung.

Das ist auch ein sehr schwieriger Punkt für Team- oder Projektleiter, da es meistens eine Person im Team gibt, die das überhaupt nicht verträgt. Hier im Falle von Fehlern das richtig einzubringen, ohne daß diese Person gleich beleidigt oder eingeschnappt ist, ist nicht immer einfach.