Probleme von Junior-Entwicklern: Wie kommuniziert man mit dem Management?

Nach zwei Wochen kann ich mit Zuversicht sagen, dass ich eindeutig keinen Wert für dieses Unternehmen geschaffen habe und die anderen Entwickler, die mir geholfen haben, meine Arbeit hätten erledigen können, anstatt Zeit mit mir zu verbringen.

Sie werden nicht viel länger einen "positiven Nettowert" für das Unternehmen schaffen (selbst wenn ich leitende Entwickler einstelle, gehe ich davon aus, dass sie 6 Monate lang keinen positiven Nettowert haben).

Alles, was Sie in Ihrer Frage erwähnt haben, sind eigentlich gute Zeichen - es hört sich so an, als würden sie interessante und nicht triviale Software entwickeln, was bedeutet, dass Sie viele Möglichkeiten zum Lernen haben, und es bedeutet, dass sie in Sie investiert werden - indem sie Ihnen die Zeit geben und Platz, um auf Touren zu kommen.

Das Schreiben von Unit- und Integrationstests ist ein recht verbreiteter Weg, um neue Nachwuchskräfte einzuarbeiten. Sie lernen die IDE, das Versionskontrollsystem, den Erstellungsprozess und all die verschiedenen formellen und informellen Arbeitsabläufe bei der Entwicklung von Software kennen, während Sie sich auf relativ kleine Arbeitseinheiten konzentrieren. Sie lernen auch viel über die Geschäftsfunktionen, die ihre Software bietet.

1 - Ist es normal?

Ja. Sie sind kein Betrüger, und es gibt keinen Grund zu der Annahme, dass es eine schlechte Idee war, in dieses Feld einzusteigen. Aufgrund der Tatsache, dass sie Sie eingestellt haben und in Sie investieren wollen, scheint es sogar eine gute Idee zu sein. Das Wichtigste ist, den naiven Glauben zu überwinden, dass Sie, nur weil Sie in Ihrem Bootcamp „wohl der Beste“ waren, bereit waren, am ersten Tag in eine Entwicklungswerkstatt zu gehen und mit der Wertschöpfung zu beginnen. Das Bootcamp hat Ihnen die grundlegenden Grundlagen des Programmierens vermittelt - es gibt noch viel, viel, viel mehr, um ein professioneller Entwickler zu sein, was Sie nur im Job lernen können.

2 - Was kann ich besser machen?

Ich denke, es gibt zwei "Bereiche" dafür. Das erste sind Dinge, die Sie selbst tun können. Investieren Sie Ihre eigene Zeit in das Erlernen der Sprache, in der Sie programmieren - die Feinheiten, die erweiterten Funktionen usw. Selbst wenn Ihr Bootcamp in derselben Sprache war, an der Sie jetzt arbeiten, gibt es viel zu lernen (ich war es Programmiere seit >10 Jahren in derselben Hauptsprache und lerne immer noch jeden Tag neue Dinge). Wenn eines der anderen Tools, die sie verwenden, öffentlich/frei verfügbar ist (die IDE, das Quellcodeverwaltungstool), üben Sie auch mit diesen. Verbringen Sie auch Zeit damit, sich mit den Grundlagen der Informatik (Algorithmen, Datenstrukturen) vertraut zu machen. Auch wenn Sie dieses Wissen nicht sofort anwenden, wird es immer hilfreich sein.

Die zweite, die zwar nicht speziell mit den von Ihnen durchgeführten Tests zusammenhängt, kann jedoch als Teil dieser Arbeit durchgeführt werden. Das heißt, die Fähigkeit zu entwickeln, ein Stück Code zu „analysieren“. Machen Sie den einfachsten Test, den Sie finden können, testen Sie das einfachste Stück Code und versuchen Sie, den Kontrollfluss dieses Stücks Code auszuarbeiten. Führen Sie es durch einen Debugger, halten Sie bei jeder Zeile an und sehen Sie, was es tatsächlich tut. Modifizieren Sie den Test leicht und sehen Sie, wie er sich anders verhält. Versuchen Sie, einen Test zu entwickeln, der einen anderen if-Zweig (usw.) testet. Verwenden Sie Ihr IDE-Versionsverwaltungstool und sehen Sie sich das letzte Commit an, das diesen Code geändert hat. Prüfen Sie, ob Sie nachvollziehen können, was diese Änderung bewirkt hat (besonders hilfreich, wenn Sie auf das Ticket verlinken können, das diese Änderung dokumentiert hat). Wechseln Sie zu einem etwas komplexeren Test und wiederholen Sie ihn. Nehmen Sie jetzt das Stück Code, das Sie testen sollen, und führen Sie diese Analyse im Voraus durch. Verwenden Sie das, um Ihren ersten Test zu schreiben.

