Wie Sie motiviert werden, an Aufgaben zu arbeiten, die Ihnen nicht helfen, sich zu verbessern

Für mich gibt es zwei Aspekte jeder Aufgabe, die einem Entwickler in einem Softwareprojekt zugewiesen wird. Diese sind nicht exklusiv, sodass eine Aufgabe beispielsweise zu 40 % aus Aspekt 1 und zu 60 % aus Aspekt 2 bestehen kann:

  1. Aufgaben, bei denen Sie neue Dinge lernen oder Ihr vorhandenes Verständnis verbessern müssen. Dadurch verbessern Sie sich als Entwickler und erworbene Kenntnisse/Erfahrungen sind übertragbar, entweder auf andere Bereiche im selben Projekt oder auf andere Projekte.
  2. Aufgaben, die spezifisch für das Projekt oder sogar für einen sehr kleinen Bereich davon sind. Wenn Sie sie ausführen, können Sie sich als bestimmter Entwickler dieses Projekts nur verbessern. Selbst dann sind gewonnene Kenntnisse/Erfahrungen nur in diesem spezifischen Teil des Projekts nützlich und daher nutzlos, es sei denn, es werden in Zukunft viele Aufgaben auf denselben Teil konzentriert.

Ich habe kein Problem damit, an Aufgaben zu arbeiten, die ausschließlich zu Typ 2 gehören, da sie Teil des Jobs sind, aber wenn es andere Teammitglieder gibt, die bereits viel Zeit mit diesen spezifischen Bereichen verbracht haben, scheint es mir, als würde ich sie erledigen Verschwendung von Zeit und Ressourcen für alle. Das tötet absolut meine Motivation. Vor allem in einem Projekt kurz vor dem Abschluss, wenn klar ist, dass es in diesen Bereichen keine Aufgaben mehr geben wird.

Dies kann nützlich sein, um Wissen im Team zu teilen, zB wenn jemand kündigt, könnten andere übernehmen, aber jeder kann ein paar Tage damit verbringen, einen Code herauszufinden. Es im Voraus zu tun ist, als würde man für einen Unfall bezahlen, der noch nicht passiert ist oder tatsächlich nie passieren wird.

Warum sollten andere Leute die Routinearbeit erledigen, die Sie nicht mögen? Haben Sie schon einmal darüber nachgedacht, dass die "anderen Teammitglieder, die viel an diesen bestimmten Bereichen gearbeitet haben" es auch nicht mögen?
@MarkRotteveel Worüber ich spreche, ist überhaupt keine Grunzerarbeit. Es gibt Bereiche, die ich geschrieben habe, wenn jemand daran arbeitet, würde es fünfmal so lange dauern, wie es bei mir dauern würde, und das Lernen dieses Teils wird ihm keine Erfahrung oder Wissen hinzufügen, ich glaube, es gibt keinen Grund für sie, es so lange zu tun Ich gehe nicht.
@uylmz Ich vermute, dass Sie dort den Nagel auf den Kopf getroffen haben, ohne es zu merken - das Duplizieren von Wissen und Erfahrung auf mehrere Teammitglieder ist eine gute Praxis, gerade weil Menschen gehen, krank werden, sterben und so weiter.
Motosubatsu Ich gehe immer davon aus, dass sie im Lotto gewinnen, der reiche Onkel hinterlässt ihnen Millionen. Viel mitarbeiterfreundlicher :-)

Antworten (4)

Ich verstehe, dass es nicht schön ist, in eine Schublade gesteckt zu werden; Ich war selbst dort und habe an Legacy-Projekten gearbeitet, die für die heutige Technologie, Architektur oder Methoden wirklich nicht relevant sind. Wenn ich allein gelassen worden wäre, wäre ich wahrscheinlich der „Legacy-Code-Typ“ geworden, also habe ich mit meinem Manager gesprochen und gesagt, dass ich neben der Arbeit an Legacy-Sachen auch andere Dinge tun möchte. Ich denke also, Schritt 1 für Sie ist, etwas Ähnliches bei Ihrem Vorgesetzten anzusprechen.

