Gibt es eine Möglichkeit, Fehler schneller zu beheben? Ich habe gerade eine Warnung von meinem Chef erhalten [geschlossen]

Mir wurde gerade von meinem Chef gesagt, dass ich am Montag eine negative Leistungsbeurteilung erhalten werde. Er möchte mit mir darüber sprechen, warum ich so langsam bin und warum meine Fehlerbehebungsrate so niedrig ist.

Ich liebe es zu programmieren und Probleme zu lösen, aber ich finde meinen Job wirklich sehr, sehr schwer.

Ich bin seit ungefähr 10 Jahren Programmierer. Aber dies ist mein erster Multithreading Embedded Linux Job - ich bin seit 2 Jahren hier und es ist für jeden offensichtlich, dass ich immer noch Probleme habe. Und ich glaube, ich bin so demoralisiert und fühle mich so marginalisiert, dass ich viel von dem Feuer verloren habe, das ich zu Beginn meiner Arbeit hatte.

Hat sich jemals jemand in einer ähnlichen Situation befunden und wie erhöhen Sie Ihre Fehlerbehebungsrate?

Update: Ich hatte die Überprüfung. Ich habe ein dreimonatiges "Mitarbeiterentwicklungsprogramm" (der von Dunk genannten Art) absolviert. Ich bin mir nicht sicher, ob ich das ändern kann. Aber auch wenn ich weitermachen muss, habe ich aus dieser Erfahrung viel gelernt.

Noch ein Update

Es sind nun ungefähr 6 Wochen seit der ersten Überprüfung vergangen. Mein Rat an alle, die mit der gleichen Situation konfrontiert sind, ist, demütig genug zu sein, Kritik zu üben und aus Ihren Fehlern zu lernen. Und keine Angst zu haben, dumm auszusehen. Stellen Sie unzählige Fragen. Lassen Sie die Leute wissen, dass Sie versuchen zu lernen und fragen Sie weiter, bis Sie es verstanden haben. Aber seien Sie darauf vorbereitet, dass es nicht klappt. Ich erstelle ein Portfolio mit Code ... und gebe mein Bestes.

Noch ein Update

Ich zögere, dies hier anzulegen, da ich befürchte, dass ich zukünftige Arbeitgeber nicht auf mein Stackoverflow-Profil verweisen kann ... Aber es könnte trotzdem für jemanden von Interesse sein, der diese Frage liest, aber ich habe meine tatsächlich verloren Arbeit vor ein paar Wochen. Ich bin gerade dabei, alle Fähigkeiten zu verbessern, die ich brauche - ich habe viel von den hier gegebenen Ratschlägen übernommen.

Viele Antworten haben die Methoden / Taktiken / Metriken / etc. Ihres Chefs in Frage gestellt. Aber das ist nebensächlich. Vielleicht bist du langsam. Jeder Entwicklerraum muss EINEN haben, der langsamer ist als der Rest, oder? (Das ist nur reine Mengenlehre.) Nehmen wir also an, dass Sie es sind. Die Antwort lautet: WARUM bist du langsam? (Dies ist natürlich die Frage, die Sie beantworten müssen, bevor Sie Ihre festgelegte Frage lösen können, wie Sie schneller werden können.)

Es kann viele verschiedene Gründe geben, aber hier sind einige mögliche Erklärungen, die zu berücksichtigen sind:

1. Sie sind weniger intelligent als sie . Es ist möglich, richtig? (Studien haben gezeigt , dass wir ALLE sind weniger beliebt , weniger interessant , und (es folgen würde) weniger intelligent als unsere Freunde.) Vielleicht sind Sie nur langsam Gehirnen. In Ihrem Fall halte ich dies für unwahrscheinlich. Ein kurzer Blick auf Ihr StackOverflow-Profil zeigt, dass Sie in der Vergangenheit intelligente Fragen zu einer Vielzahl von Themen gestellt haben. Sie sind also offensichtlich ein Denker und wahrscheinlich ein guter Denker.

