Wie setze ich Prozesse in meinem ersten Job um, wenn ich kaum weiß, was ich tue?

Die Umsetzung von Prozessen erfordert Autorität, die in der Regel beim Management liegt. Sie würden die aktive Unterstützung des Managements brauchen, aber es wäre sehr seltsam, wenn Sie als Junior-Entwickler ohne viel Erfahrung und Reputation im Unternehmen solche Macht erhalten würden.

Alles, worauf Sie realistisch hoffen können, ist, Vorschläge in den richtigen Ohren zu machen, aber auch dies funktioniert nur, wenn die betreffende Person empfänglich ist, was im Allgemeinen erfordert, zuerst etwas Vertrauen aufzubauen. Wenn sie tatsächlich nach Vorschlägen fragen, machen Sie natürlich weiter und bereiten Sie einige vor, aber ansonsten ist das wahrscheinlichste Ergebnis, dass Sie viel beschäftigte Leute nerven, die viel Einfluss auf Ihre zukünftige Karriere haben.

Soll ich versuchen, hier rauszukommen, bevor ich schlechte Angewohnheiten entwickle, oder ist das ein Durchgangsrecht? (Ich bin erst seit ein paar Wochen hier, wie lange soll ich warten?)

Erstens dauert es bei allen bis auf die kleinsten Unternehmen Monate, nicht Wochen, bis Prozessänderungen vollständig umgesetzt sind, insbesondere wenn das Managementteam mit anderen Dingen beschäftigt ist.

Was die Entwicklung schlechter Angewohnheiten betrifft, bin ich nicht davon überzeugt, dass Sie das tun würden. Schließlich scheinen Sie sich bewusst zu sein, dass ihr Prozess schlecht ist, und sich des Schadens bewusst, den er verursacht. Im Gegensatz dazu scheint es eine großartige Möglichkeit zu sein, zu lernen, was man niemals tun sollte, wenn man solche Konsequenzen täglich anschaulich veranschaulicht sieht :-)

Einer meiner ersten Jobs war ein technischer Leiter, der einige ganz besondere Schwächen hatte. Ich litt unter ihnen und lernte, was ich niemals tun sollte, wenn ich jemals Blei wurde. Als ich Jahre später in eine technische Führungsrolle befördert wurde, halfen mir diese Erinnerungen, Fehler zu vermeiden, die ich sonst vielleicht gemacht hätte. Oder anders ausgedrückt: "niemand ist nutzlos: er kann immer als schlechtes Beispiel dienen" :-)

Aber zurück zu Ihnen: In einem Unternehmen mit einem schlechten Prozess zu sein, wird Sie lehren, dass dieser Prozess schlecht ist, aber Sie werden keinen guten Prozess lernen. Wenn sich der Prozess also nach einer Weile nicht verbessert, kann es ratsam sein, das Unternehmen zu wechseln (und denken Sie daran, im Vorstellungsgespräch nach dem Prozess zu fragen, falls dies der Fall ist).

In der Zwischenzeit gibt es eine weitere wertvolle Fähigkeit, die Sie in diesem Unternehmen lernen können:

Im Grunde hat der Code keine Dokumentation [...] die meiste Zeit verbringe ich damit, willkürlich wirklich schwierige Fehler anzugreifen

Das Aufspüren von Fehlern in undokumentiertem Code, der von Leuten geschrieben wurde, die nicht mehr für Fragen zur Verfügung stehen, ist eine Fähigkeit, die Sie in Ihrer Karriere oft brauchen werden, denn selbst die Leute mit 100%iger Codeabdeckung finden manchmal die Ursache eines Fehlers in spärlich dokumentiertem Bibliothekscode, der von anderen geschrieben wurde Personen.

Also bleiben oder gehen? Das hängt von Ihnen und zahlreichen Faktoren ab, die auf einer Q/A-Site schwer zu kommunizieren sind. Aber ich persönlich sehe in Ihrem Beitrag nichts, was mich kurzfristig wirklich beunruhigen würde, also würde ich persönlich wahrscheinlich ein Jahr bei dieser Firma bleiben und dann die Situation neu bewerten: Hat sich der Prozess verbessert? Kann ich jetzt die anderen Dinge lernen, die einen Entwickler ausmachen, oder stecke ich immer noch in der Brandbekämpfung fest? Bin ich glücklich in meinem Job?

