Mach dir keine Sorgen. Unterschiedliche Menschen haben unterschiedliche Hintergründe, unterschiedliche Arten der Analyse und Untersuchung von Problemen. Menschen haben unterschiedliche Erfahrungen und ein Problem ähnelt möglicherweise einem anderen, das sie in der Vergangenheit gelöst haben.

Was können Sie dagegen tun? Seien Sie froh, dass es gefunden wurde, und sehen Sie, ob Sie vom anderen Teammitglied erfahren können, welche Denkprozesse hinter der Lösung dieses Problems stecken.

Verwenden Sie dies als Lernerfahrung, nicht als Erfahrung, bei der Sie "weniger gut" sind als Ihre Teammitglieder. Vergessen Sie nicht, dass Sie höchstwahrscheinlich in etwas anderem besser sind, weshalb Sie dem Team einen Mehrwert verleihen.

Willkommen zu meinem Arbeitstag. Einige Probleme sind einfach, andere schwierig, andere finden Sie sofort, andere dauern Wochen. Ich verstehe deinen Stress, wie ich ihn auch leide. Es macht keinen Spaß, jeden Tag aufzustehen und zu sagen, ja, ich bin immer noch auf diesem Fehler, kein Fortschritt ... . Sie fühlen sich nach 2-3 Tagen ein bisschen dumm.

Hier ist meine persönliche Formel, um darüber hinwegzukommen.

1. Machen Sie sich Notizen. Schreiben Sie Ihre Theorien auf (kommentieren Sie das Ticket) und wie Sie sie testen möchten.
2. Bitten Sie um Hilfe. Sprechen Sie mit Ihren Teamkollegen / Führungskräften und holen Sie sich deren Input, damit alle wissen, dass es sich um ein komplexes Problem handelt, und niemand zweifelt an Ihnen, wenn Sie es nicht lösen können. _{Hinweis: Sie zweifeln sowieso nicht an Ihnen. Es ist genau das, was ich mir sage sub>}
3. Wissen, wann ich es nach oben treten muss. Dokumentieren Sie Ihre Theorien / Ergebnisse und bitten Sie Ihr Team oder Ihren Scrum-Meister, diesmal formell, um Hilfe.
ol>

Dies ist ein Problem, das Sie angehen müssen.

Sie haben das Gefühl, dass etwas nicht stimmt, wenn sich herausstellt, dass jemand außer Ihnen ein Problem löst oder jemand anderes als Sie. Das Beste unter bestimmten Umständen ist ein emotionales Problem, das Ihnen im späteren Leben Probleme bereiten wird, wenn Sie es nicht ansprechen.

Wenn Sie so reagieren, werden Sie Probleme bekommen, weil Sie unnötigen Stress haben Bemühen Sie sich, mit irgendjemandem und jedem zu konkurrieren (von denen einige von Natur aus besser sind als Sie, was auch immer Sie konkurrieren), um die echten Bemühungen anderer nicht zu würdigen, um tatsächlich nicht zusammenzuarbeiten, während Sie sich gegen Ihre Kollegen bemühen, die zu sein am besten.

Ich würde darüber keinen Schlaf verlieren, besonders wenn niemand Ihre Fähigkeiten in Frage stellt. Sehr oft können Sie beim Debuggen so tief in einen Pfad vordringen, dass Sie für andere Probleme die Perspektive verlieren. Dies liegt daran, dass man sich so sehr auf die Untersuchung konzentriert. Manchmal bringt ein Schritt zurück oder ein Blick von jemand anderem eine neue Perspektive und der Fehler wird identifiziert. Dies ist keine Schwachstelle, sondern tritt häufig bei Entwicklern auf.

Dies ist eine Debugging-Strategie namens Rubber Duck Debugging, die hilfreich sein kann. Manchmal kann eine reale Person für die Ente eintreten und helfen, das Problem aus einem anderen Licht zu betrachten. Am Ende geht es darum, den Fehler zu beheben und das Team vorwärts zu bringen. Früher oder später werden Sie derjenige sein, der den Fehler eines anderen löst. Fühle dich jetzt nicht schuldig.