2. Du bist zu dünn ausgebreitet. Dasselbe SO-Profil von Ihnen zeigt, dass Ihre Fragen in den letzten 2 Jahren ein sehr breites Spektrum von Technologien abdecken (Grafik, Web, Python, C ++, C, Linux, Embedded, Threads, Sockets usw.). Persönlich weiß ich, dass ich, wenn ich in die Situation versetzt worden bin, in eine Vielzahl verschiedener Ströme eintauchen zu müssen (oder wollen), sehr schnell (oder vielmehr sehr langsam ) im Gegenstrom schwimme . Vielleicht brauchen Sie hier wirklich FOCUS . Und vielleicht eine gesunde Portion Priorisierung . Gibt es überhaupt eine Möglichkeit, die weniger wichtigen Töpfe auf den Backburner zu schieben und die Hitze auf dem Hauptgericht zu erhöhen?

3. Du hast keinen Spaß. Wenn das Feuer erlischt, wird die Dampfmaschine langsamer. Sie haben in Ihrem Beitrag zugegeben, dass Ihre Moral in letzter Zeit einen schweren Schlag erlitten hat. Leider sind Sie in den saugenden Wirbel sich selbst verstärkender negativer Harmonischer geraten - eine Kraft, die Brücken zerstören kann . Es ist eine allzu vertraute Spirale: schwierige Aufgabe -> Stress -> Terminüberschreitung -> mehr Stress -> schlechter Bewältigungsmechanismus -> mehr Stress -> Aufschub -> mehr Terminüberschreitung -> Kritik / Klatsch (real oder imaginär) - > noch mehr stress. Du bekommst das Bild. Dies führt selten zu nützlichen Zielen. Nehmen Sie eine Lektion aus meinen Tagen im Wildwasser-Rafting: Wenn Sie von einem zirkulierenden Strom auf der Rückseite eines Klasse-4-Rapid unter Wasser gesaugt werden, wird Ihre Schwimmweste NICHTBoje dich zurück an die Oberfläche. Die beste Strategie (wenn auch nicht intuitiv) ist das finden Boden des Flusses, und zu Fuß aus den riptide. Mein Rat an Sie lautet also: Finden Sie einen Boden , einen Typ (Freunde, eine Kirche, gesunde neue Gewohnheiten usw.) und nutzen Sie ihn, um sich aus dem Whirlpool zu begeben.

4. Du bist nicht in deiner Zone. Michael Jordan machte einen ziemlich lahmen Baseballspieler. (OK, er war immer noch besser als ich, aber definitiv ein Moll-Leaguer.) Vielleicht ist "Multithreading Embedded Linux" einfach nicht dein Gig. Aber Software-Entwicklung ist ein außerordentlich weites Feld (wie Sie wissen, vgl. Nr. 2 oben). Ist Ihr Unternehmen breit genug, um eine weitere Nische zu finden? In meinem letzten Job wurde ich als Entwickler von Embedded-Software eingestellt. (Ich hatte keine Erfahrung in diesem Bereich, aber ich sagte ihnen, ich sei ein "schneller Lerner".) Ich sank schnell wie ein Stein. Aber ich habe weiter hart gearbeitet und nach Problemen gesucht, die ich gemacht habewissen, wie sie zu lösen sind. Es stellte sich heraus, dass ich allmählich in neue Verantwortlichkeiten übergehen konnte, in denen ich glänzen konnte und für die ich schließlich eine beträchtliche Belobigung erhielt. Vielleicht müssen Sie sich selbst neu brandmarken.

Der Punkt ist: Wenn Sie langsam sind, gibt es einen Grund. Aber, hey - du bist ein Software-Ingenieur, Alter! Debuggen Sie sich!

Ihr Chef hat vielleicht Recht: Sie sind möglicherweise "unterdurchschnittlich" (mehr dazu in einer Minute). Aber möglicherweise liegt es nicht nur an Ihrer Kompetenz, die dafür verantwortlich ist. Ich glaube nicht, dass es eine Möglichkeit wäre, darauf hinzuweisen, dass Kräfte, die sich Ihrer Kontrolle entziehen, Stress auslösen, der sich negativ auf Ihre Leistung auswirkt.

Sehen wir uns einige der Gründe an, aus denen Ihr Chef dies jetzt anspricht:

Kultur und Politik

Es kann Kräfte geben, die sich Ihrer Kontrolle entziehen und von Ihrem Chef verlangt werden, jetzt seine Besorgnis zu äußern. Es ist wichtig, das System zu verstehen, in dem Sie arbeiten. Ihre Aufgabe ist es, Ihren Chef gut aussehen zu lassen. Die einzige Möglichkeit, dies zu tun, besteht darin, den Druck zu verstehen, unter dem er / sie steht.

Fähigkeit

