Wenn Sie während der Sprintplanung keine Geschichten aufgreifen, treten Sie weiter in den Hintergrund. Hör auf mürrisch zu sein und verbessere dein Spiel.

Arbeite mit ihm. Lerne von ihm. Bitten Sie ihn, Ihnen zu helfen, sein Niveau zu erreichen. Überprüfen Sie seinen Code per Peer-Review und stellen Sie nach Bedarf Fragen, um ihn zu verstehen - jemand muss es, und es ist eine großartige Gelegenheit, etwas zu lernen.

Tom hat offensichtlich die "Big-Picture" -Architektur im Kopf. Dies erleichtert das Entwerfen der kleineren Teile und das Erkennen, wie alles zusammenpasst.

Anstatt sich auf die Kleinigkeiten zu konzentrieren, sollten Sie sich darauf konzentrieren, die Architektur zu verstehen, die Tom im Sinn hat. Wenn Sie ein gutes Verständnis für gute Designtechniken haben, sollte Ihnen dies immens helfen. Wenn Tom noch keine Beschreibung der Architektur hat, lohnt es sich wahrscheinlich sehr, die Architektur zu dokumentieren und Tom zu bitten, das zu ergänzen, was Sie verpasst haben.

Wenn Tom ist so gut wie du sagst, dann wette ich, dass sein Ansatz sehr systematisch und eigentlich ziemlich einfach zu befolgen ist, wenn du erst einmal das "Was" und "Warum" von dem lernst, was Tom in der Architektur erreichen will. Sobald Sie das "Was" und "Warum" verstanden haben, können Sie sich auf das "Wie" konzentrieren, und ich bin sicher, dass es dann viel einfacher wird.

Aus Ihrer Beschreibung geht hervor, dass Sie einfach sind Implementieren Sie die Dinge so, wie Tom es Ihnen sagt, ohne zu verstehen, warum. Deshalb hast du nicht das Gefühl, dass es dir besser geht. Sie müssen wirklich verstehen, warum oder Sie werden sich nie verbessern, und Sie werden Toms Hilfe jedes Mal brauchen, wenn Sie etwas aus der Ferne angehen.

Diese Frage ist sehr schwer zu beantworten, da die Antwort stark von Tom abhängt. Ich habe an mehreren verschiedenen Programmen gearbeitet, an denen ein genialer Programmierer beteiligt war, und hier sind einige Dinge, die ich aufgegriffen habe.

• Denken Sie daran, dass Sie der zweitbeste Entwickler sind das Team, nicht der schlechteste Entwickler
• Vermeiden Sie es, Ihre eigene Leistung an anderen zu messen. Gibst du alles was du kannst? Nur weil er ein extrem guter Entwickler ist und Sie einfach ein guter Entwickler sind, sind Sie kein schlechter Entwickler.

Was ist Toms Persönlichkeit?

Toms Persönlichkeit hat großen Einfluss darauf, wie viel er Ihnen helfen kann und will. Wenn es ihm nichts ausmacht zu helfen / zu lehren, nutzen Sie es voll aus. Wenn er hartnäckig ist und / oder keine persönlichen Fähigkeiten besitzt, lernen Sie so viel wie möglich aus dem Internet, halten Sie Ihre Fähigkeiten auf dem neuesten Stand und suchen Sie sich woanders einen neuen Job. In beiden Fällen tragen Sie bei, was Sie können. Wenn Ihr Programm keine Tester hat, konzentrieren Sie sich darauf, seinen Code zu testen. Dafür gibt es viele Gründe: Es wird Ihnen helfen, seine Sachen zu lernen, es hält Sie beschäftigt und führt Sie aus, es bestätigt, dass sein Code ein Code auf Geniestufe und kein Code für Fleischbällchenoperationen ist (letzterer sieht für eine Weile gut aus und fällt dann auseinander ).

Ratschläge für Führungskräfte

Im Allgemeinen müssen sich die Führungskräfte im Team jedoch bewusst sein, dass sie ein Genie im Team haben und geeignete Schritte unternehmen. Der Hauptgrund dafür ist, dass Entwickler auf Genie-Ebene dazu neigen, Code zu schreiben, dessen Verständnis ein Genie erfordert. Dies führt zu einem Risiko für das Programm, und das Genie muss lernen, wie man besser wartbaren Code schreibt. Beispiel aus meiner eigenen Vergangenheit:

Einmal hatten wir drei Monate lang einen genialen Entwickler in unserem Team. Er hat unglaubliche Arbeit geleistet, um alle Arten von herausfordernden Codeproblemen zu lösen, die andere Entwickler im Team doppelt so lange gebraucht hätten. Das Problem war, dass sein vorheriges Programm ihn nach drei Monaten dringend zurück brauchte, weil er der einzige war, der einige der Probleme beheben konnte, die sie hatten. Also haben wir ihn verloren und mussten dann anfangen, seinen Code zu pflegen.

Glücklicherweise waren wir nicht wie sein vorheriges Programm von ihm abhängig geworden, aber wir hatten immer noch Probleme mit anderen Entwicklern, die Schwierigkeiten hatten, Updates vorzunehmen zu seinem Code, da sie so lange gebraucht haben, um seinen Code zu verbessern. In Ihrem Fall, in dem sich nur zwei Personen entwickeln und dies jahrelang unbehandelt bleibt und Tom dann beschließt, das Programm zu verlassen, kann dies die Leistung des Programms erheblich beeinträchtigen.

