Solo .NET Programmer wechselt zu einem Team

Ich war in den letzten 8 Jahren ein Solo-.NET-Programmierer für ein kleines Startup. Ich habe eine ziemlich anständige Software zusammengestellt, und ich habe mich immer bemüht, mich zu verbessern und mich an die Best Practices zu halten, einschließlich der Quellcodeverwaltung (SVN / TFS). Ich habe sehr eng mit einem Team von Ingenieuren anderer Disziplinen zusammengearbeitet, aber wenn es um die Software ging, war ich die einzige, die programmierte. Ich liebe das Handwerk des Programmierens und liebe es, neue Dinge zu lernen, um meine Werkzeuge zu schärfen.

In zwei Wochen starte ich einen neuen Job in einem Team von 20 .NET-Entwicklern. Meine Position wird mittelgroß sein und ich werde unter einigen Programmierern mit unglaublich beeindruckendem Hintergrund arbeiten. Auch hier wird der Teamaspekt der Entwicklung für mich neu sein, daher suche ich nach allgemeinen Tipps für "neue Leute", mit denen ich von Anfang an so effektiv und einfach wie möglich zurechtkomme.

Alles ist möglich, einschließlich Tipps auf hohem Niveau und kleiner Alltagsgegenstände zur Kommunikation.

Meistens gesunder Menschenverstand, aber mein Rat wäre:

Verbringen Sie in der ersten Woche so viel Zeit mit Menschen wie mit Technikern. Verschwenden Sie nicht den ersten Tag damit, Ihren Desktop oder andere Dinge, die Sie vom Team isolieren, anzupassen. Lernen Sie so viele Kollegen wie möglich so schnell wie möglich kennen.

Versuchen Sie schnell herauszufinden, wer die Arbeitspferde und wer die Penner sind. Vermeiden Sie die Penner so viel wie möglich, jedes Team hat sie und Sie wollen nicht als einer eingestuft werden.

Nehmen Sie in den ersten Wochen an gesellschaftlichen Veranstaltungen teil, auch wenn Sie nach der Arbeit oder dem Mittagessen nur ein Bier trinken.

Hören Sie zu und schreiben Sie Dinge auf. Bitten Sie Kollegen, Beschreibungen von Vorgängen zu wiederholen, um sie zu ärgern.

Verbringen Sie die ersten 3 bis 6 Monate damit, sich vertraut zu machen, und empfehlen Sie Änderungen an Prozeduren / Architekturen / etc. Sie funktionieren anders als Sie und einige Elemente sind möglicherweise schlecht - aber es gibt Gründe dafür und sie sind selten auf Nachlässigkeit oder Unwissenheit zurückzuführen.

Ich bezweifle, dass die Programmierseite tatsächlich ein Problem sein wird.

• Lernen! Neue Programmierer kennenzulernen ist eine großartige Möglichkeit, neue Tricks zu lernen. Wenn Sie ihnen beim Tippen zusehen, lernen Sie ein paar Editor-Tricks, und wenn Sie sich ihren Code ansehen, erhalten Sie neue Ideen.

• Belästigen Sie Ihre Kollegen nicht alle fünf Minuten, aber wenn Sie wirklich festsitzen, zögern Sie nicht, um Hilfe zu bitten. Zu viele Programmierer sitzen zwei Tage lang an einem Programm fest, bei dem die Frage, ob Ihr Nachbar es in einer Stunde gelöst hätte.

• Codekriege sind Religionskriege. Die Syntax könnte dort etwas anders sein (fügen Sie Klammern zu einzelnen Zeilenanweisungen hinzu?), Aber es lohnt sich selten, darüber zu streiten.

• Sozialisieren. Wenn sie jede Woche etwas trinken, sollten Sie unbedingt dabei sein. Das kann so einfach sein, als würde man zusammen essen .

