Was ist, wenn ich ein besserer Entwickler bin als mein Teamleiter?

Basierend auf seinen täglichen Commits sehe ich, dass er viel schlechten Code schreibt und keine guten Praktiken befolgt.

Ich habe versucht, mit ihm über bessere Methoden zum Schreiben von Code wie SOLID, DRY usw. zu sprechen (versucht, so freundlich wie möglich zu sein), und ich überprüfe immer den Code von Junior-Entwicklern, aber es fühlt sich an, als wäre es ein verlorener Kampf, denn für jede Zeile von code I umgestalten, es wird 10 neue geben und es gibt keine Verantwortung für schlechten Code.

Ich erwarte nicht, dass die Junior-Entwickler im Team über gute Praktiken Bescheid wissen, also kann ich ihnen keinen Vorwurf machen, aber der Teamleiter sollte es wissen, oder?

Was ist, wenn ich ein besserer Entwickler bin als mein Teamleiter? Wäre es empfehlenswert, als Teamleiter „seinen Platz einzunehmen“? Wenn ja, welche Ansätze wären effektiv?

"Ein Leader zu sein bedeutet mehr als nur der beste Programmierer zu sein." - @JoeStrazzere lies meine Gedanken. Teamleiter werden nicht nur durch Programmierfähigkeiten bestimmt, sondern auch, ähm, Führungsqualitäten sowie Kommunikation ... Wenn Sie besseren Code schreiben als Ihr Lead, sollten Sie sich selbst auf die Schulter klopfen und weiterhin Ihre gute Arbeit leisten. Wenn Sie tatsächlich besser sind als er, werden Ihre Bewertungen und Ihre geleistete Arbeit für sich sprechen und vielleicht letztendlich eine Beförderung für Sie bedeuten ... möchten Sie Teamleiter werden?
Best Practices werden in der Unternehmenswelt selten befolgt, und der Versuch, gewaltsam den Platz eines anderen einzunehmen, ist eine gute Möglichkeit, sich Feinde zu machen.
Ist dieser Beitrag Wunschdenken oder hast du ein konkretes Ziel? Ihr letzter Satz lässt mich vermuten, dass es der erstere ist.
Als Leiter eines Softwareentwicklungsteams versuche ich, nur Leute einzustellen, die etwas besser können als ich! Warum sollte ich sie sonst für Arbeiten bezahlen, die ich besser machen kann?
Diese Frage wird auf Meta diskutiert

Antworten (3)

Ein häufiger Fehler in der Technik ist, dass "der Teamleiter der Beste sein muss und wenn nicht, kann ich sagen, dass sie Burger sind".

Leider ist der Begriff "Teamleiter", nicht "bester Entwickler".

Stellen Sie sich das so vor: Abraham Lincoln führte den Bürgerkrieg, aber er war weder ein General noch ein großer Kämpfer. Steve Jobs führte Apple, aber er war kein großer Ingenieur.

Bei Führung geht es nicht darum, der Beste zu sein – es geht darum, andere dazu zu inspirieren, Ihnen zu folgen, ein Schiff zu führen, das viele, viele bewegliche Teile hat – von denen einige in die falsche Richtung gehen wollen, andere den Anführer ersetzen wollen! - bis zum Endziel.

Nur weil Sie ein kompetenter Ingenieur sind, werden Sie noch lange kein guter technischer Leiter oder gar Teamleiter. Wenn Sie Ihren Teamleiter nicht davon überzeugen können, Best Practices zu befolgen, welche Hoffnung haben Sie dann auf Führung?

Und welche Freude würde es Ihnen bereiten, diese Ansicht durchzusetzen? Weißt du überhaupt, warum SOLID und DRY gut sind? Ist Ihnen bewusst, dass sich Robert Martin beim Clean Coding nach den Tagen des Ausschneidens und Einfügens von Code sehnt? Ein Prinzip zu kennen und anzuwenden reicht nicht aus, um andere davon zu überzeugen, warum es gut ist. Vielleicht verkürzt dies die Entwicklungszeit, oder vielleicht ist Ihr Teamleiter der (vernünftigen) Meinung, dass ein paar Mal Code-Ausschneiden und -Einfügen viel einfacher und einfacher zu handhaben ist als ein ausuferndes Fabrikmuster-Biest, das grundlegend unterschiedliche Geschäftslogiken kombiniert .

Wenn Sie führen wollen, dann schlage ich vor, dass Sie stattdessen ein wöchentliches einstündiges Teammeeting einrichten, bei dem Sie alle durch das Ersetzen von Code führen und die Auswirkungen diskutieren - Ingenieure chatten gerne über Code, und dies ist eine gute Möglichkeit, einen Konsens zu erzielen. Oder informieren Sie sich über Agile und pushen Sie so etwas wie Kanban.