Wenn ich es dem breiteren Team vorstelle, ist jemand hereingekommen und hat ziemlich schnell mehr Kontext entdeckt, der sich dann den Punkten anschließt und das Problem löst.

Ich finde es schwierig, damit umzugehen Dies ist emotional, weil mein Ego mir sagt, ich hätte es lösen sollen.

Es scheint, dass Ihr primärer verinnerlichter Grund dafür die Arbeit ist, dass Sie sich unter Ihren Kollegen erreicht fühlen, anstatt das Problem zu lösen verfügbar. Dies ist eine Einstellung, für die in einem technischen Team wenig Platz ist.

Wenn Sie sich wirklich hauptsächlich um die Problemlösung kümmern, wären Sie froh, dass jemand die Lösung gefunden hat und kein Problem damit hat, dass dies nicht der Fall ist Sie nicht.

Stellen Sie sicher, dass Ihre menschlichen emotionalen / gesellschaftlichen Bedürfnisse außerhalb der Arbeit erfüllt werden, damit Sie diese Notwendigkeit während einer Debugging-Sitzung nicht haben.

Und Ich denke, andere Leute im Team müssen weniger an mich denken, weil sie es nicht gelöst haben.

Dies sind wahrscheinlich Sie, die Ihre eigenen Gedanken widerspiegeln. Zumindest macht ein schlechtes Debuggen Sie nicht zu einem schlechten Menschen ... nur zu einem schlechten Debugger. (Und ich sage nicht, dass Sie ein schlechter Debugger sind ... nichts in Ihrer Frage weist tatsächlich darauf hin.)

Wir haben diese Art von emotionalen Reaktionen aus einem bestimmten Grund, aber nichts davon ist hilfreich, wenn Es geht um logisches Denken und pragmatische Problemlösung im Ingenieurwesen. Lassen Sie Ihren Verstand nicht auf diesen Wert zurückgreifen. Verbringen Sie die Zeit damit, Dinge zu tun, die Ihnen helfen, diese Probleme in Zukunft zu verstehen, z. B.:

• Verstehen Sie vollständig, was schief gelaufen ist
  Verstehen Sie was vollständig? aus technischer Sicht in der Situation vor Ihnen falsch gelaufen? Wenn nicht, nutzen Sie dies als großartige Lernmöglichkeit, um alle verbundenen Systeme, auf denen das Problem aufgetreten ist, vollständig zu verstehen. Sie werden in Zukunft gut darin sein, ähnliche Dinge zu entdecken.
• Vorurteile beim Debuggen verstehen
  Hat Sie die Überprüfung nicht verwandter Systeme oder die Übergewichtung der Wichtigkeit bestimmter Fakten von anderen Informationen geblendet, die Ihre Mitarbeiter dazu veranlassen, das Problem früher zu finden? Beim Debuggen wird häufig Tunnelblick angezeigt, insbesondere bei einem System, das Sie tatsächlich sehr gut kennen. Ein komplexes System kann Symptome auf ein komplexes Problem auslösen, das Sie zuvor gesehen haben. Das eigentliche Problem kann jedoch darin bestehen, dass jemand in einem Rechenzentrum über ein Netzkabel stolpert Problem
  Zerlegen Sie alles als Problem / Lösung. Bearbeiten Sie Probleme schnell, testen Sie Hypothesen, machen Sie keine Annahmen und stellen Sie fest, dass Sie keine Zeit haben, sich Sorgen zu machen, während Sie das Problem bearbeiten. Wenn Sie den Stress und die menschliche Natur aus Ihrer Debugging-Arbeit entfernen, werden Sie effektiver und werden hoffentlich feststellen, dass Sie am Ende nichts zu befürchten hatten. Zögern Sie auch nicht, Ihren Manager für denselben Denkprozess zur Rechenschaft zu ziehen. Ein Manager, der an Ihrem Schreibtisch steht, um emotionalen Druck auf Sie auszuüben, während Sie etwas Kritisches reparieren, ist ein Manager, der nur dafür gesorgt hat, dass die Lösung mindestens viermal langsamer ist. Sagen Sie einem solchen Manager, er soll unverblümt gehen.