Es ist möglich, dass die Fähigkeit nicht der Norm entspricht, wie Sie sagen, dass er es offen gesagt hat. Folgendes würde ich in dieser Situation tun:

Erhalten Sie spezifisches Feedback von Ihrem Chef, wie er misst Leistung. Schließen Sie nicht so viele Bugs wie Person X? Gibt es eine bestimmte Anzahl von Fehlern, die Sie beheben sollten? Wenn Sie alleine arbeiten, müssen Sie sicherstellen, dass die Leute, die Ihre Leistung messen, diese fair messen und nicht auf einer vorgefassten Idee beruhen.

Wenn Ihre Leistung langsam ist und auf einer echten Lücke beruht, identifizieren Sie diese Lücke und stellen Sie mit Ihrem Chef einen detaillierten Plan zusammen, um ihn zu schließen.

Diese Bewertung ist auch eine gute Gelegenheit, um die Tatsache zur Sprache zu bringen, dass Sie nicht glücklich sind. Es ist gut, dass Sie festgestellt haben, dass Sie diesen Job nicht lieben. Aber finde heraus warum. Welchen Teil Ihrer Arbeit mögen Sie und was tun Sie nicht? Es könnte sein, dass dieser Job nicht für Sie ist ...

Einige Arbeitsumgebungen können nicht ausgeführt werden. Ich habe Umgebungen gesehen, in denen niemand überleben konnte (abgesehen von denen, die am Anfang dabei waren), weil so viel undokumentiert war und Fragen so vehement entmutigt wurden.

Sie müssen wirklich ehrlich zu sich selbst sein, was die Erwartungen und die zur Verfügung gestellten Ressourcen angeht, die Ihnen dabei helfen, diese zu erfüllen. Das Problem liegt möglicherweise nicht bei Ihnen.

Sie erwähnen, dass es Leute gibt, die ähnliche Tätigkeiten wie Sie ausüben, die vermutlich keine Schwierigkeiten haben, aber über 5 Jahre Erfahrung mit Ihrer 2. Wie fühlen Sie sich im Vergleich zu Ihren Kollegen? Sind sie Rockstars, die Sie (in dieser Hinsicht) völlig übertreffen, oder sind sie genau wie Sie? Vielleicht haben sie das System erst kennengelernt, als es noch einfacher war ... Sie erwähnten, dass Sie vor dieser Tätigkeit 8 Jahre Programmiererfahrung hatten. Wie bist du dort gelandet? Wenn du großartig warst, sollte dir das etwas sagen.

Der Teil, der mich beeindruckt hat, ist der, dass Sie sich in Bezug auf alle Fehler, die auf Sie zukommen , als im Dunkeln stehend beschreiben . Es kann sein, dass die Codebasis so umfangreich und unbekannt ist, dass die Erwartungen möglicherweise nicht vernünftig sind.

Wenn Sie es soweit geschafft haben, bedeutet dies, dass Sie etwas richtig gemacht haben und etwas für Sie tun.

Unter dem Strich muss man sich gut fühlen und wissen, was man tut. Und wenn das bedeutet, weiterzumachen, dann soll es so sein.

Besser weitermachen, als einen Job zu haben, der dein Leben ruiniert.

Erstens: Diese Antwort gilt möglicherweise nur für bestimmte Regionen, in denen es illegal ist, einen Mitarbeiter ohne Abfindung zu entlassen. Das gesagt...

Dies könnte ein Fall von konstruktiver Entlassung sein und ist illegal.

Die Taktik besteht darin, das Selbstwertgefühl eines Mitarbeiters zu demoralisieren und zu verringern, bis er seinen Job kündigt. Auf diese Weise kann das Unternehmen Geld sparen, indem es keine Abfindung zahlen muss oder das Problem löst, den Mitarbeiter konfrontieren und entlassen zu müssen.

Er möchte mit mir darüber sprechen, warum ich so langsam bin und warum meine Fehlerbehebungsrate so niedrig ist.

