Nach zwei Wochen kann ich mit Zuversicht sagen, dass ich eindeutig keinen Wert für dieses Unternehmen und die anderen Entwickler geschaffen habe, die mir geholfen haben, meine Arbeit zu erledigen, 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 anheuere, gehe ich davon aus, dass sie 6 Monate lang nicht positiv sind).

Alles, was Sie in Ihrer Frage erwähnt haben, sind eigentlich gute Anzeichen - es klingt so, als würden sie interessante und nicht triviale Software entwickeln, was bedeutet, dass Sie viele Lernmöglichkeiten haben und dass sie in Sie investiert sind - indem Sie Zeit und Raum haben, um sich auf dem Laufenden zu halten.

Schreibeinheits- und Integrationstests sind eine weit verbreitete Methode, um neue Nachwuchskräfte zu gewinnen. Sie lernen die IDE, das Versionsverwaltungssystem, den Erstellungsprozess und die verschiedenen formellen und informellen Arbeitsabläufe bei der Entwicklung von Software kennen, während Sie sich auf relativ kleine Arbeitsblöcke konzentrieren. Sie erfahren auch viel über die Geschäftsfunktionen, die die Software bietet.

1 - Ist das normal?

Ja. Sie sind kein Betrüger, und es gibt keinen Grund zu der Annahme, dass es eine schlechte Idee war, auf diesem Gebiet tätig zu werden. Aufgrund der Tatsache, dass sie Sie eingestellt haben und in Sie investieren möchten, scheint es eine gute Idee zu sein. Das Wichtigste ist, über den naiven Glauben hinwegzukommen, dass nur weil Sie "wohl die Besten" in Ihrem Bootcamp waren, Sie bereit waren, am ersten Tag in einen Entwicklungsladen zu gehen und Wert zu produzieren. Das Bootcamp bot Ihnen die grundlegende Grundlage für die Programmierung - ein professioneller Entwickler kann noch viel mehr, was Sie nur im Beruf lernen können.

2 - Was kann Ich mache es besser?

Ich denke, das hat zwei "Bereiche". Das erste ist, was 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. Auch wenn Ihr Bootcamp in derselben Sprache war, an der Sie gerade arbeiten, gibt es viel zu lernen (ich war es) Programmieren in der gleichen Primärsprache seit> 10 Jahren und lerne immer noch jeden Tag neue Dinge). Wenn eines der anderen von ihnen verwendeten Tools öffentlich / frei verfügbar ist (die IDE, das Quellcodeverwaltungs-Tool), üben Sie auch mit diesen. Nehmen Sie sich auch Zeit, um die Grundlagen der Informatik (Algorithmen, Datenstrukturen) kennenzulernen. Auch wenn Sie dieses Wissen nicht sofort nutzen, wird es immer hilfreich sein.

Das zweite, obwohl es nicht speziell mit den von Ihnen durchgeführten Tests zusammenhängt, kann als Teil dieser Arbeit durchgeführt werden. Das heißt, die Fähigkeit zu entwickeln, einen Code zu "analysieren". Machen Sie den einfachsten Test, den Sie finden können, testen Sie den einfachsten Code und versuchen Sie, den Kontrollfluss dieses Codes zu ermitteln. Führen Sie es durch einen Debugger, halten Sie in jeder Zeile an und sehen Sie, was es tatsächlich tut. Ändern Sie den Test leicht und sehen Sie, wie er sich anders verhält. Versuchen Sie, einen Test zu erstellen, der einen anderen if-Zweig (usw.) testet. Verwenden Sie Ihr IDE-Quellcodeverwaltungstool und sehen Sie sich das letzte Commit an, durch das dieser Code geändert wurde. Überprüfen Sie, ob Sie verstehen können, was diese Änderung bewirkt hat (besonders nützlich, wenn Sie auf das Ticket zurückgreifen können, das diese Änderung dokumentiert hat). Gehen Sie zu einem etwas komplexeren Test und wiederholen Sie den Vorgang. Nehmen Sie nun den Code, den Sie testen sollen, und führen Sie diese Analyse vorab durch. Verwenden Sie dies, um Ihren ersten Test zu schreiben.

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

3 - Wie kann ich dies (oder einen Teil davon) gegenüber dem Management und den Kollegen ausdrücken, ohne als Betrug zu gelten?

