Wie implementiere ich Prozesse bei meinem ersten Job, wenn ich kaum weiß, was ich tue?

Die Implementierung von Prozessen erfordert Autorität, die im Allgemeinen vom Management gehalten wird. Sie würden die aktive Unterstützung des Managements benötigen, aber es wäre sehr seltsam, wenn Sie, ein Junior-Entwickler ohne viel Erfahrung oder Ruf im Unternehmen, eine solche Macht erhalten würden.

Alles, worauf Sie realistisch hoffen können, ist make Vorschläge in den rechten Ohren, 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, bereiten Sie einige vor, aber ansonsten ist das wahrscheinlichste Ergebnis, dass vielbeschäftigte Menschen nerven, die großen Einfluss auf Ihre zukünftige Karriere haben.

Sollte ich versuchen, dies zu erreichen? hier raus, bevor ich schlechte Gewohnheiten entwickle, oder ist das ein Durchgangsrecht? (Ich bin erst seit ein paar Wochen hier, wie lange sollte ich warten?)

Erstens dauert es Monate bis auf die kleinsten Prozessänderungen in Unternehmen, nicht Wochen, bis sie vollständig implementiert sind Wenn das Managementteam mit anderen Dingen beschäftigt ist.

Ich bin nicht davon überzeugt, dass Sie schlechte Gewohnheiten entwickeln würden. Schließlich scheinen Sie sich bewusst zu sein, dass ihr Prozess schlecht ist, und Sie wissen, welchen Schaden er verursacht. Im Gegensatz dazu scheint es eine großartige Möglichkeit zu sein, solche Konsequenzen täglich anschaulich darzustellen, um zu lernen, was man niemals tun sollte :-)

Einer meiner ersten Jobs war mit einem technischen Vorsprung verbunden, der einige ganz besondere Mängel aufwies. Ich litt unter ihnen und lernte, was ich niemals tun sollte, wenn ich jemals geführt würde. Als ich Jahre später in eine technische Führungsrolle befördert wurde, halfen mir diese Erinnerungen, Fehler zu vermeiden, die ich sonst hätte machen können. Oder anders ausgedrückt: "Niemand ist nutzlos: Sie können immer als schlechtes Beispiel dienen" :-)

Aber zurück zu Ihnen: Wenn Sie in einem Unternehmen mit einem schlechten Prozess sind, werden Sie lernen, dass dieser Prozess schlecht ist, aber Sie werden keinen guten Prozess lernen. Wenn sich der Prozess nach einer Weile nicht verbessert, kann es ratsam sein, das Unternehmen zu wechseln (und wenn Sie dies tun, im Interview nach dem Prozess zu fragen).

In der Zwischenzeit gibt es eine weitere wertvolle Fähigkeit Sie können in dieser Firma lernen:

Grundsätzlich enthält der Code keine Dokumentation [...]. Die meiste Zeit verbringe ich damit, wirklich schwierige Fehler willkürlich anzugreifen.

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

Also, solltest du hier bleiben oder gehen? Das hängt von Ihnen ab und von zahlreichen Faktoren, die auf einer Q / A-Site nur schwer zu kommunizieren sind. Aber ich persönlich sehe in Ihrem Beitrag nichts, was mich kurzfristig wirklich beunruhigen würde. Ich persönlich würde 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 in meinem Job glücklich?

Der Grund für das Warten ist, dass das Verlassen eines Jobs nach weniger als einem Monat in einem Lebenslauf seltsam erscheint. Sie sollten dies also nur tun, wenn dies erforderlich ist (Ihre lokalen kulturellen Normen) Dies kann variieren, aber dies ist der Fall, wo ich wohne. Der zweite Grund ist, dass sie möglicherweise vorbeikommen und den Prozess verbessern und Ihnen die Möglichkeit geben, den Ruf zu erlangen, gute Vorschläge zu machen, die Ihrer Karriere helfen. Und drittens, so unwahrscheinlich es auch scheinen mag, ist der von ihnen verwendete Prozess möglicherweise nicht so dysfunktional, wie es auf den ersten Blick erscheint, und schränkt Ihre Karriere schließlich nicht ein.

Als jemand bei seinem ersten Job und in einer ähnlichen Situation möchte ich Ihnen sagen, dass dies kein Durchgangsrecht ist. Dies sind wichtige rote Fahnen, die auf schlechte Technik hinweisen.

Mangelnde Prozesse machen es nur schwierig, über Code nachzudenken, da die Leute am Ende wohl oder übel Code hinzufügen und ihn für die Produktion freigeben. Auf lange Sicht wird die Codebasis zu einem riesigen Haarball und schwer zu handhaben.

Wie implementieren Sie einen Prozess? Das tust du nicht. Es ist die Aufgabe Ihres Managers, dies zu tun. Der Versuch, ein zu implementieren, könnte das Gefühl haben, ihm auf die Zehen zu treten. Erhöhen Sie dies als Problem in Ihrer nächsten Teambesprechung und wenn er einen Prozess erstellt oder Sie auffordert, einen zu erstellen - großartig. Wenn nicht, schieben Sie es nicht weiter.

