Ich habe vor ungefähr 7 Jahren angefangen, als Softwareentwickler zu arbeiten. Seitdem hatte ich mehrere verschiedene Positionen in verschiedenen Unternehmen.
Ich habe in der Softwareabteilung eines Ingenieurbüros angefangen, wo Software entweder ein winziger Teil des hergestellten Produkts ist oder nur den Herstellungsprozess unterstützt. Das erste Projekt, an dem ich arbeitete, war ein großes Ein-Mann-Programm, das zu einem riesigen Software-Chaos herangewachsen war. Mein damaliger Chef und der ehemalige „Ein-Mann“ hatten kein Interesse daran, Dinge zu ändern, und mein Chef erlaubte mir auch nicht, Dinge anders zu machen. Es war sehr frustrierend.
Als Neuankömmling habe ich versucht, das so zu akzeptieren und eine Zeit lang damit gelebt. Später kontaktierte ich den Chef meines Chefs (ich nenne ihn Tom) über die Situation, in der ich mich befand, und sagte ihm, dass es nicht den Erwartungen entspricht, wie ich Software schreiben möchte.
Im Laufe eines Jahres hatte ich mehrere Treffen mit Tom, bei denen ich und ein Kollege von mir (der inzwischen dem Team beigetreten ist) die Situation besprochen haben und was getan werden könnte, um sie zu verbessern. Ich hatte eigentlich gehofft, dass Tom irgendwann meinen Chef rausholen und neu bewerten würde, wer das Schiff führen wird.
Leider ist dies nie passiert (zumindest nicht während ich dort war - es dauerte nicht lange, bis der erwähnte Kollege und ich kündigten).
Eigentlich ist gar nicht so viel passiert. Ich habe Tom nie gesagt, dass ich erwartet habe, dass sich die Dinge radikal ändern. Was ich in der Bewertung unbedingt hätte tun sollen.
Irgendwann in einem Gespräch mit Tom sagte er mir, ich solle es einfach so machen, wie ich denke, ohne es mit meinem Chef zu besprechen, und wenn es irgendwelche Probleme gäbe, solle ich meinem Chef einfach sagen, dass es so mit ihm besprochen wurde . An diesem Punkt wurde mir klar, dass Tom seine Führungsverantwortung verletzte, indem er mich zwang, meinen Chef zu umgehen. Also habe ich gekündigt.
Jetzt, ein paar Jahre und ein paar sehr ähnliche frustrierende Positionen später, stecke ich wieder in einem über viele Jahre gewachsenen Projekt fest, wo ich das Gefühl habe, dass ich der einzige bin, der daran interessiert ist, den Mist Schritt für Schritt aufzuräumen, während mein neuer Chef wieder kein Interesse daran hat, in diese Richtung zu gehen.
Und wieder folgen den Treffen, bei denen ich versuche, darauf hinzuweisen, dass wir mit der Entwicklung sauberer Software beginnen müssen, niemals irgendwelche Taten. Und wieder müssen die Meetings mit „Tom“ geführt werden, weil ich im direkten Kontakt mit meinem Chef keine konstruktive Diskussion in Gang bringen kann.
Jetzt fange ich an, meine Berufswahl zu hinterfragen. Vielleicht bin ich nicht dafür gemacht, ein Softwareentwickler zu sein. Ich kann die (wie ich fand) weitverbreitete Entscheidung einfach nicht akzeptieren, schlechte Software zu schreiben und sie später zu reparieren (was natürlich nie vorkommt).
Habe ich einfach nur Pech mit den Unternehmen, in die ich eingetreten bin, oder habe ich nicht deutlich genug gemacht, dass ich das nicht so machen will? Oder machen sie es gut und ich muss meine Domäne in etwas anderes ändern (Design, Projektmanagement, was auch immer).
Herzlichen Glückwunsch, Sie haben gerade herausgefunden, wie >90 % der Unternehmenssoftware aussieht.
Sie waren am falschen Ort, um Ihre Fähigkeiten anzuwenden. Diese Unternehmen (die die Mehrheit der Unternehmen ausmachen, die wiederum den Großteil der Software in der Produktion ausmachen) kümmern sich nicht um technische Schulden, weil sie ihr Endergebnis nicht erhöhen – oder zumindest sehen sie es nicht so Weg.
Sie könnten versuchen, Ihre Vorgesetzten vom Gegenteil zu überzeugen, aber es ist ein undankbares Unternehmen, weil sie wahrscheinlich darauf trainiert sind, nicht so zu denken. Außerdem haben Sie einen One Man Software- Typen, der seit Jahren dort ist und jetzt spielen Sie mit seinem Spielzeug herum. Leg dich nicht mit dem Spielzeug anderer Leute an.
Ich war in einer ähnlichen Situation, als wir ein Softwareprodukt verkauften, das unter einer technischen Verschuldung litt, die der Steuerverschuldung Griechenlands entspricht, und sehr wenig Anzeichen dafür, dass die Dinge in die andere Richtung gehen*. Die stabile und stressarme Umgebung machte es zu einem idealen Ort, um sich zurückzuziehen, aber für einen jungen Entwickler, der gerade erst anfing, war es nichts für mich.
Ich habe diesen Job gekündigt und bin zu einem Beratungsunternehmen gegangen, wo ich jedes Jahr an neuen Projekten arbeite und wir die neuesten und besten Technologien nutzen können, wann immer wir können.
Also, nein, du bist nicht im falschen Beruf, nur in der falschen Firma.
* Sie brachten VC-Finanzierung ein, während ich ging, und der neue Geldzufluss, gepaart mit dem ständigen Jammern der Mehrheit der Entwickler, überzeugte das Management, ihre Kernprodukte von Grund auf neu zu entwickeln, und versetzte die aktuellen Produkte in den Wartungsmodus mit begrenzter Entwicklung. Ich war sehr froh, das zu hören, und wünschte, der Prozess hätte begonnen, während ich dort war, damit ich daran arbeiten könnte, aber ich würde nicht zurückkehren.
tl;dr Im Gegenteil, Sie sollten sich fragen, ob Software Engineer der richtige Karriereweg ist, wenn Sie aufhören, sich um Qualität zu kümmern.
Es gibt gute Bücher über den Umgang mit Legacy-Software (zum Beispiel den Dauerbrenner Working Effectively With Legacy Code ); Der Punkt ist, dass Sie nicht fragen müssen, um gute Software zu schreiben, da Sie nicht fragen müssen, um den von Ihnen geschriebenen Code zu testen. Das Refactoring und die Verbesserung der Qualität von vorhandenem Code ist fast immer Teil des Wartungsprozesses, da das Schreiben von Tests auch Teil der Bereitstellung eines neuen Features ist. Verwandt und interessant: Als Entwickler; Keine Zeit zum Testen bekommen, extreme Deadlines erhalten und vom Manager nicht angehört werden .
Sie können jedes Mal davonlaufen und der perfekten Firmenchimäre mit der perfekten Codebasis (oder immer neuen Projekten ohne Altlasten) nachjagen. Alternativ können Sie diese Herausforderung annehmen und dem Unternehmen, für das Sie arbeiten, Ihren eigenen beruflichen Wert hinzufügen.
Die Arbeit an älteren Projekten wird Ihnen auch äußerst wichtige Lektionen über Skalierbarkeit, Zuverlässigkeit und Wartbarkeit beibringen, die Sie niemals lernen werden, wenn Sie jedes Jahr oder so zu neuen Projekten wechseln.
Was Sie verbessern können, ist Ihre Herangehensweise an das Problem. Zunächst einmal müssen Sie verstehen, dass technische Schulden in fast jedem Softwareprojekt enthalten sind , dies ist ein grundlegender Punkt und Sie können ihn nicht ändern. Wie Sie bereits wissen, kann eine technische Schuld aus vielen Gründen hoch sein:
Nachdem Sie diese Offenbarung angenommen haben, müssen Sie verstehen, wie Sie damit umgehen . Manchmal ist eine komplette Neufassung eine mögliche Wahl, aber normalerweise müssen Sie Ihren Managern erklären, welchen Wert diese große Investition dem Unternehmen bringen wird. Dies wurde viel diskutiert und ich werde es hier nicht wiederholen, die richtige Strategie ist für jeden der oben genannten Fälle etwas anders. Das ist der Hauptpunkt: Ein nicht-technischer (aber auch ein technischer, weil er die Dinge von seiner Position aus aus einer anderen Perspektive sehen wird) Manager ist nicht gegen Qualität, aber er muss die Investition rechtfertigen , bedenken Sie:
Was zu tun ist? Beginnen Sie mit der Kommunikation: Erklären Sie zunächst die Situation , aber schimpfen Sie nicht einfach über die Codequalität, sonst werden Sie ungehört:
Wenn sie mit einer solchen Umschreibung nicht einverstanden sind (was durchaus sein kann), müssen Sie im Rahmen Ihrer täglichen Aufgaben einen schrittweisen Ansatz verfolgen.
Was Sie tun können, ist zu verstehen, dass es IHRE PFLICHT ist, guten Code mit allen Einschränkungen zu schreiben, die von Ihrem Management vorgegeben werden (Zeit, Budget, Ressourcen). Das bedeutet, dass Sie:
Iterieren Sie oft genug und Ihre Codebasis wird jetzt gut genug sein . Manchmal müssen einige große architektonische Änderungen genehmigt werden, weil sie zu lang oder komplex sind, aber wenn Sie an diesem Punkt angelangt sind, haben Sie wahrscheinlich bereits eine solide Basis.
Dies ist ein unsichtbarer Prozess, die Qualität entwickelt sich ständig weiter, ist aber nicht unbedingt von außen sichtbar. Ich denke, das ist, was Tom (der Chef des ersten Chefs) versucht hat, Ihnen zu sagen: „Mach deine Arbeit (Schritt für Schritt!), ohne deinen Chef zu stören, es ist deine Pflicht, und ich vertraue darauf, dass du weißt, wie es geht (schick ihn zu mir falls er das im Einzelfall nicht versteht)." Sollte er mit Ihrem Chef darüber sprechen müssen? Ich kann es nicht sagen, aber wenn Sie Ihre Arbeit auf nicht destruktive Weise erledigen, dann ist der Prozess unsichtbar und effektiv.
Manchmal sind sie [Management/Chef] schuld, aber es ist oft ein Kommunikationsproblem . Vielleicht möchten Sie Representation and Misrepresentation: Tufte and the Morton Thiokol Engineers on the Challenger und den Originaltext von Tufte in Visual Explanations: Images and Quantities, Evidence and Narrative lesen .
Ja, viele größere Unternehmen haben Gruppen von „Unberührbaren“, in denen neue Leute hinzukommen, und sie wollen nicht, dass Sie ein „funktionierendes“ Produkt kaputt machen. Ich habe es bei meiner letzten Firma gesehen. Eine kleine Gruppe von Leuten entwickelte die Hauptsoftware für das Unternehmen. Sie alle stiegen in Führungspositionen auf und hatten ein hohes Ansehen beim oberen Management. Sie stellen neue Entwickler ein, weil sie begründet haben, dass sie neue Entwickler brauchen, um das Wachstum des Produkts fortzusetzen. Neue Leute kommen hinzu, und die ursprüngliche Gruppe, die es gemacht hat, erwartet einfach, dass die neueren Entwickler so an dem Produkt arbeiten, wie sie es wollen.
Es ist ziemlich üblich in Unternehmen, die in einen Nischenmarkt eingestiegen sind. In meiner letzten Firma hatten sie nie Software oder IT-bezogene Produkte, und als sie in diesen Markt vordrangen, machten die Leute, die ursprünglich eingestellt wurden, es groß, da sie die "go to"-Gruppe wurden, sobald die Software ausgereift war. Keiner aus dem oberen Management versteht, wie IT-Entwicklung funktioniert, und verlässt sich auf die ursprüngliche Gruppe von Entwicklern. Sie kümmern sich nur um die Einnahmen und ob sie reinkommen. Sie feuern schnell jeden neu eingestellten Manager, der diese Erwartung nicht erfüllt.
Sie müssen ein Unternehmen finden, das entweder nicht allein auf Gewinne setzt, oder ein gut etabliertes Unternehmen finden, das schon immer im IT-Bereich tätig war, mit IT-Führungskräften und dem oberen Management.
Das kannst du normalerweise herausfinden, ohne direkt zu fragen. Fragen Sie einfach den Hauptvorgesetzten, wie er zu seiner Position im Unternehmen gekommen ist. Wenn er dir eine Geschichte wie oben erzählt, dann weißt du, was dich erwartet.
Dunkle Materie
anon