Nachdem das Problem gelöst ist, denken Sie daran, dass wir alle Menschen sind und den Erfolg / Misserfolg von was annehmen du machtest. Aber tun Sie es im Kontext des Problems selbst und bringen Sie nicht Ihren Selbstwert ein. Wenn Sie sich für etwas auf sich selbst einlassen möchten, tun Sie dies, um Emotionen nicht von Dingen entfernen zu können, die keine Emotionen erfordern. Dies ist eine Fähigkeit, deren Erlernen lange dauert und für einige sehr schwierig ist. Wenn es für Sie problematisch ist, ist das in Ordnung , kann es nur mehr Übung erfordern.

Wenn Sie immer noch Zweifel haben, bringen Sie morgen eine Schachtel Donuts für Ihr Team mit. Alle kleinen Streitereien werden sofort gelöst. :-)

Mit mehr Erfahrung kommt mehr Weisheit. Es ist wahrscheinlich, dass die andere Person zuvor ein ähnliches Problem hatte.

Es gibt auch das eigentliche Problem, dem Problem "zu nahe" zu sein. Sie haben so lange auf dasselbe gestarrt, dass Sie zum Beispiel nicht einmal das fehlende Semikolon sehen können. Ich habe stundenlang an Dingen gearbeitet, nur um zu erkennen, dass ich das Gleichheitszeichen durch einen Doppelpunkt ersetzen musste, weil es ein anderer Kontext war. Und umgekehrt.

Wie fühlen Sie sich nicht schlecht dabei? Nun, zuerst fühlst du dich schlecht. Das ist einfache menschliche Natur. Sie wurden von der Schule, den Eltern, dem Einzelhandel und vielen anderen Dingen programmiert, um zu glauben, dass Sie beim ersten Mal immer die richtige Antwort haben müssen. Die "reale Welt" funktioniert so nicht, besonders wenn es um Computer geht. Der durchschnittliche Programmierer fällt öfter aus, als er erfolgreich ist. Dies beruht auf der einfachen Idee, dass Sie eine Aufgabe nur einmal erfolgreich ausführen, sie jedoch viele Male und auf viele verschiedene Arten scheitern können, bevor sie schließlich funktioniert. Und selbst dann gibt es wahrscheinlich einen besseren Weg, dies zu tun. (Ich kann diese Antwort nicht einmal eingeben, ohne meine Rechtschreibung und Grammatik korrigieren zu müssen.)

Je länger Sie diese Art von Arbeit ausführen, desto mehr werden Sie feststellen, dass es nicht Ihr Fehler ist, sondern nur ein weiteres Experiment nicht 100% korrekt sein. Sie lernen, Ihre Fehler zu beseitigen und weiterzumachen. Ich finde, wenn Leute auf etwas hinweisen, das ich vermisst habe, bin ich erleichtert. Ich muss meinen Kopf nicht mehr gegen das Problem schlagen. Ich fühle mich manchmal immer noch dumm, weil ich das zusätzliche Komma in meiner -Liste nicht bemerkt habe, aber ich behebe das Problem und vergesse meinen Fehler. Ich versuche mich nur an die Lösung zu erinnern, damit ich nicht noch einmal den gleichen Fehler mache.

Als Junior habe ich Lösungen gefunden, die Senioren nicht finden konnten. Ich habe Aufgaben in 1/4 der Zeit erledigt, die andere haben. Ich habe auch Tage damit verbracht herauszufinden, warum mein JSON nicht funktioniert, wenn ich " anstelle von ' hätte verwenden sollen. Grrr!

Ich lerne seit über 25 Jahren Programmieren und bin seit ungefähr 7 Jahren ein Profi. Ich lerne immernoch. Ich lerne neue Methoden, um Funktionen auszuführen, saubereren Code zu schreiben, wie man Code besser debuggt und wie das, was meiner Meinung nach am besten funktioniert, für manche Menschen keine Rolle spielt.

Der Schlüssel ist, sich nicht zu verprügeln. " Ausfälle ", da es sich wahrscheinlich nicht um Ausfälle handelt. Es kann eine Weile dauern, bis man lernt, wie man es nicht persönlich nimmt, aber glauben Sie mir, es ist normalerweise nicht persönlich. Selbst wenn dich jemand beschuldigt, ist es wahrscheinlich sein Ego, das du gerade beleidigt hast, anstatt dass es deine Schuld ist. Nun, es sei denn, es ist wirklich deine Schuld, aber diesmal ist das nicht der Fall.