Der Grund für das Warten ist, dass das Verlassen eines Jobs nach weniger als einem Monat in einem Lebenslauf seltsam aussieht, also sollten Sie dies nur tun, wenn es notwendig ist (Ihre lokalen kulturellen Normen diesbezüglich können variieren, aber das ist der Fall, wo ich lebe). . Der zweite Grund ist, dass sie vorbeikommen und den Prozess verbessern könnten, was Ihnen die Möglichkeit gibt, sich einen Ruf für gute Vorschläge zu verschaffen, was Ihrer Karriere zugute kommt. Und drittens, so unwahrscheinlich es scheinen mag, vielleicht ist der von ihnen verwendete Prozess nicht so dysfunktional, wie es auf den ersten Blick erscheint, und schränkt Ihre Karriere doch nicht ein.

Lassen Sie mich Ihnen als jemand in seinem ersten Job und in einer ähnlichen Situation sagen, dass dies kein Durchgangsrecht ist. Dies sind wichtige Warnsignale und ein Hinweis auf schlechte Technik.

Das Fehlen von Prozessen macht es nur schwierig, über Code nachzudenken, weil die Leute am Ende Code wohl oder übel hinzufügen und ihn für die Produktion freigeben. Auf lange Sicht wird die Codebasis zu einem riesigen Haarballen und schwer zu handhaben.

Wie implementiert man also einen Prozess? Du nicht. Es ist die Aufgabe Ihres Vorgesetzten, dies zu tun. Beim Versuch, es umzusetzen, fühlt es sich vielleicht so an, als würde man ihm auf die Zehenspitzen treten. Sprechen Sie dies in Ihrem nächsten Teammeeting als Thema an und wenn er einen Prozess erstellt oder Sie bittet, einen zu erstellen - großartig. Wenn nicht, treiben Sie es nicht weiter voran.

Was die Entwicklung schlechter Angewohnheiten betrifft, so ist das etwas auf persönlicher Ebene. Stellen Sie sicher, dass Sie die Best Practices für Ihre Sprache / Ihr Framework kennen und versuchen Sie, diese in den von Ihnen geschriebenen Code zu integrieren. Machen Sie sich auch mit Literatur zum gleichen Thema wie dem Buch "Clean Code" usw.

Abgesehen davon, wenn der Code schwer zu begründen ist, hilft keine Menge QA, da Fehler durch Ihre Testsuite schlüpfen werden. Das habe ich aus einem der Vorträge von Rich Hickey, dem Schöpfer der Programmiersprache Clojure, über die Frage, warum Softwareentwicklung einfacher sein muss, entnommen.

Grundsätzlich hat der Code keine Dokumentation

Ich habe nie, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, Ich habe noch nie Code mit Dokumentation gesehen, und ich habe mit all der Software gearbeitet, die Sie jeden Tag Ihres Lebens auf allen Kontinenten und in den meisten Branchen verwenden.

und das Unternehmen hat im Grunde keinen Sinn für Prozesse

Ich habe noch nie, nie, nie, nie, nie, nie, nie, etc. eine Softwareabteilung oder -einheit mit einem Prozess1 gesehen

Wie mein erster Informatik-Professor sagte: „Wenn Architekten und Bauherren wie Software-Ingenieure wären, würde die Zivilisation am Dienstag zusammenbrechen.“

Notiz!

Ihre Kommentare kennzeichnen Sie als Anfänger!

Ich habe gerade den Rest Ihres Beitrags gelesen, und tatsächlich, genau wie Sie sagen: "Die erfahreneren Entwickler, mit denen ich außerhalb des Arbeitsplatzes gesprochen habe, lachen wie verrückt ..."

Also, mehr gibt es hier nicht zu sagen; Sie haben "Software entdeckt"! Genießen.

Wiederholen Sie diese Idee nicht noch einmal („Mir ist aufgefallen, dass wir keinen Prozess oder keine Dokumentation haben! Ich kann das beheben!“) gegenüber dem Management oder irgendjemandem!

... sondern konkret sein .

Überlege es dir morgen. Sagen Sie am Montag jemandem:

„Hey, ich habe dieses {Schema, API, Klasse, was auch immer} entdeckt, wo wir eine Menge technischer Schulden haben. Ich denke, mit {N} Tagen Arbeit könnte ich dramatisch {umgestalten, neu anfangen, ein BAAS verwenden, umschreiben, was auch immer } und es würde uns von da an eine Menge Arbeitsstunden ersparen."