Es wird immer Aufgaben bei der Arbeit geben, die Sie nicht erledigen möchten, die sich aber nicht von selbst erledigen, und schließlich muss sie jemand erledigen. Es ist jedoch nicht fair, dass dies die alleinige Verantwortung einer Person ist, daher haben Sie das Recht, an anderen Dingen zu arbeiten, solange Sie Ihren Anteil an der Gesamtverantwortung übernehmen, so wie es jeder gute Mitarbeiter tut, wenn er sich für eine Arbeit entscheidet für einen Arbeitgeber.

In Bezug darauf, wie Sie sich in Zeiten motivieren können, in denen Sie festgefahren sind und Dinge tun, die Sie nicht tun möchten, sind hier einige Tipps, die für mich funktionieren:

  • Wenn der Code schlecht ist, betrachten Sie ihn als eine Übung, um zu lernen, wie Sie Ihre zukünftige Software nicht schreiben sollten.
  • Denken Sie daran, dass jede Arbeit, die Sie als Softwareentwickler leisten, relevante Erfahrung für Sie ist. Sie müssen nicht immer die neuesten technologischen Trends nutzen oder völlig neue Konzepte lernen, um beruflich zu wachsen; Jede Programmierung, die Sie machen, trägt dazu bei, dass Sie ein besserer Entwickler werden.
  • Wenn es etwas wirklich Schreckliches und Langweiliges ist (und ich muss mein Gehirn nicht zu sehr benutzen), höre ich Thrash Metal und treibe es einfach durch.
  • Wenn Sie in langen Phasen, in denen Sie nicht an interessanten Dingen arbeiten, ernsthaft daran interessiert sind, ein guter Softwareentwickler zu werden, dann studieren Sie in Ihrer Freizeit. Lies Bücher, mache persönliche Projekte, trage zu einigen Open-Source-Projekten bei usw.

Schließlich ist Ihr Punkt zum Teilen von Wissen gültig. Ihr nächster Punkt, dass es Zeitverschwendung sei, ist jedoch nicht gültig - wie Sie sagten, ist es

für einen Unfall zu bezahlen, der noch nicht passiert ist oder vielleicht noch nie passieren wird

Du hast es selbst gesagt; Es ist nicht garantiert, dass diese erfahrenen Entwickler immer da sein werden, daher ist es im besten Interesse des Unternehmens, sicherzustellen, dass genügend Leute über diese Produkte Bescheid wissen, um sie am Laufen zu halten, falls Leute gehen (oder, wie es zunehmend der Fall ist, mit Legacy-Code , sterben).

Es hat wahrscheinlich damit begonnen, dass einer dieser "anderen Mitglieder, die viel Zeit dort verbracht haben", sagte, dass sie auch an anderen Aufgaben arbeiten möchten, und der Busfaktor ist auch ein gutes Argument.