Und manchmal brauchst du nur ein wenig Zucker, damit du dich besser fühlst. Iss einen Keks und beruhige dich ein wenig. Yum, Schokoladenstückchen ..... ;-)

Es hat mir sehr geholfen zu verstehen, dass es oft nur von Zufall und Glück abhängt, wie lange es dauert, die Grundursache eines Fehlers zu finden.

Es gibt so viele verschiedene Gründe für Fehler und es gibt sie viele verschiedene Tools und Techniken, um Fehler aufzuspüren. Stellen Sie sich vor, jemand kommt in ein Büro und sagt, dass mit einem Server etwas nicht stimmt. Oft ist die Beschreibung des Problems ziemlich vage.

• Möglicherweise versucht jemand, den Fehler zuerst auf dem Server oder auf seinem lokalen Entwicklungscomputer zu reproduzieren.
• Es kann hilfreich sein, die Protokolldateien des Servers zu überprüfen und zu analysieren.
• Ein anderer Entwickler greift möglicherweise in den Quellcode ein und liest ihn Zeile für Zeile.
• Oder Sie haben ein Tool zur Benachrichtigung über Ausnahmen, das Sie möglicherweise in die richtige Richtung weist
• Und dann gibt es den Entwickler, der in der letzten Woche gerade in diesem Bereich der Codebasis gearbeitet hat oder der am Tag zuvor einen Blog-Artikel über einen seltsamen Fehler in einer externen Bibliothek gelesen hat.

Es gibt so viele verschiedene Möglichkeiten, wie man sucht und wie man Fehler findet. Manchmal kann der eine oder andere Weg schneller oder sogar offensichtlicher sein. Aber einen Fehler in kürzerer Zeit als andere zu finden, ist einfach ein Glücksfall.

Ich bin sicher, dass Sie den Fehler auch gefunden hätten. Es hätte nur ein bisschen länger gedauert. Du bist in die falsche Richtung gegangen, aber das ist normal und in Ordnung. Denn erst nachdem Sie den Fehler gefunden haben, wissen Sie, welche Richtung die richtige war.

Es geht nur um Bauchgefühl und viel um Glück.

Ich denke, was Ihnen dabei helfen könnte, dies zu überwinden, ist eine subtile Anpassung Ihrer Einstellung zu den Projekten, an denen Sie arbeiten. Sie sagten, dass Sie unglücklich sind, wenn Sie die Grundursache eines Fehlers nicht finden. Dies deutet darauf hin, dass Sie ein Gefühl der persönlichen Eigenverantwortung für den Code haben, an dem Sie arbeiten.

Im Gegensatz dazu fand ich es hilfreich, den Code als zu jedem gehörend zu betrachten Das Team. Es gibt keinen Code, den I geschrieben hat. Sobald der Code mein Gehirn verlässt und in meinem Editor abgetippt wird, ist es Code, den wir geschrieben haben. Wenn jemand darauf hinweist, wie ich es sauberer oder korrekter hätte schreiben können, ist dies kein Angriff auf meinen Code, sondern eine Chance, unseren Code so viel besser zu machen. Und wenn ein Fehler gefunden wird, verschwende ich keine Zeit damit, mir Gedanken darüber zu machen, wessen Code den Fehler verursacht hat oder wer den Fehler letztendlich behebt. Es ist ein Problem in unserem Code, und es ist ein Gewinn, wenn wir es beheben.

Ich habe festgestellt, dass dies mir wirklich hilft, viel glücklicher zu sein Erfahrung beim Codieren! Es bedeutet, dass ich keine Zeit damit verbringe, auf jemanden herabzuschauen, wenn jemand anderes etwas kaputt macht. Es liegt ebenso in meiner Verantwortung wie in ihrer, und ich bin glücklich, mit ihnen einzutauchen und es zu reparieren. Es bedeutet, dass wenn ich etwas kaputt mache, ich es selbst nicht zu sehr schwitze! Ich weiß, dass meine Mitarbeiter die gleiche Einstellung haben wie ich, daher können wir alle das Problem lösen, ohne mit den Fingern zu zeigen.