Wenn Sie Hilfe benötigen, fragen Sie den Autor des gesuchten Tests oder Codes, um Ihnen einen Überblick zu verschaffen.

3 - Wie könnte ich dies (oder einen Teil davon) dem Management und den Kollegen mitteilen, ohne als Betrug rüberzukommen?

Niemand wird mit dem Wissen geboren, wie man codiert. Deshalb haben Ihre Kollegen und Vorgesetzten alle an einem ähnlichen Ort angefangen wie Sie. Solange sie keine Idioten sind (und du hast bereits gesagt, dass sie es nicht sind), wissen sie Bescheid und erwarten, dass du sie um Hilfe bittest.

Natürlich müssen Sie die richtige Balance finden zwischen zu vielen Fragen und nicht früh genug um Hilfe zu bitten. Ich habe meinen Juniors oft gesagt: „Verschwende nicht 3 Stunden damit, etwas herauszufinden, bei dem ich dir in 5 Minuten helfen kann“. Verschwenden Sie andererseits nicht meine 5 Minuten, wenn Sie nicht einige Zeit damit verbracht haben, es selbst herauszufinden.

Wenn Sie noch keines geplant haben, bitten Sie Ihren Vorgesetzten um ein wöchentliches 30-minütiges Meeting. Um eine andere Antwort zu zitieren, die ich hier geschrieben habe:

die Aufgabe Ihres Vorgesetzten [ist], sein Bestes zu geben, um Ihnen die Möglichkeit zum Erfolg zu geben - dies kann nur geschehen, wenn Sie beide regelmäßig und häufig Gespräche führen und wenn Sie während dieser Gespräche offen und ehrlich sagen, wo Sie Schwierigkeiten haben, wo du Unterstützung brauchst, wo du nicht weiterkommst und wo du erfährst, was er/sie von dir erwartet.

Eine der wichtigsten Fragen ist: „Wo soll ich anfangen“ und „Wen soll ich um Hilfe bitten“

Viel Glück!

Ich habe dort nur 2 Wochen gearbeitet

Sie müssen ihm viel mehr als nur 2 Wochen geben.

• Jeder fühlt sich ein bisschen überfordert, wenn er zum ersten Mal mit einem Programmierjob beginnt.
• In den ersten Wochen/Monaten werden Sie viele Dinge verlernen, die Ihnen in der Schule/im Bootcamp beigebracht wurden, und lernen, wie echte Softwarearbeit ausgeführt wird.
• Niemand versteht den ganzen Code auf den ersten Blick. Manchmal ist vorhandener Code schlecht kommentiert und für alle außer dem ursprünglichen Autor nicht entzifferbar.

Gehen Sie die Dinge schrittweise an. Sie werden mit ziemlicher Sicherheit feststellen, dass jede Woche ein bisschen angenehmer ist als die letzte.

Profitieren Sie von der netten und freundlichen Kultur. Bitten Sie um Hilfe, wenn Sie sie brauchen.

Und sei nicht so hart zu dir. Wenn Sie das Programmieren selbst gelernt haben und dann im Bootcamp brillant waren, werden Sie höchstwahrscheinlich mit etwas mehr Geduld und harter Arbeit zurechtkommen.

Willkommen im Dschungel. :)

Ja. Es ist normal. Du bist ein Junior. Es wird erwartet, dass Sie keine Ahnung haben, und deshalb lassen sie Sie tun, was Sie tun.

Fragen stellen. Holen Sie sich das Verständnis. Fragen Sie, was Sie in Ihrer Freizeit lesen können, um ein besseres Verständnis zu entwickeln. Sei bereit, hart zu arbeiten, auch wenn du ein paar Stunden außerhalb der Arbeit verbringst. Ich würde mir Sorgen um einen Junior-Entwickler machen, der KEINE Fragen stellt. Ich würde wetten, dass jeder Ihrer Kollegen, der Senior ist, genauso angefangen hat wie Sie.