Das Entwickeln von schlechten Gewohnheiten ist 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 "Clean Code" -Buch usw. vertraut.

Abgesehen davon, wenn der Code schwer zu begründen ist, hilft keine Menge an Qualitätssicherung, da Fehler auftreten Am Ende schlüpfen Sie durch Ihre Testsuite. Dies habe ich aus einem der Vorträge von Rich Hickey, dem Erfinder der Programmiersprache Clojure, aufgegriffen, warum die Softwareentwicklung einfacher sein muss.

Grundsätzlich hat der Code keine Dokumentation

Ich habe nie, nie, nie, nie, nie, nie, nie, nie, nie, nie, nie , immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer, immer Code mit Dokumentation gesehen, und ich habe mit all der Software gearbeitet, an der Sie uns jeden Tag Ihres Lebens arbeiten Jeder Kontinent und die meisten Branchen.

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

Ich habe nie, nie, nie, nie, nie Wie immer mein erster Informatikprofessor sagte: "Wenn Architekten und Bauherren wie Softwareingenieure wären, würde die Zivilisation bis Dienstag zusammenbrechen."

Hinweis!

Ihre Kommentare markieren Sie als Anfänger!

Ich habe gerade den Rest Ihres Beitrags gelesen, und zwar nur wie Sie sagen "Die älteren Entwickler, mit denen ich vom Arbeitsplatz aus gesprochen habe, lachen wie verrückt ..."

Also hier gibt es nichts mehr zu sagen; Sie haben "Software entdeckt"! Viel Spaß.

Wiederholen Sie diese Idee nicht ("Ich habe festgestellt, dass wir keinen Prozess oder keine Dokumentation haben! Ich kann das Problem beheben!") an das Management oder an irgendjemanden!

... seien Sie lieber spezifisch .

Denken Sie morgen darüber nach. Sagen Sie am Montag jemandem:

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

Also, herzlichen Glückwunsch zum Sein "heutiger offensichtlicher Beitrag" :) Aber die gute Nachricht für Ihre Karriere hier ist, dass Sie einer der genialen "spezifischen ..." Ansätze sind, zu denen Sie gehören Die älteren Jungs lachen über die neuen Jungs, in kürzester Zeit! Viel Spaß.

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

• Insbesondere die Sprache "Code Debt" wird hier wirklich für Sie funktionieren. Erklären Sie, dass Sie eine Code-Verschuldung gefunden haben und in einer bestimmten Zeit eine bestimmte Menge zukünftiger Arbeitsstunden sparen.

• Geben Sie nicht einmal einen Hinweis beim Zeigen der Schuldfinger. (Wenn Sie der Meinung sind, dass ein Kollege oder ein Unternehmen im Allgemeinen für den Abwasserkanal verantwortlich ist, der Software auf diesem Planeten ist, ist das einfach naiv. Schlagen Sie nicht einmal vage Schuld oder Vernunft vor.) Geben Sie einfach in kurzen Worten an das System / die Codezeile / was auch immer Sie technische Schulden sehen.

• im zweiten Teil der Formulierung ( "... und es würde Sparen Sie uns von da an X Mannstunden. ") Seien Sie genau. "Es würde also die Arbeitsstunden reduzieren, die für {dieses bestimmte Webeingabeformular / diese bestimmten REST-Aufrufe im XYZ-Build / was Jeff gerade tut}"

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

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

OK. Lassen Sie uns das noch etwas verbessern.

Als Junior-Entwickler sind Sie noch nicht da, um eine Führungsrolle zu übernehmen. Sie haben bereits festgestellt, dass Sie kaum wissen, was Sie tun. Wie erwarten Sie realistisch, dass andere von Ihnen Anweisungen erhalten?

Trotzdem ist es gut, dass Sie spüren können, dass etwas kaputt ist. Anstatt sich mit dem Versuch zu überwältigen, das gesamte Team zu ändern, können Sie sich auf konsistente Ergebnisse im Arbeitsprodukt konzentrieren, das nur von Ihrem Schreibtisch stammt. Wenn Sie dies tun, werden Sie als eine Person bekannt, die zuverlässigen, wartbaren und skalierbaren Code erstellt. Wenn Probleme mit anderen oder größeren Prozessen auftreten, haben Sie dann die Möglichkeit, sich zu äußern und Vorschläge zu machen . Bis Sie einen solchen Ruf haben, müssen Sie sich etwas zurücklehnen.

Keines dieser Dinge wird an einem Tag behoben. Sie sind schon lange durcheinander, bevor Sie aufgetaucht sind, und sie sind möglicherweise gleich, wenn Sie Ihren nächsten Job bekommen - aber das müssen Sie nicht blasen Sie eine Dichtung über die Situation. Manchmal muss man Menschen fallen lassen, bevor sie an das Konzept der "Schwerkraft" glauben. Sie können erklären, fordern, drängen, bis Sie blau im Gesicht sind, aber niemand wird es bekommen, bis sie heruntergefallen sind und ihre Knie gehäutet haben. Entspannen! Ein Tag nach dem anderen.