Also, herzlichen Glückwunsch, dass Sie "heute offensichtlicher Posten" sind :) Aber die gute Nachricht für Ihre Karriere hier ist, dass Sie, wenn Sie sich für den genialen "spezifischen ..." Ansatz entscheiden, einer der älteren Leute sein werden, die über die neuen Leute lachen, im Handumdrehen! Genießen.

Weitere Tipps zur Umsetzung des "spezifischen..." Ansatzes:

• insbesondere die Sprache "Code Debt" wird Ihnen hier wirklich gut tun. Erklären Sie, dass Sie einige Codeschulden gefunden haben und in einer bestimmten Zeit eine bestimmte Menge zukünftiger Arbeitsstunden einsparen werden.

• deuten Sie nicht einmal an, mit dem Finger auf die Schuld zu zeigen. (Wenn Sie denken, dass irgendein Kollege oder eine Entität im Allgemeinen für die Kanalisation verantwortlich ist, die Software auf diesem Planeten ist, ist das einfach naiv; schlagen Sie nicht einmal vage Schuld oder Vernunft vor.) Geben Sie einfach in kurzen Worten das System an / Codezeile / was auch immer Sie technische Schuld sehen.

• im zweiten Teil der Formulierung ( "... und es würde uns von da an X Arbeitsstunden sparen" ) konkret sein. Also, "es würde die Arbeitsstunden, die für {dieses bestimmte Web-Eingabeformular / diese bestimmten REST-Aufrufe im XYZ-Build / was Jeff gerade tut}, erheblich reduzieren."

Tut mir leid das zu hören. Es ist schwierig, wenn Sie ein erfahrener Entwickler sind, noch schwieriger, wenn dies Ihr erster Job ist. Ich gehe davon aus, dass Sie schlau sind und diesen Job als Chance zum Wachsen wollen (also starten Sie Ihren nächsten Job als Nicht-Junior-mehr).

Ich würde mit Ihrem Vorgesetzten sprechen und seine Erlaubnis einholen, ein wenig Zeit darauf zu verwenden, jedes Stück Code zu dokumentieren, das Sie sich ansehen und verstehen mussten. Und jedes Mal, wenn Sie den Code von jemandem verstehen und eine Stunde damit verbringen müssen, ihn zu verstehen, verbringen Sie dann 10 Minuten damit, Dokumentation hinzuzufügen. Dann wird sich der Code Stück für Stück verbessern. Und das nächste Mal, wenn Sie denselben Code verstehen müssen, geht es viel schneller.

OK. Lassen Sie uns dies ein wenig verbessern.

Als Junior-Entwickler sind Sie noch nicht dazu da, eine Führungsrolle zu übernehmen. Sie haben bereits festgestellt, dass Sie kaum wissen, was Sie tun. Wie erwarten Sie realistischerweise, dass andere sich von Ihnen leiten lassen?

Trotzdem ist es gut, dass man spürt, dass etwas kaputt ist. Anstatt sich mit dem Versuch zu überfordern, das zu ändern, was das gesamte Team tut, können Sie sich auf konsistente Ergebnisse in dem Arbeitsprodukt konzentrieren, das allein von Ihrem Schreibtisch kommt. Wenn Sie das tun, werden Sie als eine Person bekannt, die zuverlässigen, wartbaren und skalierbaren Code erstellt. Wenn Probleme mit anderen oder größeren Prozessen auftauchen, haben Sie die Möglichkeit, sich zu äußern und Vorschläge zu machen . Bis Sie diesen Ruf haben, müssen Sie sich etwas zurücklehnen.

Keines dieser Dinge wird an einem Tag repariert. Sie waren schon lange durcheinander, seit Sie aufgetaucht sind, und sie könnten die gleichen sein, wenn Sie Ihren nächsten Job bekommen - aber Sie müssen die Situation nicht verderben. Manchmal muss man Menschen fallen lassen, bevor sie an das Konzept namens „Schwerkraft“ glauben; Sie können erklären, fordern, drängen, bis Sie blau im Gesicht sind, aber niemand wird es verstehen, bis sie hingefallen sind und sich die Knie aufgeschürft haben. Entspannen! Ein Tag nach dem anderen.