Stellen Sie Fragen und lernen Sie. Mit der Zeit müssen Sie keine Fragen mehr stellen. Es wird nur klicken und Sie werden es bekommen.

Wie alle sagen, zwei Wochen sind nichts. Sie werden viel länger brauchen, um auf den neuesten Stand zu kommen. Und Ihr Vorgesetzter und Ihre Kollegen erwarten dies.

Ich möchte einen Satz zum Kommentieren herausgreifen:

Mein Problem ist, dass ich Tests für Methoden schreiben muss, die ich meistens nicht verstehe, ich verstehe nicht immer, welche Parameter sie nehmen müssen, was sie zurückgeben, ...

Aus meiner Sicht ist dies ein Dokumentationsfehler . Was auch schrecklich üblich ist. In einer idealen Welt sollte es eine Beschreibung all dessen geben, was verfügbar ist, aber sehr oft gibt es das nicht.

Ihre erste Frage sollte also sein, ob Sie eine Dokumentation verpasst haben. Die wahrscheinlichste Antwort ist "nein", aber es lohnt sich zu fragen.

Ich würde vorschlagen, diese Dokumentation zu schreiben , bevor Sie Unit-Tests durchführen. Dies ermöglicht die Frage "Habe ich den Zweck dieser Funktion richtig verstanden?" Die Dokumentation selbst ist für das Unternehmen wertvoll, und die Komponententests testen eher, was sie testen sollten.

Es kann schwierig sein, den Mut aufzubringen, einen vielbeschäftigten Kollegen mit einer wahrscheinlich trivialen Frage zu unterbrechen. Wie es sich gehört, sind Unterbrechungen scheiße.

Stattdessen sollten Sie einen Termin vereinbaren. So gibt es nur eine Unterbrechung statt viele. Wenn Sie eine Frage haben, die Ihre Arbeit blockiert, legen Sie diese beiseite und suchen Sie sich eine andere Aufgabe.

Bereiten Sie sich auf das Meeting vor. Haben Sie eine Liste mit Fragen, genaue Verweise auf relevante Quellen oder Dokumente, die beteiligt sind, und so weiter.

Am Anfang werden Sie viele solcher Treffen brauchen, aber es wird besser, wenn Sie mit allem vertrauter werden.

1 - Ist es normal?

Ja. Dasitzen, verwirrt auf fremden Code starren und sich fragen, was man da tut, ist auf allen Ebenen normal, auch nach jahrzehntelanger Erfahrung. Was sich ändert, ist, wie Sie damit umgehen.

2 - Was kann ich besser machen?

Weiter so. Zwei Wochen sind wirklich kein Grund zur Sorge. Ich war einmal Teamleiter / leitender Entwickler für eine Anwendung wie Ihre, und neue Leute brauchten mehr als zwei Monate , um einigermaßen produktiv zu werden, manchmal dauerte es Jahre. Es kann eine Woche oder länger dauern, bis die Entwickler ihre Entwicklungsumgebung initialisieren und in der Lage sind, den Quellcode für ältere Anwendungen zu kompilieren, und weitere Wochen, um sie auf ihrem Laptop zum Laufen zu bringen. Usw.

3 - Wie könnte ich dies (oder einen Teil davon) dem Management und den Kollegen mitteilen, ohne als Betrug rüberzukommen?

Sie sprechen nicht darüber, wie Sie sich als Betrüger fühlen; Sie sprechen sachlich über die anstehende Aufgabe. Versuchen Sie, mögliche Lösungen zu erarbeiten, und wenn Sie sich nicht selbst entscheiden können, fragen Sie Ihren Chef oder leitenden Entwickler. Wenn das bedeutet, dass Sie Ihren Kollegen den ganzen Tag fragen müssen, dann ist das so. Wenn Ihr Kollege Ihnen das Gefühl gibt, dass es zu viel ist, dann fragen Sie Ihren Chef, wen Sie sonst noch fragen können, oder ob er andere Informationsquellen hat oder ob er damit einverstanden ist, dass Sie sich viel Zeit nehmen, um herumzustolpern dunkel.