Das bedeutet, wenn ich ein schwieriges Projekt beende, wie das Beheben eines dornigen Fehlers Ich bekomme kein aufgeblasenes Ego. Es war ein Projekt, das wir erfüllen mussten, und wir alle gewinnen jetzt, da es abgeschlossen ist. Und wenn ein Teamkollege eine beeindruckende Arbeit beendet, wird ich nicht eifersüchtig und versuche nicht, seinen Erfolg herunterzuspielen. Wieder ist es ein Sieg für uns , und ich kann ihnen gratulieren und stolz darauf sein, mit ihnen zusammenzuarbeiten, ohne mir Sorgen machen zu müssen, mich mit ihnen zu vergleichen.

Wenn Sie diese Einstellung einnehmen und lange Zeit versuchen, einen Fehler nur für eine andere Person zu finden, um ihn schnell zu beheben, werden Sie sich nicht schlecht fühlen, wenn Sie Ihren Fehler nicht lösen. Sie werden froh sein, dass das Team den Fehler behoben hat, und Sie werden auch Teil dieses Sieges sein. Wenn Sie Teil eines gesunden Teams sind, haben Ihre Mitarbeiter diese Einstellung bereits und sehen nicht auf Sie herab, weil Sie keine Punkte gesammelt haben. Sie sind froh, dass Sie sich einschalten, um nach besten Kräften bei den Fehlern zu helfen.

Für mich ist die Antwort jedoch dieselbe.

Gewöhne dich daran.

Ich bezeichne dies als Müdigkeitssyndrom und habe mit allen meinen Teammitgliedern darüber gesprochen.

Immer wenn jemand längere Zeit über ein Problem gerätselt hat und ich in ein paar Minuten vorbeischaue und es löse und er sich selbst treten will, erinnere ich ihn daran, dass mir genau dasselbe passiert .

Unterschätzen Sie niemals ein neues Augenpaar. ob Sie eine Pause machen oder eine neue Person mit einer neuen Perspektive. Machen Sie es sich zur Gewohnheit, Teamkollegen einzubeziehen, wenn Sie eine Weile an einem Problem festhalten. Es ist großartig, Hilfe von jemandem mit mehr Erfahrung zu erhalten, aber ich habe weniger erfahrene Entwickler gebeten, meinen Code oft dort anzusehen, wo er sich ausgezahlt hat, und ich habe Entwickler mit weitaus mehr Erfahrung als ich aus vielen Löchern herausgegraben. Manchmal sind Sie so in ein Problem verwickelt, dass Sie nicht sehen können, was direkt vor Ihnen liegt (googeln Sie einfach "Code Blindness").

Zwei Ratschläge, um den Prozess der Gewöhnung an dieses zu beschleunigen:

Machen Sie Pausen - oft und für eine Weile, idealerweise an etwas anderem das macht dir den Kopf frei

Bug einander - frag jemanden, was du gerade arbeitest - "Vermisse ich hier etwas oder was?" hat mir viele Stunden sinnlosen Durcheinander erspart - und wenn ein Mitarbeiter mehr als sonst auf seinen Bildschirm flucht, fragen Sie, was das Problem ist. Oft lösen Sie (oder sie) das Problem nur, indem Sie es erklären müssen (warum so viele Entwickler eine Gummiente haben). Daher lohnt es sich fast immer, sich Zeit zu nehmen, um ein Problem zu erklären auch dort, wo sie (oder Sie) nicht helfen können.

Was mir am meisten geholfen hat, war, als ich anfing, öfter auf der anderen Seite des Gesprächs zu sein und zu erkennen, wie oft ich die Antwort nur aufgrund eines Zeitmangels schnell finden konnte.

Ich Ich kann Ihnen nicht sagen, wie oft ich tagelang mit einem Problem zu kämpfen hatte, es schließlich gelöst habe. Ein paar Wochen später bittet jemand um Hilfe bei einem sehr ähnlichen Problem. Mit anderen Worten, Ihre Mitarbeiter sind im Allgemeinen nicht schlauer als Sie, sie haben nur einen Vorsprung.