Dieser Fehler ist sehr vieldeutig. Es ist unmöglich, dass eine Seite der Partei behauptet, die andere sei falsch. Sie haben einen Monat gebraucht, um einen Fehler zu beheben. Na und! Dies versetzt Sie in eine defensive Position, indem Sie Fakten vorlegen müssen, um Ihre Behauptung zu untermauern, dass ein Monat erforderlich war. In Anbetracht Ihrer aktuellen Fähigkeiten, Erfahrungen und Kenntnisse als Faktoren. Als Arbeitgeber ist es die Aufgabe des Arbeitgebers, die Zeit und den Aufwand seiner Mitarbeiter zu steuern. Der Arbeitgeber muss die Person sein, die das mit der Behebung der Fehler verbundene Risiko eingeht. Nicht der Angestellte. Er hatte immer die Wahl, den Bug jemand anderem zuzuweisen.

Wenn Sie ein Auftragnehmer sind und in Ihrem Vertrag angegeben ist, dass für die Behebung von Fehlern verantwortlich ist, ist dies eine ganz andere Geschichte.

Ist es falsch, wenn sich der Arbeitgeber beschwert, dass Sie zu lange brauchen? Absolut nicht, aber er kann dich nicht dafür zur Rechenschaft ziehen, und er kann dich nicht dafür feuern. Er kann Ihnen sagen: "Wir haben keine Fehler mehr, die Ihre Fähigkeiten erfordern, und Sie werden beurlaubt." Sie müssen Ihnen jedoch mitteilen, sobald ein neues Problem auftritt, das Sie beheben können. Andernfalls müssen sie mit Abfindung enden. Was er nicht tun kann, ist Ihnen Arbeit zu geben, mit der Sie nicht umgehen können, und sich dann darüber zu beschweren. Ich halte das für illegal.

Ich liebe es zu programmieren und Probleme zu lösen, aber ich finde meinen Job wirklich sehr, sehr schwer.

Es gibt einen großen Unterschied, ob Sie einen Job annehmen, den Sie schwer finden, oder ob Ihr Arbeitgeber Ihnen Arbeit gibt, die zu schwer ist. Wenn Sie der Meinung sind, dass die Ihnen zugewiesenen Aufgaben erledigt wurden, um Sie von einer Karriere im Unternehmen abzuhalten, könnte dies illegal sein.

Ich bin seit ungefähr 10 Jahren Programmierer. Aber dies ist mein erster Multithreading Embedded Linux Job - ich bin seit 2 Jahren hier und es ist für jeden offensichtlich, dass ich immer noch Probleme habe.

Aus diesem Grund, glaube ich, haben Sie sich mitten in einer konstruktiven Entlassung befunden. Sie sind nicht glücklich mit dir, also stapeln sie den Mist auf dich, bis du gehst.

Und ich glaube, ich bin so demoralisiert und fühle mich so marginalisiert, dass ich viel von dem Feuer verloren habe, das ich zu Beginn meiner Arbeit hatte.

Ein Arbeitgeber ist dafür verantwortlich, ein sicheres und positives Arbeitsumfeld zu schaffen. Ohne weitere (höchstwahrscheinlich persönliche) Informationen ist es für Außenstehende schwierig zu sagen, was hier wirklich vor sich geht. Fragen Sie einen Arbeitsrechtsanwalt nach einer kostenlosen Beratung. Sie können Ihnen sagen, ob Sie gespielt werden.

Verweise

Ich bin kein Anwalt, habe aber einige Dokumente von Google zum Thema "Konstruktive Entlassung" gelesen, die es wert sind, gelesen zu werden, bevor Sie am Montag Ihre Bewertung abgeben. Das Wichtigste dabei ist, auf Lohnsenkungen, Demütigungen und plötzliche Veränderungen Ihrer Karriere im Unternehmen zu achten.

Relevante Fakten beachten Sie:

• Nicht ordnungsgemäße Unterstützung eines Mitarbeiters unter schwierigen Arbeitsbedingungen
• Übermäßige Disziplinierung eines Mitarbeiters Erzwingen einer kurzfristigen Änderung des Arbeitsplatzes des Mitarbeiters
• Auferlegung einer Lohn- oder Gehaltskürzung

Rechtliche Fragen und Antworten: Konstruktive Entlassung

Gründe für einen Antrag auf konstruktive Kündigung

Wikipedia

Elemente einer konstruktiven Entlassung

Vielleicht werden Sie mit einem der ursprünglichen Programmierer eines Projekts verglichen. Ich weiß, dass ich als ursprünglicher Entwickler eines der Projekte, an denen ich arbeite, einen enormen Vorteil habe, wenn ich Fehler darin behebe. Ich glaube nicht, dass es an mangelnder Dokumentation liegt, sondern dass ich intuitiv zu potenziellen Problemen springen kann, weil mein Gehirn den gesamten Code kennt.