Niemand wird geboren, der weiß, wie man codiert. Daher haben Ihre Kollegen und Manager alle an einem ähnlichen Ort begonnen wie Sie. Solange sie keine Idioten sind (und Sie haben bereits gesagt, dass sie es nicht sind), wissen sie und erwarten, dass Sie sie um Hilfe bitten.

Natürlich müssen Sie das richtige Gleichgewicht zwischen beiden finden zu viele Fragen stellen und nicht früh genug um Hilfe bitten. Ich habe meinen Junioren oft gesagt, "verschwenden Sie keine 3 Stunden damit, etwas herauszufinden, bei dem ich Ihnen in 5 Minuten helfen kann". Verschwenden Sie umgekehrt nicht meine 5 Minuten, wenn Sie nicht einige Zeit damit verbracht haben, es selbst herauszufinden.

Wenn Sie noch keine geplant haben, fragen Sie Ihren Manager nach einer wöchentlichen 30 Minuten Besprechung. Um eine andere Antwort zu zitieren, die ich hier geschrieben habe:

Die Aufgabe Ihres Managers besteht darin, sein Bestes zu geben, um Ihnen die Chance auf Erfolg zu geben - dies kann nur geschehen, wenn Sie beide reguläre und haben häufige Gespräche, und wenn Sie während dieser Gespräche offen und ehrlich darüber sind, wo Sie Schwierigkeiten haben, wo Sie Unterstützung benötigen, wo Sie stecken bleiben und wo Sie erfahren, was er / sie von Ihnen erwartet.

Eines 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 viel mehr als nur 2 Wochen geben.

• Jeder fühlt sich ein bisschen überwältigt, wenn sie anfänglich einen Programmierjob beginnen.
• In den ersten Wochen / Monaten werden Sie viele Dinge verlernen, die Ihnen in der Schule / im Bootcamp beigebracht wurden, und lernen, wie echte Software funktioniert.
• Niemand versteht den gesamten Code auf den ersten Blick. Manchmal ist vorhandener Code schlecht kommentiert und für alle außer dem ursprünglichen Autor nicht zu entziffern.

Nehmen Sie die Dinge schrittweise. Sie werden mit ziemlicher Sicherheit feststellen, dass jede Woche etwas komfortabler ist als die letzte.

Nutzen Sie die schöne und freundliche Kultur. Bitten Sie um Hilfe, wenn Sie sie brauchen.

Und seien Sie nicht so hart zu sich selbst. Wenn Sie das Programmieren selbst gelernt haben und dann im Bootcamp brillant waren, werden Sie höchstwahrscheinlich etwas mehr Geduld und harte Arbeit haben.

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.

Stellen Sie Fragen. Holen Sie sich das Verständnis. Fragen Sie, was Sie in Ihrer Freizeit lesen können, um ein Verständnis zu entwickeln. Seien Sie bereit, hart zu arbeiten, auch wenn Sie einige Stunden außerhalb der Arbeit verbringen. Ich wäre besorgt über einen Junior-Entwickler, der KEINE Fragen gestellt hat. Ich würde wetten, dass jeder Ihrer Kollegen, die Senioren sind, genauso angefangen hat wie Sie.

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

Wie jeder sagt, sind zwei Wochen nichts. Sie werden viel länger brauchen, um sich auf den neuesten Stand zu bringen. Und Ihr Manager und Ihre Kollegen erwarten dies.

Ich möchte einen Satz zum Kommentieren nehmen:

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

Aus meiner Sicht ist dies ein Fehler von Dokumentation . Welches ist auch schrecklich häufig. In einer idealen Welt sollte es eine Beschreibung von allem geben, was verfügbar ist, aber sehr oft 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 bei den Komponententests wird mit größerer Wahrscheinlichkeit geprüft, was getestet werden soll.

Es kann schwierig sein, den Mut zu fassen, einen vielbeschäftigten Kollegen mit einer Frage zu unterbrechen ist wahrscheinlich trivial. Wie es sein sollte, saugen Unterbrechungen.

Stattdessen sollten Sie ein Meeting planen. Auf diese Weise ist es nur eine Unterbrechung statt vieler. Wenn Sie eine Frage haben, die Ihre Arbeit blockiert, legen Sie diese beiseite und suchen Sie eine andere Aufgabe.