Ein wichtiger Grund, warum ich jetzt einen Vorsprung habe, ist, dass ich schneller um Hilfe bitte und fahren Sie mit dem nächsten Schritt fort. Das heißt, anstatt lange mit einem Problem zu kämpfen, das mir jemand anderes schnell lösen könnte, verbringe ich die meiste Zeit damit, an Problemen zu arbeiten, die meine Mitarbeiter auch noch nicht lösen können.

Sie sind Teil eines Teams und das Team hat gerade getroffen ! Freut euch!

Sie waren nicht die letzte Person am Ball, aber Sie haben den letzten Pass gemacht. Als Sie dem Team das Problem beschrieben haben, haben Sie ihm genau das gegeben, was er zur Lösung des Problems benötigt. Du hast es gut gemacht!

Viele dieser Antworten sind wirklich großartig. Die Konzentration auf die Teamarbeit ist hier wirklich entscheidend. Und die Lernkurve hört bei keinem Projekt wirklich auf.

Ich bin jetzt seit fast 3 Jahren in meiner jetzigen Position. Ich habe mich am Anfang oft genauso gefühlt wie du. Ich bin auf einen Fehler gestoßen, habe nach Stunden / Tagen gesucht, nur um zu sehen, dass mich jemand anderes nach 3 Minuten Einchecken in die richtige Richtung weist.

Aber im Laufe der Zeit kommen Fehler und Fehler Geh, ich bin immer mehr in der Lage, diese Person selbst zu sein. Mit zunehmendem Wissen über das Projekt habe ich immer mehr Möglichkeiten, meinen Kollegen auf die gleiche Weise zu helfen, wie sie mir geholfen haben (und mir immer noch helfen).

Das ist also mein Rat. Versuchen Sie, sich so oft wie möglich in eine Position zu versetzen, in der Sie der Helfer sein können. Es spielt keine Rolle, dass die Leute Ihnen helfen müssen, wenn Sie sicher sind, dass es bald die Möglichkeit gibt, dasselbe für sie zu tun.

Mein Ego sagt mir, ich hätte es lösen sollen. Und ich denke, andere Leute im Team müssen weniger an mich denken, weil sie es nicht gelöst haben.

Es ist wirklich gut, dass Sie die Überzeugungen hinter Ihren Gefühlen reflektiert und identifiziert haben. Sie entwickeln dort gute Selbstbewusstseinsfähigkeiten. Es könnte sich lohnen, diesen Prozess etwas weiter voranzutreiben. Warum denkst du, hättest du es lösen sollen?

• Ist es nur Ego - denkst du, du bist der beste Insektenjäger, der die Ursache für jeden Fehler in kurzer Zeit findet?
• Haben Sie das Gefühl, dass es in Ihrer Verantwortung liegt, einen Fehler zu beheben, wenn Sie ihn einmal zugewiesen bekommen?
• Haben Sie das Gefühl, dass Ihnen der Fehler nicht zugewiesen worden wäre, wenn Sie es nicht gewesen wären? Am besten positioniert, um die Lösung zu finden

Sobald Sie das Gefühl haben, Ihre Gefühle und Überzeugungen identifiziert zu haben, besteht die nächste Herausforderung darin, zu versuchen, sie anders zu betrachten. Das ist auch nicht einfach! Aber sobald Sie sich über die Wurzeln Ihrer Überzeugungen im Klaren sind, können Sie versuchen, andere Wege zu finden, um über die Situation nachzudenken (andere Leute zu fragen ist auch hier in Ordnung!) Und zu sehen, ob sie auch wahr klingen. Zum Beispiel:

• Ich bin nicht der beste Insektenjäger, den die Welt je gesehen hat, und das ist in Ordnung. Es gibt nur einen Platz für das Beste und es sind buchstäblich Millionen von Programmierern im Rennen. Ich habe immer noch beträchtliches Fachwissen und Erfahrung, bin fleißig und hartnäckig und lerne aus jedem Fehler.
• Ich muss nicht jeden Fehler selbst beheben. Wir sind ein Team und unser Ziel als Team ist es, die Unternehmensziele zu fördern. Wir tun dies schneller und effizienter, wenn wir nur wenig Zeit benötigen, um knifflige Fehler auszutauschen, falls jemand anderes einen Einblick hat, der sie schneller lösen kann.
• Die Manager, die Arbeit zuweisen, wissen nicht, was Die Ursache für Fehler ist - wenn ja, wären sie bereits behoben. Es gibt keine Möglichkeit zu wissen, wer am besten in der Lage ist, das Problem im Voraus zu beheben. Wenn ich also Probleme habe, es festzuhalten, ist es sinnvoll, andere Personen zu fragen.

Auf die Gefahr hin, zu auf der Nase zu sein, ähnelt der gesamte Prozess ein bisschen der Fehlersuche. Sie beginnen damit, Ihre möglicherweise komplizierten Gefühle und Überzeugungen zu untersuchen, um zu verstehen, was gerade passiert. Sie verwenden ein wenig Kreativität und Querdenken, um verschiedene Denkweisen für die Situation zu entwickeln. Hoffentlich haben Sie ein System von Gefühlen und Überzeugungen, das ein bisschen besser funktioniert und ein bisschen robuster ist.

(Sie werden sich wahrscheinlich auch irgendwann wie ein kompletter Grund fühlen -Schreiben in einem anderen Rahmen ist die Antwort. Wir nennen das eine Mid-Life-Krise :))

Es ist ein Teamspiel!

Dies ist sehr ähnlich zu dem, was ich einem Kindersportteam daran erinnere, dass ich beim Coaching helfe - nur weil Sie das nicht getan haben [Ball / Puck / Quaffel] im [Netz / Reifen] bedeutet nicht, dass Sie nicht Teil dieser Punktzahl sind. Die Maßnahmen, die Sie ergriffen haben, bevor das Team ein Tor erzielt hat, haben zum Ergebnis beigetragen.

Ihr Kollege konnte Folgendes angeben:

a) Bob Ich habe mehrere Tage damit verbracht, dies aufzuspüren, daher ist es unwahrscheinlich, dass dies eines der offensichtlichen Dinge ist, die sie sonst ausschließen müssten.

b) Es ist wahrscheinlich etwas Lächerlicheres.

Sie beginnen nicht an dem Punkt, an dem Sie es getan haben, sondern bauen dort auf, wo Sie aufgehört haben.

Ich habe auch das Teammitglied, das vorbeikommt, einen Blick auf Ihre Arbeit wirft und das Problem in 5 Minuten löst, mit denen Sie eine Woche lang zu kämpfen hatten.

Was mir emotional sehr geholfen hat, war zu erkennen, dass selbst dieser Typ kein Gott ist, der alles kann. Er ist einfach sehr gut in dem, was ich nicht gut kann.

Jedes Mitglied des Teams hat unterschiedliche Stärken und Schwächen. Das Wichtigste ist, Ihre eigene Stärke zu finden, die von Ihrem Team genutzt werden kann. Für mich stellte ich fest, dass zwei meiner Stärken in meinem Team unterrepräsentiert waren: Codedokumentation und Testen. Die Förderung dieser Stärken gab mir etwas, auf das ich stolz sein konnte, und etwas, bei dem ich meinen Teammitgliedern helfen konnte. Und es gleicht meine Schwächen in Schwierigkeiten aus, Code anderer Leute zu lesen und beim Debuggen von Code langsam zu sein.

Versuchen Sie also, sich nicht mehr mit anderen zu vergleichen. Finden Sie Ihre eigenen Stärken (es kann eine Weile dauern, aber das ist in Ordnung), seien Sie sich Ihrer Schwachstellen bewusst und akzeptieren Sie sie. Stärken Sie Ihre Stärken - so können Sie Ihren Teammitgliedern helfen. Versuchen Sie, mit Ihren Schwachstellen besser zu werden, aber akzeptieren Sie, dass Sie nicht in allen Bereichen gut sein können - holen Sie sich Hilfe von Ihren Teammitgliedern in diesen Bereichen.

Da Emotionen nicht rational sind, kann dies eine Weile dauern besser werden. Es ist ein Prozess.