Wenn Sie damit verglichen werden, werden Sie einfach nicht mithalten können. Sie werden immer mehr Zeit benötigen, um sich mit dem Projekt vertraut zu machen, und Sie werden nicht wissen, wo sich alle potenziellen Interaktionspunkte befinden.

Ich habe Ihren Kommentar darüber gelesen, dass Sie keine Informationen zu Tools und Tricks erhalten, mit denen andere Programmierer Probleme lösen. Vielleicht müssen Sie für Ihre nächste Fehlerbehebung die Paarprogrammierung ausprobieren. Das kann unglaublich nützlich sein. Fahren Sie abwechselnd mit der Tastatur. Reden Sie viel .

Sie können ein Notebook oder ein Whiteboard verwenden, um Funktionspfade, Threads und die Lebensdauer von Sperren zu bestimmen und zu markieren, wo Sie verschiedene Verhaltensmerkmale beobachten und wo Sie neue Sonden einfügen können.

Das Lösen dieser Art von Threading-Problemen auf niedriger Ebene kann sehr schwierig sein, und ich habe großes Mitgefühl für Sie. Ich musste zuvor mehrere Gigabyte an Protokolldateien analysieren, um ein zweizeiliges Problem zu erkennen. Und weisst du was? Ich starrte das tagelang an, bevor ich einen Junioringenieur um Hilfe bat, der ein Jahr zuvor Praktikant gewesen war, und er kam auf eine neue Herangehensweise und entdeckte das Problem in einer Stunde. Also, nachdem Sie einige Zeit in einen Bug gesteckt haben, bekommen Sie ein paar neue Augen darauf. Es kann viel helfen!

Eine der häufigsten Verwaltungsstörungen in dieser Branche besteht darin, nicht zu verstehen, dass das Debuggen von Natur aus schwierig ist . Ich habe fast 20 Jahre Erfahrung und ich muss immer noch regelmäßig eine ganze Woche damit verbringen, den Einzeilenfehler zu finden, durch den das Programm einmal von fünfzig abstürzt. Und wenn mein Vorgesetzter diese Dinge nicht versteht, muss ich eine Woche warten, um eine Codezeile zu ändern.

Was können Sie dagegen tun?

• Machen Sie sich beim Debuggen Notizen. Lassen Sie einfach immer ein Editorfenster offen und schreiben Sie Ihren Bewusstseinsstrom auf. Es muss für niemanden außer Ihnen einen Sinn ergeben. Sie werden feststellen, dass dies Ihnen hilft, schneller zu debuggen, aber es bedeutet auch, dass Sie auf etwas Konkretes hinweisen müssen, um zu demonstrieren, dass Sie die ganze Woche nicht Nethack gespielt haben.

• Vergleichen Sie Notizen mit all Ihren Mitarbeitern. Wie lange dauert es normalerweise, bis sie die Fehler behoben haben? Bleiben ihre Fehler behoben? Wie oft ändern sie eine Kleinigkeit und werden von einer Reihe von Folgen heimgesucht? Die Antworten auf diese Fragen geben Ihnen einen Eindruck davon, ob Sie wirklich mit dem Rest der Abteilung zu kämpfen haben.

• Bilden Sie Freunde mit den QA-Leuten und den Kundenbetreuungsleuten. Sie wissen am besten, wie wichtig die Bugs sind. Oft hat dies wenig oder gar keine Korrelation mit dem Schwierigkeitsgrad der Bugs. Sie können das System also ein wenig spielen und versuchen, alle wichtigen Bugs mit niedrigem Schwierigkeitsgrad zuzuweisen. (Dies ist kein wirklicher Betrug. Ein gut organisiertes Team geht diesen Fehlern immer zuerst nach.)

• Wenn Ihr Chef Ihnen zwei Jahre lang kein angemessenes Feedback zu Ihrer Leistung gegeben hat, ist dies ein Problem, das Sie zuerst bei dieser Leistungsüberprüfung ansprechen müssen und dann, wenn Sie den Überblick darüber erhalten, mit dem Chef Ihres Chefs zu sprechen. Seien Sie höflich und lassen Sie sie besonders nicht sehen, wie wütend Sie sind, sondern lassen Sie sich schriftlich kritisieren.