Aber tappen Sie nicht in die Falle, dass reines Können gleichbedeutend mit Führung ist. Es trifft selten auf andere Aspekte des menschlichen Lebens zu, es ist sicherlich nicht "wahrer" in der Technik. Warum sollte es sein?

Führung braucht eine Vision, und Führung braucht Vertrieb. Von den beiden ist der Verkauf der wichtigere. Die Vision bestimmt möglicherweise, wie erfolgreich Sie sind und wie gut Sie in Erinnerung bleiben – aber der Verkauf bringt Sie dorthin. Es gibt viele Führungskräfte mit wenig Vision, aber ich bin mir nicht sicher, ob es welche gibt, die nicht verkaufen können.

Soviel dazu hier! Nur weil Sie sich für einen guten Entwickler halten, sind Sie nicht automatisch eine gute Führungskraft. Nur weil Sie wissen, wie man anderen sagt, was sie zu tun haben, macht Sie das noch lange nicht zu einer guten Führungskraft. Tatsächlich würde ich sagen, dass die meisten Entwickler, die sich für „gut“ halten, kaum als mittelmäßig durchgehen würden. Es gibt nicht viele "gute" Entwickler. Heutzutage ist jeder ein Experte...
@Jeffrey: Amen. Haha 9,9 von zehn Mal, wenn ich sehe, wie Leute ihre Verdienste als Programmierer basierend auf einem subjektiven Maß wie "Qualität" des Codes mit jemand anderem vergleichen, bedeutet das, dass diese Person bestenfalls mittelmäßig ist. Wenn er jedoch harte Statistiken hätte, wie z. B., dass mein Code 2x so viel Speicher spart oder 10x so schnell lief und besser lesbar war, wäre ich dafür offen. Codequalität ist ein Luxus, den sich nur die größten der größten Unternehmen leisten können.
@ldog, ich habe immer noch Probleme mit diesen harten Statistiken. Ich kenne nicht viele Leute, die in der Lage wären, diese Zahlen genau zusammenzuziehen. Ich frage jeden, der anfängt, auch über seine zahlenmäßigen Vorzüge zu sprechen. Ich bin ein Zyniker, denke ich.

Bevor ich Ihre Fragen beantworte, ist es meiner Meinung nach wichtig zu erwähnen, dass dies kein Problem sein sollte, vorausgesetzt, Sie haben recht und Sie sind ein besserer Entwickler als Ihr Teamleiter. Ein Teamleiter muss nicht der beste Entwickler im Team sein. Er/sie sollte am besten führen, das Beste aus jedem Teammitglied (Entwickler und Nicht-Entwickler) herausholen, interne und externe Probleme lösen, die den Arbeitsfluss und die Produktivität des Teams blockieren, und der Beste darin sein, ein Team aufzubauen viele andere Dinge.

Also, Beantwortung deiner Fragen:

Sollte der Teamleiter mit Best Practices vertraut sein?

Meiner Meinung nach ja, der Teamleiter sollte mit bestimmten Best Practices vertraut sein. Noch einmal, diese Person muss nicht unbedingt ein Experte für jedes Softwareentwicklungskonzept sein, aber er/sie sollte mit vielen davon vertraut oder kompetent sein.

Was ist, wenn ich ein besserer Entwickler bin als der Teamleiter?

Nehmen wir das Beispiel einer Fußballmannschaft. Der Kapitän ist nicht unbedingt der technisch versierteste Spieler, aber er/sie ist der Beste darin, ein Team zu führen und zu leiten.

Sie können ein besserer Entwickler sein (oder auch nicht), aber höchstwahrscheinlich ist Ihr Teamleiter besser als Sie darin, viele andere Dinge zu tun, von denen Sie vielleicht nicht einmal wissen, dass diese Person sie tut.

Konzentrieren Sie sich darauf, der beste Entwickler zu sein, der Sie sein können, egal wie gut oder schlecht Sie im Vergleich zu Ihrem Teamleiter sind.

Soll ich versuchen, seinen Platz als Teamleiter einzunehmen?

Ich würde das auf keinen Fall tun.

Was soll ich machen?

Wenn Sie versucht haben, freundlich zu sein und bessere Vorgehensweisen zu erklären, und Ihr Teamleiter trotzdem auf eine Weise programmiert, mit der Sie sich nicht wohl fühlen, gibt es nicht viele einfache Wege, denen Sie folgen können. Sie können versuchen, ein ernsteres Gespräch mit ihm zu führen, immer respektvoll zu sein und Ihre Bedenken zu erklären, aber ich bezweifle sehr, dass es gut ankommen wird.

Es ist eine weitere Option, dies mit jemandem in der Kette anzusprechen, und auch dies wird selten zu Ihren Gunsten funktionieren.

Wenn die Situation so weitergeht, nachdem Sie versucht haben, mit Ihrem Vorgesetzten zu sprechen, ist es manchmal einfacher und vernünftiger, ein Team und einen Teamleiter zu finden, die Ihrer Denk- und Arbeitsweise entsprechen, anstatt zu versuchen, viele Leute davon zu überzeugen ändern oder verbessern, um sie Ihren Wünschen oder Standards anzupassen.