Ich wusste nicht, dass Sie sich so fühlen ...

Aber im Ernst, seien Sie einfach selbstbewusster. Manchmal neigen Menschen dazu, Persönlichkeiten zu haben, bei denen sie das Gefühl haben, dass Projekte falsch ausgeführt werden, wenn sie nicht direkt darüber schweben. Teilen Sie die Arbeit so auf, dass jeder von Ihnen den Fortschritt des anderen sehen und verstehen kann, was los ist. Lassen Sie sich nicht mit offenem Mund erwischen, wenn er plötzlich zu MIA geht und Sie die alleinige Verantwortung tragen.

Besprechen Sie einige Geschichten, wenn Sie eine Idee haben, wenn überhaupt, stellen Sie sie einfach da raus. Die gesamte Idee der Sprintplanung besteht darin, ein Brainstorming durchzuführen, das nicht zu dem passt, was "Tom" gesagt hat. Vielleicht sind deine Ideen besser als du denkst. Das Sitzen auf der Rückseite Ihres Sitzes wird nicht für Sie funktionieren.

Abgesehen davon ist das Testen von Fehlern wichtig. Und das mit Ihrem eigenen Code zu tun, ist schwierig. Und ich zeige nicht auf Unit-Tests, sondern auf echte menschliche Tests. Dies ist möglicherweise nicht Ihre ideale Position, hilft Ihnen jedoch dabei, wirklich darüber nachzudenken, wie Sie Code erstellen können, um Fehler zu vermeiden.

Es ist eine gute Gelegenheit für Sie. Nehmen Sie die herausfordernde Aufgabe und stellen Sie Ihrem talentierten Teammitglied eine Frage. Er wird Ihnen auf jeden Fall helfen. Sie werden viel von ihm lernen und fühlen sich nicht als ziemlich nutzlos. Es ist Ihr Fehler, dass Sie nicht nach vorne kommen, um die Aufgaben zu übernehmen. Nach ihm haben Sie nur den Kontaktpunkt, nur dass Sie nicht viel von Ihrem beigetragen haben Seite, aber Sie wissen alles in diesem Projekt.

Nehmen Sie die neuen Geschichten mit Ihren Teamkollegen und beginnen Sie damit, daran zu arbeiten, wie ein Team funktioniert. Alle Teammitglieder sind nicht gleich talentiert, aber Sie müssen lernen, das Talent anderer zu nutzen, indem Sie sie höflich fragen. Aber stellen Sie sicher, dass Sie sie nicht langweilen, indem Sie dumme Fragen stellen und nichts von Ihrer Seite versuchen, was Sie im Team produktiv hält.

Bist du sicher, dass Tom das Genie ist, von dem du denkst, dass er es ist? Dies liest sich wie die Einführung in eine tägliche WTF-Geschichte, in der Tom das System neu implementiert und eine gute Zeile spricht, aber wenn jemand seinen Code tatsächlich betrachtet, ist er tatsächlich schlampig und unbegründet.

Es ist sicherlich möglich dass Tom weiß, was er tut (und Sie sollten dies von einem der leitenden Entwickler bestätigen lassen). In diesem Fall kann er Ihnen hoffentlich viel beibringen, aber ich vermute, dass Tom glaubt, er weiß verdammt viel mehr als Er tut es tatsächlich. In diesem Fall profitieren Sie davon, wenn Sie Ihre Fähigkeiten langsam aufbauen und sich vor allem, was Tom tut, in Acht nehmen, das zu schnell und / oder zu einfach ist.

Er nimmt sich die Zeit, um Paare zu programmieren und Sie zu unterweisen. Versuchen Sie also, von ihm zu lernen.

Ich habe eine jüngere Kollegin, die viel weniger Erfahrung hat als ich (ich programmiere seit ihrer Geburt). Wir machen keine Paarprogrammierung, sondern regelmäßige Codeüberprüfungen, und nach 1-2 Monaten kann ich sehen, dass sie besser wird, bis ich schätze, dass ich mich in 1-3 Monaten aus diesem Teil des Projekts entfernen und sie lassen kann Mach es alleine.

Wenn dein Team und der leitende Entwickler die richtige Einstellung haben (um ihn nach einiger Zeit zu lernen und für andere Dinge frei zu haben), sollte die Welt in Ordnung sein.

Einige praktische Ratschläge:

• In einem Sprint sollten Sie bewerten, wie Sie die Aufgabe sehen. Das Auswerten von User Stories funktioniert nur, wenn jeder seine Meinung äußert.

• Das Festlegen einer Aufgabe bedeutet nicht, dass Sie dies ohne Hilfe tun müssen. Bitten Sie im täglichen Standup um Hilfe.

• Wenn Backlog-Storys so kompliziert werden Nur eine Person im Team fühlt sich in der Lage, die Auswirkungen und den Umfang der Geschichte zu verstehen (vorausgesetzt, Sie scrum), und dann muss die Geschichte verfeinert / aufgeteilt werden. Eine Story-Beschreibung zu haben, die vom gesamten Team nicht verstanden wird, ist nicht akzeptabel.

• Mir scheint, dass er einen Großteil der Architektur im Kopf hat, was dazu führen kann es ist furchtbar schwer zu folgen. Vielleicht können Sie die Architekturgeschichte "dokumentieren" lassen.