Senior Manager trat in die Rolle eines Softwareentwicklers ein und schneidet schlecht ab [geschlossen]

TL;DR: Der Mitbegründer des Unternehmens möchte „richtige Arbeit“ leisten, schadet aber mehr als er nützt.

Das Unternehmen ist ein Softwarehaus mit Sitz in Großbritannien, beschäftigt rund 20 Mitarbeiter, macht stabile Gewinne, zahlt gut und bietet hervorragende Arbeitsbedingungen (freundliche Atmosphäre, Sozialleistungen usw.).

Sie haben mich vor 3 Monaten eingestellt, um ein neues, ehrgeiziges und langfristiges Projekt zu starten. Derzeit sind insgesamt 3 Personen an dem Projekt beteiligt: ​​ein weiterer Spezialist und ein Senior Manager (Mitbegründer des Unternehmens). Es gibt keine Managerrollen – wir alle machen die „richtige Arbeit“ und wir sind alle gleich (z. B. Entscheidungen werden durch Abstimmung getroffen).

Das Problem ist, dass der Mitbegründer kein erfahrener Programmierer ist. Vielleicht war er das einmal, aber wahrscheinlich hat er im Laufe der Jahre, in denen er nicht als Softwareentwickler gearbeitet hat, an Zugkraft verloren. Er diskutiert gerne Dinge von geringer Bedeutung (z. B. Programmierstil), aber wenn es ums Programmieren geht, macht er schreckliche Fehler. Ich bin es leid, jedes Stück seiner Arbeit doppelt zu überprüfen.

Ich kann mich über ihn als Person nicht beschweren (z. B. zeigt er keine Anzeichen von Unhöflichkeit, Eifersucht usw.), es fehlt ihm einfach an Fähigkeiten. Deshalb behebe ich seine Fehler normalerweise heimlich während Merges, aber ich vermute, dass dies auf Dauer keine richtige Lösung ist.

Da ich offensichtlich NICHT in der Lage bin, ihn zu beraten, wie soll ich vorgehen? Soll ich mit ihm reden? Oder besser loslassen und auf die Katastrophe warten? Wenn das wichtig ist, sprechen wir über einen eng spezialisierten Bereich der Softwareentwicklung und der betreffende Typ ist etwa 10 Jahre älter als ich. Er ist auch ein CS-Absolvent.

EDIT: Beantwortung der Fragen in Kommentaren: Wir arbeiten in einer Nische, ziemlich schwierige Technologie. Erwähnte Fehler sind einfache Fehler, wie die Verwendung nicht initialisierter Variablen.

Dinge von untergeordneter Bedeutung (z. B. Programmierstil) bei mehreren Entwicklern ist dies nicht mehr von untergeordneter Bedeutung, wenn Sie die Arbeit des anderen verstehen möchten :-| Ich habe Projekte gesehen, bei denen man erkennen konnte, welcher Teil des Codes von wem geschrieben wurde. Das sah lustig aus (aber war pures Chaos) - sie haben anscheinend nie darüber gesprochen. Trotzdem ist dies ein interessantes Thema. Ich würde einfach mit ihm reden, aber ich rede mit jedem über alles :-] Ich bin gespannt, was andere sagen werden...
Wenn Sie alle gleich sind, warum tun Sie es, so dass Sie ihn offensichtlich nicht beraten können? Es klingt so, als ob Sie entweder nicht wirklich gleichberechtigt sind oder in der Lage sein sollten, ehrlich zu ihm zu sein.
" ... ein Senior Manager (Mitbegründer des Unternehmens). Es gibt keine Managerrollen - wir alle machen die 'richtige Arbeit' und wir sind alle gleich" - was auch immer Sie sich sagen möchten, Sie sind nicht alle gleich. Je früher Sie das erkennen, desto besser.
Eine nicht verwendete Variable ist nicht immer ein "Fehler", es kann eine schlechte Praxis sein, aber abhängig vom Code ist es nicht immer erforderlich
Eine Firma, in der ich arbeitete, hatte einen CTO, der wahrscheinlich einer der besten Ingenieure war, die ich in meinem Leben gesehen habe, aber er hatte schreckliche Angewohnheiten, wie z. B. das Nichteinrücken seines Codes und das Verwenden aussagekräftiger Variablennamen. Nicht ein einziges Mal habe ich sein Können eingesackt, weil ich es nachvollziehen konnte. Ich habe oft vergessen, wo ich geparkt habe, als ich den kompliziertesten Code geschrieben habe. Sie werden feststellen, je tiefer der Denker ist, desto mehr wird er zu einem Dummkopf. Es ist schwer jemandem zu erklären, der das nicht erlebt hat.