Während Sie es lieben mögen, Probleme zu programmieren und zu lösen, könnte die Frage aufkommen, wie gut Sie das Gelernte auf andere Bereiche übertragen. Sind einige der letzten Dutzend Fehler, die Sie behoben haben, ähnlich genug, dass das, was Ihnen bei der Behebung eines Fehlers geholfen hat, für einen anderen nützlich war? Dies ist ein Teil des Rückblicks auf das, was Sie getan haben und wie lange es gedauert hat, dies zu tun. Nur eine zu überlegende Idee.

Zweitens würde ich nachsehen, wie Sie Ihre Arbeit machen. Werden Sie regelmäßig unterbrochen und erhalten die Meldung, dass die Fehler B und C die höhere Priorität haben, wenn Sie versuchen, Fehler A zu beheben? Überlegen Sie genau, welche Art von Änderungen bei Ihrer Arbeit Ihnen dabei helfen können, da dies wahrscheinlich Teil dessen ist, was Ihr Chef wissen möchte.

Ich habe von einigen Arbeitsplätzen erfahren, dass ihnen nicht gefallen hat, wie lange ich gebraucht habe, um einen Teil meiner Arbeit zu erledigen. Natürlich waren dies die Orte, an denen, wenn ich eine Sache erledigen würde, 5 neue Dinge in meinen Schoß fielen und es daher leicht war, überwältigt zu werden. Während ich dort nicht mehr arbeiten kann, hatte ich keine gute Lösung, um meine Aufmerksamkeit auf ein paar Dinge zu lenken, so dass ich nicht das Gefühl habe, 1000 Dinge auf einmal zu meistern. Wenn ich ein paar wichtige Dinge wissen kann, die zu erledigen sind, und weiß, wie meine Arbeit bewertet wird, dann bin ich viel besser als wenn ich eine kilometerlange "To-Do" -Liste habe und es niemanden zu interessieren scheint, wenn ich sie bekomme Teile davon erledigt. Es könnte also sein, dass dies eine kulturelle Komponente innerhalb der Organisation ist, obwohl ich vorsichtig sein würde, wenn ich darum bitten würde, dass sich hier etwas ändert.

Nach zwei Jahren im Job sollte für alle (Sie, Ihr Chef, Ihre Kollegen) klar sein, wo Sie stehen. Das heißt, Sie sollten niemals herausfinden, dass Sie nur einmal im Jahr schlechte Leistungen erbracht haben. Ein ideales Arbeitsumfeld bietet ein kontinuierliches Feedback.

Wie auch immer, in Bezug auf das Debuggen von Multithread-Code: Sie haben nicht erwähnt, ob dies Ihr Code oder der Code eines anderen ist. Es gibt einige neue Debugger und statische Analysatoren, die die Parallelität verarbeiten können. Aber wirklich, die Muster zu kennen, ist die beste Wahl, da Sie wissen, wonach Sie suchen müssen.

Wenn Sie verstehen, wie kritische Abschnitte, Rennbedingungen und Deadlocks funktionieren, können Sie unerwartete Ereignisse besser erkennen. Wenn Sie "Kommunikation" zwischen zwei Threads ohne Bedingungsvariablen sehen oder wenn Ressourcen ohne eine bestimmte Reihenfolge mutexiert werden oder wenn eine lokale Variable staticohne ersichtlichen Grund deklariert wird , liegt ein potenzieller Fehler vor! Lernen Sie also die Best Practices Ihrer Domain kennen und Sie können besser beurteilen, wenn etwas ungewöhnlich ist.

Kämpfe nicht alleine, es sei denn du musst. Rekrutieren Sie Kollegen. Bringen Sie sie dazu, bei der Fehlersuche zu helfen. Fragen Sie sie nach ihrem Denkprozess und ihren Werkzeugen. Erwähnen Sie dies möglicherweise in Ihrer Rezension als Teil Ihres Plans zur Verbesserung. Wenn alle um Sie herum besser mit diesem System umgehen, wissen sie vielleicht etwas Bestimmtes?

Mir wurde gerade von meinem Chef gesagt, dass ich am Montag eine negative Leistungsbeurteilung erhalten werde. Er möchte mit mir darüber sprechen, warum ich so langsam bin und warum meine Fehlerbehebungsrate so niedrig ist.