Ich habe verschiedene Strategien verwendet, je nach Aufgabentyp, Umfang, erwarteter Zeit usw.:

  1. Langweilige Handarbeit? Anstatt eine einfache Aufgabe in den nächsten 5 Stunden mehr als 100 Mal zu erledigen, werde ich einen Weg finden, sie zu automatisieren (oder zumindest halbautomatisch). Es kann am Ende 8 Stunden dauern, aber es a) macht mehr Spaß, b) ist weniger fehleranfällig (fast immer), c) wiederverwendbar (weil wir wissen, dass einmalige Probleme dazu neigen, wiederholt von den Toten aufzuerstehen), d ) Wenn nichts anderes, haben Sie Ihre Skriptfähigkeiten geübt und die nächste Aufgabe wird einfacher und effektiver [mit Ihren Worten haben Sie die Aufgabe gerade in Gruppe 1 verschoben]
  2. Verwandle es in einen Wettbewerb. Messen Sie etwas und versuchen Sie, es kontinuierlich zu schlagen. Hilft sicherlich, wenn Sie nicht der einzige sind, der die Arbeit macht.
  3. Versuchen Sie, Spaß an der Aufgabe selbst zu finden. Dies ist sehr zuverlässig von der Aufgabe und deren Art. Wenn Sie an durcheinandergebrachtem Legacy-Code arbeiten, zeigen Sie Ihrem Kollegen die lustigen Teile "Hey Pete, arbeite gerade an , wenn Sie diese Klasse in der IDE öffnen, sieht der Linter aus wie eine große Bildlaufleiste." Wenn Sie oft daran arbeiten, können Sie einen (monatlichen) Wettbewerb für den "schlechtesten/verrücktesten/hässlichsten gefundenen Code" oder ähnliches veranstalten.
  4. Funktioniert für eher kurze Aufgaben - spiele laute (trashige) Musik, schalte das Gehirn aus und erledige es.
  5. Denken Sie daran, dass Sie am meisten aus den schlechten Dingen lernen. Ich habe immer gewusst, dass es ein Antimuster ist, eine Ausnahme in Java zu protokollieren und auszulösen. Wenn Sie das tatsächliche Protokoll davon sehen, werden Sie sich viel mehr (und für immer) daran erinnern/verstehen. Ich habe darüber geschimpft, dass einige Maven-Hacks schwer zu verstehen sind. Dann sah ich Ameisenskripte. Plötzlich beschwere ich mich nicht mehr.
  6. Machen Sie die Aufgabe größer, indem Sie Teile aus der ersten Gruppe einbeziehen: Fehlerhafter Teil des Codes? Schreiben Sie (Unit-)Tests. Legacy-Hölle? Machen Sie ein bisschen Refactoring. [moderne Workflows sollen Ihnen helfen, die dort verbrachte Zeit zu rechtfertigen]
  7. Innere Ruhe schaffen: Wenn ich an etwas arbeiten muss, das mir nicht gefällt, hilft es mir, hinterher eine E-Mail zu dem Thema zu schreiben, wie man es richtig macht usw. Auch wenn ich weiß, dass die Erfolgsaussichten null sind, werde ich es tun tun Sie dies. Wenn es wieder explodiert, werde ich ein Follow-up zu dieser E-Mail schreiben. [und sich möglicherweise darüber lustig machen, wie die Leute das Problem vermeiden, Ausreden finden usw.]
  8. Ähnlich wie zuvor werde ich Aufgaben für alles erstellen, was nicht stimmt, und sie im Rückstand halten, dann zustimmen, dass es eine niedrige Priorität hat, aber niemals schließen, es sei denn, es ist gelöst. [hilft auch bei anderen Sachen]
  9. Der "feeling good"-Weg - funktioniert bei Problemen etc. Für mich fühlt es sich gut an, "der Typ zu sein, der weiß" und andere kommen um Hilfe zu holen oder der "rettete einen Tag"-Typ zu sein oder einfach ein guter Teamkollege zu sein und einen dafür zu nehmen Team (wie sich freiwillig für eine Aufgabe zu melden, die jeder hasst, und jede Methode anzuwenden, um es lustiger zu machen, und wenn möglich, das loszuwerden).
  10. Machen Sie regelmäßig Pausen, um bei Verstand zu bleiben.

Hinweis: Es gibt buchstäblich Hunderte von Möglichkeiten, basierend auf der Art der Aufgabe (Legacy-Code-Bug, Legacy-Code-Funktion, manuelles Klicken, manuelle Datenkorrektur/en, Berichterstellung, Erlernen unpopulärer/alter Technologie), erwarteter Zeit für die Fertigstellung (5 Minuten verrückt Klicken, 1 Stunde hartes Nachdenken, 3 Monate Recherche, ...) usw.

Wie Sie motiviert werden, an Aufgaben zu arbeiten, die Ihnen nicht helfen, sich zu verbessern

Selbst wenn Sie Ihre aktuelle Aufgabe nicht verbessern können (das bezweifle ich), gewinnen Sie durch die Erledigung dieser Aufgaben Zeit, um an Aufgaben zu arbeiten, die Ihnen helfen, sich zu verbessern.

Wenn Ihr einziger Zweck der Arbeit in Ihrem Unternehmen also darin besteht, sich zu verbessern, sollte Ihre Motivation darin bestehen, die „nicht verbessernde“ Aufgabe A zu erledigen, damit Sie an der „verbessernden“ Aufgabe B arbeiten können.

Überlegen Sie, wie Ihre Routinearbeit automatisiert werden könnte. Nutzen Sie die Gefühle von Frustration und Abgestumpftheit als Zündsystem für Ihre Entdeckung von Automatisierungsmethoden.