Wenn Sie bereits Code-Reviews durchführen, stellen Sie außerdem sicher, dass Sie den "besseren" Weg als Teil dieser Reviews markieren, er sollte Ihre Kritik entweder berücksichtigen oder zumindest erklären, warum er seinen Ansatz gewählt hat (es kann sein Faktoren, die Sie nicht kennen). Und wenn Sie nicht bereits Code-Reviews durchführen, MÜSSEN Sie Code-Reviews durchführen.

Ich stimme den vorhandenen Antworten zu: dass es kein Problem sein muss, dass ein Teamleiter / Entwicklungsmanager möglicherweise nicht der beste Entwickler im Team ist. Führungs- und Managementfähigkeiten haben nicht unbedingt große Überschneidungen mit robusten Fähigkeiten in der Softwareentwicklung.

Der Grund, warum sich diese Antwort von ihrer unterscheidet, ist jedoch, dass ich denke, dass hier immer noch ein Problem besteht:

Für jede Codezeile, die ich umgestalte, gibt es 10 neue

Ich denke, es ist in Ordnung für einen Teamleiter, ein weniger als herausragender Programmierer zu sein, wenn er nicht viel codiert oder sich auf den kritischen Pfad begibt (dh wenn er seiner Führungsrolle Vorrang vor der Entwicklung einräumt), aber es klingt so, als ob er es wäre In diesem Fall ist er es.

In diesem Fall schlage ich vor, dass Ihre Frage nicht so sehr lautet „Was ist, wenn ich ein besserer Entwickler bin als mein Teamleiter?“, sondern „Wie kann ich angesichts des Widerstands von etablierten/älteren Entwicklern Best Practices einführen?“

Das ist knifflig und braucht Geduld. Code-Reviews sind ein Schritt in die richtige Richtung, ebenso wie statische Analysetools, Unit-Tests und so weiter – obwohl es eine Herausforderung sein kann, ihre Verwendung zu akzeptieren. Es gibt andere Antworten auf solche Fragen, die es wert wären, untersucht zu werden.

Wenn ich laut nachdenke, frage ich mich auch, ob sich Ihr Teamleiter möglicherweise unter Druck fühlt, neben der Führung des Teams auch weiterhin zu programmieren. Es kann sein, dass er das Gefühl hat, genauso produktiv sein zu müssen, wie er es war, als er „nur“ ein Programmierer war, und außerdem seine Führungsrolle erfüllen muss. Vielleicht könnte ein vermeintlicher Zeitmangel für die schlechte Qualität seiner Check-Ins verantwortlich sein; Vielleicht braucht er mehr Vertrauen in sein Team, um die Arbeit zu erledigen, während er sich zurückhält. Ich weiß es nicht, aber es könnte sich lohnen, die Situation aus seiner Sicht zu betrachten - vielleicht sogar informell mit ihm zu diskutieren, nur um ihn auszuhorchen ("Guten Morgen Chef - also, hast du heute viel zu tun?" könnte ein Auge sein -Öffnung!). Dies wird helfen zu erfahren, ob er ein schlechter Programmierer ist, der nicht er weiß es nicht einmal, hat aber die Befugnis, jeden zu überstimmen, der darauf hinweist (eine sehr schwierige Situation, mit der man fertig werden muss), oder war einmal ein guter Programmierer, aber seine Führungsverantwortung bedeutet, dass er keine Zeit mehr hat, es richtig zu machen, und er muss nur lernen, dich und den Rest der Zeit damit umgehen zu lassen. Wenn Sie dies besser verstehen, wird Ihr Weg möglicherweise klarer.

Wäre es empfehlenswert, als Teamleiter „seinen Platz einzunehmen“?

Nein.

Wenn Sie eine Führungsrolle als nächsten Schritt in Ihrer Karriere sehen, dann arbeiten Sie auf jeden Fall darauf hin, Teamleiter zu werden (was eines Tages bedeuten kann, dem aktuellen Teamleiter nachzufolgen, aber das ist etwas weniger aggressiv, als sich „versuchen, seinen Platz einzunehmen“ anhört !). Ich persönlich würde hier ansetzen .

Wenn, OTOH, Sie nur der beste Entwickler sein wollen, der Sie sein können, und Sie in die Falle getappt sind zu denken, dass Teamleiter eine Belohnung oder Anerkennung dafür ist, der beste Entwickler zu sein, konzentrieren Sie sich stattdessen darauf, die Praktiken sowohl in sich selbst als auch übergreifend zu verbessern das Team, und überlassen Sie die Führung und das Management denen, die führen und verwalten wollen. (In dieser Rolle geht es viel mehr um Menschen als um das Programmieren, oder es sollte sich um sie handeln). Dies könnte helfen, den Unterschied zu erkennen.