Bereiten Sie sich auf das Meeting vor. Haben Sie eine Liste mit Fragen, genaue Verweise auf relevante Quellen oder Dokumente usw.

Am Anfang benötigen Sie viele solcher Besprechungen, aber die Dinge werden besser, wenn Sie sich mit allem vertraut machen.

1 - Ist das normal?

Ja. Dort zu sitzen, verwirrt auf Alien-Code zu starren und sich zu fragen, was Sie tun, ist auf allen Ebenen normal, auch nach jahrzehntelanger Erfahrung. Was sich ändert, ist, wie Sie damit umgehen.

2 - Was kann ich besser machen?

Bleiben Sie dran. Zwei Wochen sind wirklich kein Grund zur Sorge. Ich war einmal der Teamleiter für eine Anwendung wie Ihre, und neue Leute brauchten mehr als zwei Monate , um etwas produktiv zu werden. Manchmal dauerte es Jahre. Es kann eine Woche oder länger dauern, bis die Benutzer nur ihre Entwicklungsumgebung initialisiert haben, in der Lage sind, die Quelle für ältere Anwendungen zu kompilieren, und weitere Wochen, bis sie auf ihrem Laptop ausgeführt werden können. Und so weiter.

3 - Wie kann ich dies (oder einen Teil davon) gegenüber dem Management und den Kollegen ausdrücken, ohne als Betrug zu gelten?

Sie sprechen nicht darüber, wie Sie sich betrogen fühlen. Sie sprechen objektiv über die anstehende Aufgabe. Versuchen Sie, mögliche Lösungen zu finden, und wenn Sie sich nicht selbst entscheiden können, fragen Sie Ihren Chef oder leitenden Entwickler. Wenn das bedeutet, dass Sie Ihren Kollegen jeden Tag den ganzen Tag fragen müssen, dann sei es so. Wenn Ihr Kollege Ihnen das Gefühl gibt, dass es zu viel ist, fragen Sie Ihren Chef, wen er sonst fragen soll, ob er andere Informationsquellen hat oder ob es ihm recht ist, wenn Sie sich viel Zeit nehmen, um im Internet herumzustolpern dunkel.

Seien Sie transparent; Stellen Sie sicher, dass Ihre "Stakeholder" wissen, was Sie tun. (Es ist eine Kunst, dies so zu tun, dass nicht jeder auf die Nerven geht - vielleicht ein Thema für eine andere Frage; eine Möglichkeit wäre, einen Ein-Pager zu halten, den Sie auf dem neuesten Stand halten, und ihn nur einmal pro Woche oder jede andere zu senden Woche oder so ähnlich. Hängt auch wirklich von Ihrer Unternehmenskultur ab.)

Dies ist eine Einbahnstraße. Den neuen Mann auf undokumentierten Quellcode zu werfen, ist eine schöne Übung, um die "Säfte fließen zu lassen", aber am Ende des Tages würde niemand erwarten, dass hier Magie passiert.

Wenn Sie konkrete technische Fragen haben, wenden Sie sich besser an einen der technischeren Stapelbörsen.

Ich habe an einigen massiven und alten Codebasen gearbeitet (3D-CAD in C ++, von denen einige automatisch aus FORTRAN generiert wurden) und 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 gesagt haben, bist du nicht allein. Ich habe ähnliche Ratschläge wie Stig, aber mit einigen wichtigen Nuancen.

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

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

1. Schreiben Sie ein Tagebuch, auch wenn es niemandem gezeigt wird. Wenn Sie glauben, dass Sie Ihr Tagebuch den Menschen zeigen werden, führen Sie ein privates Tagebuch, in dem Sie Ihrem zukünftigen Selbst beschreiben, wie Sie verloren sind oder ob Sie an diesem Tag etwas verstanden haben.
2. Schreiben Sie tatsächliche Tests, auch wenn dies der Fall ist dumme triviale, die ein bisschen Code ausüben. Wenn Sie die Einschränkungen für Parameter nicht verstehen, verspotten Sie etwas, 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 andere Personen problemlos mit der Ausführung beginnen können.
3. Schreiben Sie, wie von anderen vorgeschlagen, Dokumentation. Abhängig von der Sprache sollten Sie in der Lage sein, eine Art automatisches Dokumentationswerkzeug wie Doxygen zu erhalten, das allgemeine Callgraphs generiert. Wenn Sie nicht können, beginnen Sie mit einem Code und verfolgen Sie, wo er verwendet wird. Wenn Sie den Code ausführen und einen Debugger aufrufen können, verwenden Sie Haltepunkte, um einen Aufrufstapel 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.
ol>