Beachten Sie, dass in einem nicht funktionsgestörten Unternehmen Dinge nicht in dieser Reihenfolge geschehen. Wenn Ihr Chef sich Sorgen um Ihre Leistung macht, sollte er sich kurzfristige Ziele setzen und über Ihre Ergebnisse sprechen, um herauszufinden, wo das Problem liegt.

Stattdessen beschließt er, eine negative Bewertung abzugeben und dann herauszufinden, warum. Klingt so, als wäre er nicht bereit, sich auf das Problem einzulassen, und möchte nur Ergebnisse in der Tabelle haben.

Versuchen Sie nicht, Fehler schneller zu beheben. Versuchen Sie, Ihre eigenen Fähigkeiten einzuschätzen, zu überprüfen, wie Ihre Kollegen arbeiten, wie sie wissen, was sie wissen, und sich darüber im Klaren zu sein, dass dies kein ideales Unternehmen ist.

Für praktische Tipps verwende ich Codefragmente und mein eigenes MediaWiki, um Notizen zu machen. Ich habe immer vor Augen, welche Bücher ich als nächstes lesen und in welche Richtung ich gehen soll, um weiterzulernen. Lernen ist der Weg zu einem besseren Job und einem glücklicheren Leben.

Erstens ein Vertrauensschub:

Warum leiden? Sie können leicht einen Job finden, bei dem sie glauben, Sie seien "Gott", nur weil Sie alles in Linux eingebettete tun können, unabhängig von Ihrer Fehlerbehebungsrate.

Wie auch immer, es ist unmöglich, ein Zeitlimit für die Suche nach einem Bug festzulegen. Das Jagen von Insekten ist zweifellos eine Fähigkeit, und die Effizienz darin ist äußerst wertvoll.

Möglicherweise fehlt Ihnen ein grundlegender Trick, den andere kennen, wodurch Sie langsamer werden.

Wenn Sie und ich zum Beispiel an einer Linux-Middleware arbeiten und Valgrind verwenden, um Speicherbeschädigungsprobleme und Datenrassenzustände zu finden, während Sie sich nur auf gdb und printf verlassen, werde ich wahrscheinlich auf Ihren Hintern treten, selbst wenn du bist schlauer als ich

Wie ist Ihr Verständnis von Parallelität ? Wenn Sie sich seit zehn Jahren weiterentwickeln, die meiste Erfahrung jedoch nicht mit Multithread-Code gemacht haben, könnte dies ein Problem sein.

Sie sollten sich eingehend mit Multithreading befassen: Sie müssen nicht nur wissen, wie die APIs verwendet werden, sondern sie auch wirklich auf einer tiefen Ebene "verstehen". Wenn Sie Multithread-Programmierung durchführen, sollten Sie derjenige Entwickler sein, der eine Codebasis aus einer Entfernung von mehreren Kilometern betrachten und Szenarien von Rennbedingungen, Deadlocks, Prioritätsumkehrungen, Hunger ... erkennen kann.

Ich habe kürzlich das Buch Working Effectively with Legacy Code gelesen, und es gibt mir einen deutlichen Vertrauensschub, wenn ich ein Problem in einer beliebigen Codebasis anpacke.

Wenn der Code, mit dem Sie arbeiten, alles andere als perfekt ist, ist dieses Buch meiner Meinung nach hilfreich. Ich habe festgestellt, dass ich die meiste Zeit, um einen Fehler zu beheben, zuerst den umgebenden Code überarbeiten muss, um ihn überhaupt zu verstehen , und dann, sobald ich den Code verstehe, den Code hoffentlich testbar machen, aufspüren und Das Problem zu beheben ist weniger anstrengend. (Manchmal schreibe ich den Code sogar neu, um ihn zu verstehen, aber mache dann meine Änderungen wieder rückgängig, um das Risiko der Einführung neuer Fehler zu verringern. Dann füge ich meine Fehlerbehebung ein. Diese Technik basiert auf einem Trick aus dem Buch.)

Ich denke, mein Vorschlag befasst sich nur mit einem Teil Ihres Problems, und zwar etwas indirekt, aber das Buch ist auf jeden Fall lesenswert, da die Arbeit mit Legacy-Code für jeden Entwickler unvermeidlich ist.

Fragen Sie Ihren Vorgesetzten, wie schnell Sie Fehler beheben und wie schnell das Team die Fehler durchschnittlich behebt. Noch wichtiger ist, fragen Sie ihn, wie die Geschwindigkeit der Fehlerbehebung gemessen wird ...