Seien Sie transparent; Stellen Sie sicher, dass Ihre „Stakeholder“ wissen, was Sie tun. (Es ist eine Kunst, dies so zu tun, dass es nicht jedem auf die Nerven geht - vielleicht ein Thema für eine andere Frage; eine Möglichkeit wäre, einen One-Pager zu führen, den Sie aktuell halten und nur einmal pro Woche oder alle zwei Jahre herumschicken Woche oder so ähnlich. Hängt auch wirklich von Ihrer Unternehmenskultur ab.)

Dies ist eine Einbahnstraße. Den Neuen auf undokumentierten Quellcode zu werfen, ist eine nette Übung, um die "Säfte zum Fließen zu bringen", aber am Ende des Tages würde niemand erwarten, dass hier Magie passiert.

Wenn Sie konkrete technische Fragen haben, fragen Sie besser in einer der eher technischen Stack-Börsen.

Ich habe an einigen massiven und alten Codebasen gearbeitet (3D-CAD in C++, von denen einige automatisch aus FORTRAN generiert wurden) und ich bin seit über 35 Jahren hauptsächlich Entwickler. Alles Negative, was ich unten sage, kommt von Gefühlen und Situationen, in denen ich war!

Wie andere schon sagten, du bist nicht allein. Ich habe ähnliche Ratschläge wie Stig, aber mit einigen wichtigen Nuancen.

Erstens ist es für Ihr Selbstwertgefühl und möglicherweise für Ihren Job wichtig zu zeigen, dass Sie nicht nur dasitzen und auf Code starren und sich verloren fühlen.

Es gibt drei Dinge, die Sie schreiben können, um zu zeigen, was Sie tun:

1. Schreiben Sie ein Tagebuch, auch wenn es nie jemand anderem gezeigt wird. Wenn Sie denken, dass Sie Ihr Tagebuch anderen zeigen werden, führen Sie ein privates Tagebuch, in dem Sie Ihrem zukünftigen Ich beschreiben, wie Sie sich verlaufen haben oder ob Sie an diesem Tag etwas verstanden haben.
2. Schreiben Sie echte Tests, auch wenn es dumme triviale sind, die ein bisschen Code üben. Wenn Sie die Einschränkungen für Parameter nicht verstehen, machen Sie sich etwas vor, damit der Test ausgeführt wird, und dokumentieren Sie diese Einschränkungen. Stellen Sie sicher, dass die Tests eine Readme-Datei oder ein zentrales Dokument enthalten, damit jemand anderes leicht damit beginnen kann, sie auszuführen.
3. Wie andere vorgeschlagen haben, schreiben Sie eine Dokumentation. Abhängig von der Sprache sollten Sie in der Lage sein, eine Art automatisches Dokumentationstool wie Doxygen zu erhalten, das allgemeine Anrufdiagramme generiert. Wenn Sie dies nicht können, beginnen Sie mit einem Stück Code und verfolgen Sie zurück, wo es verwendet wird. Wenn Sie den Code ausführen und einen Debugger aufrufen können, verwenden Sie Haltepunkte, um eine Aufrufliste bis zu diesem Punkt anzuzeigen. Wenn Sie manuell suchen müssen, wählen Sie etwas mit eindeutigen Namen aus, damit Sie die gesamte Codebasis durchsuchen können.

Dinge zu vermeiden

Kritisieren Sie nicht ihre bestehenden Dokumentationspraktiken. Dies ist ein Bereich, der oft sehr umstritten ist. Die Leute haben vielleicht ihre eigenen starken Meinungen und wurden abgelehnt. Sie wären erstaunt , wie tief die Gefühle in Bezug auf Dokumentationspraktiken (und das Schreiben von Tests) sein können.

Frag niemanden um Rat und scheine ihn zu ignorieren. Wenn Ihnen jemand einen Rat gibt und Sie nicht verstehen, wie Sie ihn anwenden sollen, denken Sie darüber nach und schreiben Sie zumindest einige Notizen darüber, wie Sie versucht haben, ihn anzuwenden.

Versuchen Sie nicht, alles zu verstehen. Nur nicht . Dies ist wahrscheinlich die größte Schwäche des begrenzten Codes, dem Menschen in der Ausbildung ausgesetzt sind (nicht nur Bootcamps). Nur sehr wenige Orte bringen Ihnen das Programmieren bei, ohne zu erwarten, dass Sie alles verstehen. Das ist in großen Programmen einfach nicht möglich. Lass das Bedürfnis zu verstehen los.