Spielen Sie Devil's Advocate und ich sage, stellen Sie sicher, dass Ihre Teamkollegen kompetent sind. Nichts ist schlimmer als in einem Team zu arbeiten, in dem niemand außer Ihnen irgendetwas "richtig" macht, weil Sie immer zahlenmäßig unter den Leuten sind, die etwas falsch machen wollen.

Sie erwähnen die Arbeit unter Entwicklern mit beeindruckendem Hintergrund, das klingt also vielversprechend. In diesem Fall ermutige ich Sie, zu lernen, was Sie können, aber vergessen Sie niemals, was Sie bereits für die "Herdenmentalität" wissen. Wenn alle anderen etwas falsch machen und Sie es richtig machen, gehen Sie keine Kompromisse ein.

Zusätzlich zu Jonno würde ich sagen:

Seien Sie auf Veränderungen vorbereitet. Jedes Team arbeitet anders. Gute SW-Teams haben Codierungsregeln. Seien Sie bereit, sie anzunehmen, auch wenn sie anfangs seltsam erscheinen.

Seien Sie bereit für viel mehr Kommunikation. Wenn Sie alleine arbeiten, sind viele Detailinformationen in Ihrem Kopf. Sobald Sie in einem Team arbeiten, müssen diese Details (zumindest einige davon) geteilt und kommuniziert werden, und dafür ist Zeit erforderlich.

Höre mehr zu als du redest.

Stellen Sie mehr Fragen, als Sie zu beantworten versuchen (es sei denn, die Fragen richten sich an Sie). Die "Oldtimer" im Team werden anhand der von Ihnen gestellten Fragen wissen, wie weit Sie beim Erlernen des Codes sind. Sie haben wahrscheinlich eine mentale Liste von Fragen, die sie erwarten.

Schreiben Sie Ihren Code so, dass er zum vorherrschenden Stil passt. Dies gilt für Bereiche, in denen Sie Leerzeichen, geschweifte Klammern, Großbuchstaben, die Länge von Variablennamen, die durchschnittliche Größe von Methoden, die Dichte von Kommentaren und alles andere einfügen, was keine Rolle spielen sollte. Wenn Sie einen guten Grund haben, etwas anders zu machen, fragen Sie einen der Oldtimer, warum das Team den vorgegebenen Stil hat. Sie können einige interessante Dinge über die Teamgeschichte und Persönlichkeiten lernen. Das bringt mich zum nächsten Punkt.

Lerne die Team-Überlieferung. Höchstwahrscheinlich ist keine der Überlieferungen aufgeschrieben, aber es ist allgemein bekannt im Team. Die Überlieferung des Teams enthält die Geschichte, wie das Projekt zu seinem aktuellen Stand gekommen ist, Fehler, die in der Vergangenheit gemacht wurden, Erfolge, die in der Vergangenheit gemacht wurden, Lehren, die auf diesem Weg gezogen wurden. Es wird in kurzen Aussagen wie "klingt wieder wie der Frobnitz-Bug" erwähnt. Wenn Sie sehen / hören, dass Teammitglieder mit einem kryptischen Kommentar einverstanden sind, ist wahrscheinlich Teamkunde beteiligt. Frag jemanden.

Kritisieren Sie Code erst, wenn Sie die Persönlichkeiten und die Geschichte kennen. Sie wissen nicht, wen Sie beleidigen könnten.

Stellen Sie Fragen und hören Sie sich die Antworten an. Denken Sie über die Antworten auf vorherige Fragen nach, bevor Sie die nächste Frage stellen, damit Sie versuchen können, eine Antwort vorwegzunehmen.

Bemühen Sie sich, die bestmögliche Arbeit zu leisten. Gewöhnen Sie sich daran, sich zu fragen, was andere im Team von Ihrem Code halten, wenn sie ihn nächsten Monat ändern müssen.

Wenn Sie ein Problem sehen, das behoben werden muss, geben Sie Ihr Bestes, um eine angemessene Lösung anzubieten, bevor Sie Bedenken über das Problem äußern. Übernehmen Sie die Verantwortung für die Implementierung einer Lösung, wenn Sie auf ein Problem hinweisen.