Dies ist eine Art Metrik, die eigentlich keine Metrik ist. Wenn es so wäre, wäre es sogar noch unzuverlässiger als LOC (obwohl es verschiedene Dinge misst). Und ohne eine richtige Messung gibt es keinen Grund, Ihnen irgendetwas vorzuwerfen.

Erkennen Sie, dass Sie MIT Arbeitgebern und / oder Kunden NICHT für sie arbeiten. Zögern Sie nicht, dies in den Interviews zu erwähnen, nur um den Rekord von Anfang an richtig zu stellen.

Sie sind ein Profi, der viel in Ihr kleines Unternehmen investiert hat, nämlich Sie selbst.

Sie sind bereit zu arbeiten, während eine Interessenvereinigung Sie jeden Tag aus dem Regal befördert.

Wenn dieser Antrieb längere Zeit nicht vorhanden ist, fahren Sie fort.

Sie verschwenden Ihre Zeit und Energie mit einem Penner-Arbeitgeber, der Ihr Interesse nicht aufrecht erhält / Ihre Fähigkeiten aktualisiert / Ihre Aufgaben herausfordernd und / oder interessant für Sie sind. Das ist die Aufgabe des Managements. Ansonsten sind sie reine Overhead .....

Halte deine Leidenschaft am Laufen, denn das ist der Schlüssel.

Ich war in ähnlichen Situationen, weil ich Angst hatte, um Hilfe zu bitten. Nach dem zu urteilen, was Sie in diesem Kommentar gesagt haben ...

"Aber was frustrierend ist, dass es bestimmte Tools / Tipps / Tricks gibt, die ich erst herausgefunden habe, als ich anderthalb Jahre dort war. Ich bin von Team zu Team gewechselt worden (ich denke, weil ich unterdurchschnittlich war) und ich entdecke diese "versteckten" Werkzeuge immer wieder. "

... Sie hatten vielleicht das gleiche Problem wie ich. Das Debuggen ist ebenso ein Handwerk wie das Schreiben von Code, für den in erster Linie nicht so viel Debugging erforderlich ist. Das Beobachten, wie andere Entwickler ein Debug-Problem lösen, kann sehr lehrreich sein. Bitten Sie sie um Hilfe, wenn Sie Probleme beim Aussortieren haben. Vor allem, wenn Sie Boden abdecken, den Sie vorher nicht haben. Und dies idealerweise, bevor es Zeit für Panik ist, weil Sie nichts erledigen können.

Trotzdem stimme ich den Kommentaren zu, dass das Management etwas falsch gemacht hat. Wenn jemand mit etwas zu kämpfen hat, sollte er Hilfe bekommen, bevor der Spaß an der negativen Bewertung beginnt. Zur Hölle, wenn jemand in einem Team Probleme hat und nie Hilfe bekommt, würde ich sagen, dass jedes Mitglied dieses Teams etwas falsch macht (obwohl dies eine direkte Folge davon sein könnte, dass die Leute ihre Fehlerbehebungsraten zu genau beobachten).

Was im OP fehlt, ist die Erwähnung eines wiederholbaren Prozesses oder einer wiederholbaren Methode zur Behebung von Fehlern.

Dokumentieren Sie also zunächst den Prozess, dem Sie folgen. Stellen Sie sicher, dass Sie dokumentieren, was mit jedem Schritt im Prozess erreicht werden soll.

Sie können den Prozess folgendermaßen umreißen:

1. Stellen Sie sicher, dass Sie genau verstehen, worum es sich bei dem gemeldeten Problem handelt.
2. Versuchen Sie, das Problem zu reproduzieren.
3. Zerlegen Sie das Problem in kleinere Teile
4. Denken Sie an mögliche Ursachen des Problems.
5. Testen Sie diese Hypothesen

Es wäre hilfreich zu wissen, ob die Bugs schon lange existieren oder mit den neuesten Änderungen eingeführt wurden. Wenn die Fehler in den letzten Jahren durch Codeüberprüfungen und / oder das einfache Lesen des Codes, den Benutzer erstellen, behoben wurden, kann dies Abhilfe schaffen.

Ich denke, wenn Sie das Problem klar definieren können, z. B. "Ich habe Probleme, mir zu prüfende Hypothesen auszudenken, wenn ich versuche, Fehler zu beheben", können Sie gezieltere Ratschläge erhalten.