Frage:
Kein Prozess beim ersten Entwicklerjob - wie kann man mit dem Management diskutieren?
anon
2017-06-03 03:12:11 UTC
view on stackexchange narkive permalink

Ich habe gerade meinen ersten Job als jr Webentwickler bekommen und bin begeistert !! Zumindest war ich -

Grundsätzlich hat der Code keine Dokumentation und das Unternehmen hat im Grunde keinen Sinn für Prozesse. Ich und ungefähr 5 andere Entwickler sind auf der ganzen Welt verstreut, daher ist das Treffen spärlich. Der Code wurde von Auftragnehmern erstellt, mit denen wir keinen Kontakt mehr haben, die alle verschwunden sind, und die meiste Zeit verbringe ich damit, willkürlich wirklich schwierige Fehler anzugreifen. Keine Unit-Tests oder QA-Dinge.

Je älter die Entwickler sind, mit denen ich außerhalb des Arbeitsplatzes gesprochen habe, desto verrückter lachen ich, wenn ich über all das spreche, aber ich habe berechtigte Angst - Wie implementiere ich den Prozess bei meinem ersten Mal? Job, wenn ich kaum weiß, was ich tue? Sollte ich versuchen, hier rauszukommen, bevor ich schlechte Gewohnheiten entwickle, oder ist dies ein Durchgangsrecht? (Ich bin erst seit ein paar Wochen hier, wie lange sollte ich warten?) Das Management scheint für das Feedback empfänglich zu sein und scheint die richtigen Prozesse aufzubauen und die richtigen Leute einzustellen, aber sie verbringen ihre Zeit damit, Feuer zu löschen und nicht viel zu ändern.

Können Sie klarstellen, was Sie unter "kein Prozess" verstehen?Welche Aspekte des Prozesses fehlen Ihnen speziell?
Wer ist verantwortlich und was sagt diese Person?z.B.Haben Sie einen Teamleiter oder Manager, der die Richtung vorgeben kann?
Wenn es das Management interessieren würde, wären die Dinge anders, aber hey, willkommen in der realen Welt.
heh;Das OP wurde mit Bedacht auf Anon geändert :) :)
"Der Code wurde von Auftragnehmern erstellt, mit denen wir keinen Kontakt mehr haben, die alle verschwunden sind ..." - Das tun Auftragnehmer.Zu erwarten, dass sie etwas anderes tun, ist einfach dumm von Ihrer Seite.Erwarten Sie, dass Ihr Bauherr Sie vierteljährlich anruft und fragt, wie es läuft?
Willkommen in der Welt der Softwareentwicklung!
Fünf antworten:
#1
+15
meriton
2017-06-03 05:25:45 UTC
view on stackexchange narkive permalink

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.

#2
+8
An SO User
2017-06-03 04:13:07 UTC
view on stackexchange narkive permalink

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.

Einverstanden, aber beachten Sie, dass die Lösung, wie ich humorvoll erkläre, sehr einfach ist: Sie teilen dem Chef einfach einen * spezifischen * Code-Schuldenvorschlag mit.In einem bestimmten Satz.Und lass es dabei.("Hey Boss, wenn wir Spalte X aus dem Schema entfernen, wird ABC in Zukunft viel einfacher. Soll ich das tun?") Und mach einfach weiter.
Als jemand, der seit 1986 professionell Software schreibt, sind Sie genau richtig.Es ist kein Übergangsritus, es sei denn, dieser Ritus funktioniert an einem Ort, der nicht weiß, was er tut, was wir alle irgendwann tun.Auf jeden Fall rote Fahnen.
@ChristopherEstep Das Problem liegt in der Verherrlichung der "Startup-Kultur".Wie Robert Martin sagte, hat Software ältere, erfahrenere Programmierer, aber es ist ein Spiel für junge Männer geworden.Es war in einem seiner YouTube-Gespräche.
@LittleChild Es gibt unzählige Artikel und Vorträge, in denen eine Startup-Kultur, die eine faule Kultur in Bezug auf "Prozesse" (ob Software oder andere Vorgänge) angenommen hat, zum Scheitern verurteilt ist.Vielleicht würde mehr Erfolg haben, wenn sich diese Unternehmer in der Notwendigkeit von Methoden und Strukturen weiterbilden würden.Die Startups, die mit lockerer Organisation und ohne Prozesse erfolgreich sind, sind die Ausnahme, würde ich wetten.
#3
+4
Fattie
2017-06-03 22:04:13 UTC
view on stackexchange narkive permalink

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}"

aufgewendet wurden
Ich wünschte, ich könnte tausendmal abstimmen.Große Flüsse bestehen aus unzähligen kleineren Bächen.Fügen Sie überall einen Stream hinzu.Und lesen Sie Joel Spolsky: https://www.joelonsoftware.com/2001/12/25/getting-things-done-when-youre-only-a-grunt/
lol danke Mann @gazzz0x2z - nur versuchen, unterhaltsam zu sein :)
Hey @GabeSechan - ich glaube, Sie hatten Glück :) Ich denke, es geht darum, wie das OP vorgehen soll: Seien Sie genau und schlagen Sie einen Weg vor (wahrscheinlich klein, um anzufangen), um Code-Schulden abzuwickeln.
#4
+2
gnasher729
2017-06-03 23:12:11 UTC
view on stackexchange narkive permalink

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.

Ich mag dieses, weil es einen proaktiveren Ansatz verfolgt.Wenn Sie Ihre Produktivität nicht verlangsamen, würde ich nicht fragen (ich bin allerdings eher ein Risikoträger ...), sondern mich steigern und dokumentieren, während ich gehe (ich mag die 10-minütige Idee).Wenn ich mit einem großen Teil der Dokumentation fertig bin, bieten Sie sie dem Chef oder, besser gesagt, dem Team an.
#5
+2
Xavier J
2017-06-06 03:40:44 UTC
view on stackexchange narkive permalink

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.

Leider schaben sich einige Leute meiner Erfahrung nach immer wieder die Knie, beschuldigen aber weiterhin die Leute, die diesen perfekt flachen Boden gebaut haben, anstatt das Laufen zu lernen.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...