Zu vermeidende Dinge

Kritisieren Sie nicht die vorhandenen Dokumentationspraktiken. Dies ist ein Bereich, der oft sehr kontrovers ist. Menschen haben möglicherweise ihre eigenen starken Meinungen und haben sie abgelehnt. Sie werden erstaunt sein , wie tief die Gefühle in Bezug auf Dokumentationspraktiken sein können (und wie man Tests schreibt).

Bitten Sie niemanden um Rat und scheinen Sie 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 Bildung ausgesetzt sind (nicht nur Bootcamps). Nur an wenigen Stellen lernen Sie, wie man programmiert, ohne zu erwarten, dass Sie alles verstehen. Das ist in großen Programmen einfach nicht möglich. Lassen Sie das verstehen müssen.

Ich denke, dass ich mich in Verlegenheit bringe, wenn ich eine Frage stelle, so dass ich oft festsitze, auf den Bildschirm starre und versuche, einen Sinn für das zu finden, was ich lese.

Ich denke, dies ist der einzige Ort, an dem Sie falsch liegen. Neue Leute müssen viele Fragen stellen, es ist die einfache Möglichkeit für erfahrene Leute, zu beurteilen, was Sie als nächstes wissen müssen.

Wenn Sie feststellen, dass Sie selbst auf den Bildschirm starren, schreiben Sie eine E-Mail (oder eine schlaffe Nachricht) , oder Wasauchimmer). Behandeln Sie es wie eine Stapelüberlauffrage. Beschreiben Sie das Problem und was Sie getan haben, und zeigen Sie, dass Sie sich etwas Mühe gegeben haben. In der Hälfte der Zeit deutet dies möglicherweise auf etwas hin, das Sie nicht ausprobiert haben, oder auf ein Thema, das Sie recherchieren können, und Sie müssen die E-Mail nicht senden. Wenn nicht, senden Sie es und fahren Sie mit einem anderen Problem fort, während Sie auf eine Antwort warten.

Mit E-Mail können andere Personen antworten, wenn es ihnen passt. Bitten Sie sie jedoch, Sie anzurufen, wenn es Ihnen passt Gehen Sie zu ihrem Schreibtisch und sprechen Sie mit ihnen. Auf diese Weise erhalten Sie mehr Informationen und können wichtige Beziehungen aufbauen.

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

Wenn Sie eine schlecht dokumentierte Funktion finden und eine Weile darüber lernen, sollten Sie aufschreiben, was Sie lernen. Dies können Kommentare im Code, in der offiziellen Dokumentation, in einem Team-Wiki oder inoffizielle Notizen (in dieser Reihenfolge) sein. Dann schaffen Sie Mehrwert und helfen dem nächsten Mann. Sie können auch Notizen zu Bereichen machen, die für das Refactoring überfällig sind, sowie zu Fehlern, die Sie finden.

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 eines können und sollten Sie besser machen:

Ich denke, dass ich mich schäme, wenn ich eine Frage stelle, so dass ich oft festsitze, auf den Bildschirm starre und versuche zu machen Sinn für das, was ich lese.

DIESES ist das, woran Sie arbeiten müssen. Es gibt einige Dinge, die Sie selbst herausfinden können, und es ist im Allgemeinen natürlich besser, wenn Sie dies tun, wenn möglich. 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 anzusehen.

Jetzt sage ich nicht, dass Sie wie eine Mücke durch das Büro huschen, die alle auf Ihrem Weg summt. Wenn Sie auf ein solches Problem stoßen, notieren Sie es sich. Lassen Sie sich von jemandem (normalerweise Ihrem Manager) 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 Ihre Liste der relevanten Fragen mit ihnen durch. Sie werden sich nicht über einen ständigen Strom von Fragen ärgern, aber Sie haben trotzdem die Möglichkeit, sich auf dem Laufenden zu halten.