Ich denke, dass ich mich blamiere, wenn ich eine Frage stelle, also neige ich dazu, viel hängen zu bleiben, auf den Bildschirm zu starren und zu versuchen, einen Sinn in dem zu finden, was ich lese.

Ich denke, das ist der einzige Punkt, an dem Sie falsch liegen. Neue Leute müssen viele Fragen stellen, so können erfahrene Leute leicht einschätzen, was Sie als Nächstes wissen müssen.

Wenn Sie feststellen, dass Sie auf den Bildschirm starren, schreiben Sie eine E-Mail (oder eine Slack-Nachricht oder was auch immer). Behandeln Sie es wie eine Stack Overflow-Frage; Beschreiben Sie das Problem und was Sie getan haben, und zeigen Sie, dass Sie sich Mühe gegeben haben. In der Hälfte der Fälle kann dies etwas vorschlagen, das Sie noch nicht ausprobiert haben, oder ein Thema, zu dem Sie recherchieren können, und Sie müssen die E-Mail nicht senden. Wenn nicht, senden Sie es und gehen Sie zu einem anderen Problem über, während Sie auf eine Antwort warten.

Per E-Mail können andere Personen antworten, wenn es für sie bequem ist. Bitten Sie sie jedoch, Sie anzurufen, wenn es für Sie bequem ist, zu ihrem Schreibtisch zu gehen, und sprechen Sie dann mit ihnen. Auf diese Weise erhalten Sie mehr Informationen und bauen wichtige Beziehungen auf.

Verteilen Sie Ihre Fragen, anstatt die Zeit einer Person zu verschwenden, und bitten Sie die Leute, Ihnen zu zeigen, wie sie das Problem lösen würden, anstatt nur „die Antwort“ zu suchen. Sie sollten die Leute auch fragen, wie lange sie gebraucht haben, um das System zu lernen, und wie viel sie davon wissen. Das sollte Sie davon überzeugen, dass es Ihnen gut geht.

Auch wenn Sie eine schlecht dokumentierte Funktion finden und sich eine Weile damit beschäftigen, sollten Sie das Gelernte aufschreiben. Dies können Kommentare im Code, offizielle Dokumentation, ein Team-Wiki oder eine inoffizielle Notiz sein (in dieser Reihenfolge). Dann schaffst du einen Mehrwert und hilfst dem Nächsten. Sie können sich auch Notizen zu Bereichen machen, die für das Refactoring überfällig sind, sowie zu gefundenen Fehlern.

2 - Was kann ich besser machen?

Ich stimme den anderen Antworten voll und ganz zu, 2 Wochen sind im Grunde nichts, also hör auf, dir darüber Sorgen zu machen. Aber es gibt eine Sache, die Sie besser machen können und sollten:

Ich denke, dass ich mich blamiere, wenn ich eine Frage stelle, also neige ich dazu, viel hängen zu bleiben, auf den Bildschirm zu starren und zu versuchen, einen Sinn in dem zu finden, was ich lese.

Daran müssen Sie arbeiten. Es gibt einige Dinge, die Sie selbst herausfinden können, und es ist im Allgemeinen natürlich besser, wenn Sie dies tun, wenn dies möglich ist. Aber es gibt andere Dinge, wie historische Gründe für einige Wendungen des Codes, die Sie unmöglich herausfinden können. Sie müssen nach diesen Dingen fragen, ohne Tage damit zu verbringen, sie zu betrachten.

Ich sage jetzt nicht, dass Sie wie eine Mücke durch das Büro flitzen und jeden auf Ihrem Weg umschwirren. Wenn Sie auf ein solches Problem stoßen, notieren Sie es. Lassen Sie sich von jemandem (normalerweise Ihrem Vorgesetzten) sagen, wer der Experte für dieses oder jenes ist. Versuchen Sie dann, eine Zeit zu finden, in der Sie sie nicht unterbrechen (z. B. einen tatsächlichen Termin vereinbaren?) und gehen Sie mit ihnen Ihre Liste relevanter Fragen durch. Sie werden sich nicht durch ständige Fragen ärgern, aber Sie haben trotzdem die Möglichkeit, sich auf den neuesten Stand zu bringen.