Antworten (1)

Zusammenfassung

  • Verwenden Sie Code Quality-Software
  • Einführung von Pull-Requests und Peer-Reviews
  • Schreiben Sie alle anderen Fehler auf, die Sie finden

Die Antwort

Das Gute ist, dass Dinge von geringer Bedeutung normalerweise automatisiert werden können, insbesondere der Codierungsstil. Sehen Sie, wie viel davon von Ihrem Build-System verarbeitet werden kann. Die Einführung eines Codequalitätsmonitors (z. B. Sonarqube oder ähnliches) wird sich auf der ganzen Linie auszahlen , insbesondere in einem jungen Projekt wie Ihrem.

Zeigen Sie, dass der Code gebrochen ist. Indem du das Zeug im Geheimen reparierst

  • ihm die Gelegenheit nehmen, zu wissen, dass er es vermasselt hat
  • lass ihn sich falsche Vorstellungen über seine eigenen Fähigkeiten machen
  • Lassen Sie sich von ihm falsche Vorstellungen über Sie als Fachmann, Ihre fachlichen Fähigkeiten sowie Ihre Soft Skills bei der Kommunikation von Problemen machen.

Sie sind nicht in der Position, ihm Ratschläge zu erteilen, aber Sie können auf das Problem hinweisen und das Gespräch dorthin lenken, wo Sie es möchten.

Für kleine Dinge wie nicht initialisierte Variablen ist ein Codequalitätsmonitor oder ein statischer Analysator äußerst hilfreich. Einmal eingerichtet, müssen Sie sich nur noch auf das Niveau der Codequalität einigen, das Sie für das Projekt wünschen.

Bei größeren Problemen würde ich für jeden Fehler, den ich finde , einen Komponententest oder ein Ticket erstellen. Sobald ich einen Haufen davon habe, würde ich auf den wachsenden Haufen hinweisen und fragen, wie wir planen, damit umzugehen. Jetzt ist ein guter Zeitpunkt, um Scrum vorzustellen, wenn Sie ein Fan sind.

Abhängig von der Beziehungsdynamik können Sie die meisten Reparaturen immer noch selbst vornehmen, aber er wird sich des Problems bewusst sein und Sie können den Zeitaufwand abschätzen, wenn Sie dies jemals tun müssen.

Schließlich, um ehrlich zu sein, klingt er wie ein Typ, der Kritik vertragen kann, also würde ich das auch untersuchen. Integrieren Sie Pull-Requests und Peer-Review in Ihren Workflow und sehen Sie, wie es läuft.

Wie man vorgeht

Nicht jeder denkt, dass er Codequalitätsmonitore braucht. Wenn Sie es nicht direkt verkaufen können, müssen Sie möglicherweise einige Überstunden machen, um es einzurichten, und dann darauf hinweisen, was für eine große Hilfe es war, und vorschlagen, es zu übernehmen. Auch hier wird Ihre Laufleistung je nach Ihrem Chef variieren; Meiner Erfahrung nach ist Demonstrieren immer besser als Verkaufen (aber ich bin ein schlechter Verkäufer).

So viel Arbeit, nur um einem Typen zu sagen, dass er im Programmieren scheiße ist ;-] Warum haben die Leute immer Angst, mit jemandem zu reden, wenn sie wissen, dass etwas nicht stimmt?
@red-shield Weil wir Entwickler sind und unsere zwischenmenschlichen Fähigkeiten gegen Null gehen :) Das kümmert sich um das Soft-Skills-Problem und wird dem Projekt in Zukunft helfen. Aber ich stimme zu, manchmal ein Plan -Typ, du bist scheiße, nicht wahr, wirkt Wunder
Der Vorschlag von @red-shield Rath tut viel mehr, als nur einer bestimmten Person zu sagen, dass ihr Code scheiße ist – er führt QA-Checks und -Balances ein, die den gesamten Softwareproduktionsprozess verbessern. Das ist eine gute Sache™ und wenn es richtig implementiert ist, entfällt die Notwendigkeit, einer Person sagen zu müssen, dass ihr Code scheiße ist.
Senior Manager trat in die Rolle eines Softwareentwicklers ein und schneidet schlecht ab [geschlossen]
AntwortenHierDatenschutz-Bestimmungen1y, 0v