Ich hatte einen 12-Monats-Vertrag (ich lebe in einem Land, in dem dies für neue Entwickler nicht üblich ist), bis mir die Geschäftsleitung meines Unternehmens vor ein paar Wochen ein Angebot und eine Gehaltserhöhung für eine Festanstellung machte. Ich möchte meinen Lebenslauf immer auf dem neuesten Stand halten (vor allem wegen COVID), also habe ich gegoogelt, ob ich es in meinem Lebenslauf aufführen kann.
Die Ratschläge, die ich fand, lauteten, dass ich im Allgemeinen aufführen sollte, welche Leistung der Anlass für die Einstellung war. Gut und schön.
Das Problem ist, dass die Leistung immer darin bestand, knappe Kundenfristen einzuhalten, und ehrlich gesagt, habe ich das geschafft, indem ich entschieden habe, dass die Technik in bestimmten Fällen nicht so hervorragend sein kann (womit das Management einverstanden war).
Ich bin ein relativ junger Entwickler in einem Team von 6 Entwicklern. Ich habe mich jedoch schnell zu einem der Entwickler entwickelt, dem das Management am meisten vertraut, wenn es darum geht, Dinge zu liefern, wenn ich sage, dass ich sie liefern werde, und sie über die relativen Kompromisse auf dem Weg dorthin zu informieren. In meiner zugegebenermaßen kurzen Zeit hier war ich immer in der Lage, etwas zu liefern, wenn ich gesagt habe, dass ich es liefern kann.
Ich hatte schon ein paar solcher Fälle, aber das hier ist der, den ich kurz vor dem Angebot der Festanstellung gemacht habe. Eines unserer Produkte ist eine Batch-API, die einmal am Tag von einem einzigen Kunden aufgerufen wird. Sie muss nichts zurückgeben, außer einer CSV-Datei der fehlgeschlagenen Einträge per E-Mail. Das Unternehmen wollte eine neue Funktion hinzufügen, und der Vertriebsmitarbeiter hatte sich vertraglich verpflichtet, sie bis Ende des Monats bereitzustellen. Aus verschiedenen Gründen wurde die Anfrage für diese Funktion erst am Montag der letzten Woche des Monats an uns weitergeleitet.
Der leitende Entwickler teilte dem Manager mit, dass die Entwicklung nicht ordnungsgemäß durchgeführt werden könne und er dem Kunden sagen solle, dass dies nicht möglich sei. Ich widerspreche den Senior-Entwicklern in Sprint-Planungsmeetings nicht, aber vielleicht war es offensichtlich, dass ich mit dem Senior nicht einverstanden war. Ich habe nicht widersprochen, aber es gab eine Option mit bestimmten Nachteilen. Die anderen Entwickler sind auch ziemlich passiv, also hat ihm auch niemand sonst widersprochen. Der Vorgesetzte war darüber nicht glücklich, da der Kunde bereits wütend auf uns ist, weil wir nicht liefern, obwohl wir es versprochen haben. Der Manager hat mich dann nach der Besprechung in sein Büro gerufen, um zu fragen, ob ich eine Alternative sehe. Ich sagte ihm, dass ich eine Lösung finden könnte, die aber wahrscheinlich die Verarbeitungszeit der API verdoppeln würde (was 4 Minuten zusätzlich bedeuten würde), da ich keine speziellen SQL-Kenntnisse habe. Der Manager stimmte zu, und der Kunde hat es offenbar nicht einmal bemerkt.
Ich bin mir nicht sicher, welche Folgen das Verpassen der Frist gehabt hätte, aber sie waren so gravierend, dass der Geschäftsführer unseres 1000-Mann-Unternehmens mir eine Dankes-E-Mail für die Lieferung schickte.
Ein anderer Fall hat nicht so viel Aufmerksamkeit erregt, aber es ging um einen Prozess, den wir in einer Datenbank durchführen mussten. Der korrekte Weg wäre gewesen, einen richtigen Batch-Prozess in das von uns verwendete Java-System zu schreiben, ihn durch alle regulären QS-Prozesse zu schicken und ihn zwei Wochen später am Ende herausspringen zu lassen. Ich bot dem Manager ein Python-Skript an, das manuell ausgeführt werden müsste und furchtbar ineffizient wäre (man müsste es über Nacht laufen lassen), das aber, wenn es einmal im Monat ausgelöst würde, das Problem in Schach halten würde, bis eine dauerhafte Lösung gefunden wäre. Da es sich um ein Produktionsproblem handelte, stimmte er dem als Überbrückungsmaßnahme zu. Es handelte sich im Grunde nur um eine billige for-Schleife, die Zeilen auf eine bestimmte Art von fehlerhaften Daten überprüfte und diese neu formatierte.
Gibt es eine Möglichkeit, diese Art von Dingen in meinem Lebenslauf aufzuführen, ohne dass ich wie ein Programmierer aussehe, der ältere Entwickler untergräbt? Ich gebe zu, dass meine Lösungen technisch nicht einwandfrei sind, aber sie entsprachen den damaligen geschäftlichen Erfordernissen, und der Kompromiss der Ineffizienz war in den meisten Fällen irrelevant.
Sie haben mehrere wirksame (nicht effiziente) Wege gefunden, um Probleme zu lösen, ohne sie zu sehr in die Länge zu ziehen, und "Geschafft ist besser als perfekt"
Eine Lösung zu finden, die gerade gut genug ist, ist eine wichtige Fähigkeit für einen Ingenieur, da man sonst viel Zeit damit verbringen würde, etwas zu optimieren, das es nicht wert ist, optimiert zu werden. Wenn etwas nicht oft benutzt wird, lohnt es sich oft nicht, es zu optimieren. Es gibt einen netten XKCD-Comic mit einer Tabelle, die einem sagt, wie viel Zeit man in etwas investieren sollte.
Eine Lösung ist nur dann etwas wert, wenn sie benutzt wird (oder werden kann), also hat man mit einem Hack dem Kunden ermöglicht, so lange zu arbeiten, bis man eine Lösung hat.
Es gibt keinen Grund, jemandem zu sagen, dass Sie mit Ihrem Vorgesetzten nicht einverstanden waren. Wählen Sie einfach etwas wie "In der Lage, unter Zeitdruck effektive Lösungen zu erarbeiten".
Ich gebe zu, dass meine Lösungen technisch nicht einwandfrei sind, aber sie waren aber sie waren gut für die damaligen geschäftlichen Erfordernisse, und die Ineffizienz war in den meisten Fällen weitgehend irrelevant.
Sie hatten nur eine Aufgabe: "eine Lösung zu finden, die innerhalb der vorgegebenen Zeit läuft und die Aufgabe löst". Und genau das haben Sie getan.
Ich habe das Gefühl, dass hier nur das Management Antworten gegeben hat, denn es war nichts als Lob für die Einhaltung unangemessener Fristen.
Es gibt hier einen anderen Gesichtspunkt. Sie sollten die sozialen Unruhen nicht unterschätzen, die Sie innerhalb des Entwicklerteams auslösen, wenn das Management an den Ecken und Kanten spart und die Meinungen der leitenden Entwickler ignoriert. Es gibt ein Sprichwort, das ungefähr so lautet:
Solange es jemanden gibt, der ständig das Feuer löscht, wird das Management nicht aufhören, mit Spielen zu spielen.
Es ist eine Sache, wenn man ein- oder zweimal den hackigen Weg geht, weil man dazu gezwungen wird, aber eine ganz andere, wenn es zur Normalität wird. Und Ihrer Beschreibung entnehme ich, dass sich das Management mit der Praxis, Sie zum Sparen zu benutzen, recht wohl fühlt. Sie sollten ernsthaft erwägen, diese Frage Ihrem Management und Ihren leitenden Angestellten gegenüber zur Sprache zu bringen, um ein gesundes Arbeitsumfeld zu erhalten. Ein Unternehmen ist ein Gleichgewicht zwischen Entwicklung und Management und nicht nur eine Top-down-Struktur. Es gibt einen Grund, warum es das Wort "nein" gibt, und Sie sollten sich darin üben, es zu benutzen.
Allerdings ist dies immer noch mehr eine Frage des Managements als Ihre. Daher gibt es keinen Grund, dies in Ihrem Lebenslauf irgendwie zu erwähnen. Ich würde mich dem also anschließen:
in der Lage, Fristen einzuhalten
Wie das Sprichwort "Das Perfekte ist der Feind des Guten" besagt, ist das Eingehen von technischen Kompromissen zur Erfüllung der geschäftlichen Anforderungen so ziemlich das A und O. Die guten Entwickler/Programmierer/Ingenieure sind diejenigen, die in der Lage sind, die akzeptablen Kompromisse zu erkennen, die eingegangen werden können.
In Ihrem API-Beispiel war der Kunde eindeutig eher bereit, eine 4-minütige Verzögerung bei der Verarbeitung in Kauf zu nehmen, um etwas zu erhalten, das funktionierte und pünktlich geliefert wurde.
Idealerweise sollte man bei solchen Kompromissen darauf achten, die technische Schuld zu minimieren - aber das ist alles Teil der Erfahrung und des Wissens, wo man Zeit einsparen kann und wann man sicherstellen muss, dass etwas richtig gemacht wird, um langfristig mehr Zeit zu sparen.
Meine grundsätzliche Frage ist: Gibt es eine Möglichkeit, diese Dinge in meinem Lebenslauf aufzuführen, ohne dass ich wie ein Programmierer aussehe, der ältere Entwickler untergräbt?
Wenn es um Ihren Lebenslauf geht, brauchen Sie nicht auf die Einzelheiten Ihrer Lösung einzugehen - Sie können einfach sagen, dass Sie eine gute Erfolgsbilanz bei der Einhaltung von Fristen bei zeitkritischen Projekten haben, und die Beispiele ohne Einzelheiten der tatsächlichen Umsetzung erwähnen.
Was Sie tun, ist KEIN "Hacken", es ist "Lösungen finden".
Ich arbeite jetzt seit 20 Jahren als Entwickler und Berater, und diese Fähigkeit ist es, wonach Arbeitgeber suchen: Lassen Sie es nicht in Ihrem Lebenslauf weg, sondern betonen Sie genau das: Sie versuchen, Lösungen zu finden, auch wenn das bedeutet, "ungewöhnliche" Wege zu gehen.
Schreiben Sie nicht, dass Sie das hinter dem Rücken von erfahrenen Entwicklern tun, sondern dass Sie das immer tun, wenn Sie nach Lösungen gefragt werden, auch wenn erfahrenere Leute anderer Meinung sind / sagen, dass es nicht möglich ist.
Es gibt ein großartiges Zitat, das angeblich von Albert Einstein stammt und Ihre Situation genau beschreibt:
Jeder wusste, dass es unmöglich war, bis ein Narr, der es nicht wusste, daherkam und es tat.
Ich habe mit vielen Entwicklern zusammengearbeitet und kenne jede Facette davon:
Ich habe mit einem Entwickler gearbeitet, der zu den Top 1% der JavaScript-Experten bei stackoverflow gehört. Er ist ein Genie und ich bewundere wirklich jede Zeile Code, die er schreibt. Aber sehr oft hat er seine Projekte nicht zu Ende gebracht: Lieber stellte er etwas nicht fertig, als dass er es beendete, wenn er mit der Schönheit des Codes nicht zufrieden war.
Und ich habe mit Entwicklern zusammengearbeitet, die zwar extrem effizient waren, aber dafür viele Abkürzungen nahmen, die die Lösungen fast unwartbar machten (hartcodierte Pfade, magische Zahlen usw.).
Und ich habe immer "fertig" gegenüber "schön" bevorzugt, und meine Kunden taten das letztendlich auch: Sie haben lieber "etwas", wenn die Deadline da ist, als "nichts, aber es wird in einiger Zeit X" schön sein;
Nur eines: Workarounds / Shortcuts / "Hacks" müssen verständlich, dokumentiert und wartbar sein, dann spricht nichts gegen Lösungen wie Sie
Sie beschreiben technische Schulden, und technische Schulden sind nicht immer schlecht. Die Analogie der Verschuldung erstreckt sich darauf, dass es viele legitime Gründe gibt, warum ein Unternehmen finanzielle Schulden aufnimmt. Der Schlüssel dazu ist, dass es beabsichtigt ist und dass es einen realistischen Plan gibt, sie zurückzuzahlen. Martin Fowler hat ausführlich darüber geschrieben, insbesondere über das, was er den [technischen Schuldenquadranten] nennt (https://martinfowler.com/bliki/TechnicalDebtQuadrant.html):
Es klingt, als hätten Sie eine kluge Entscheidung bezüglich der technischen Verschuldung getroffen. Zu erkennen, wo technische Verschuldung klug ist, und zu wissen, wie man damit umgeht, sind äußerst wertvolle Fähigkeiten.
Die Frage "Ist Ihr Lebenslauf der richtige Ort für diese Geschichte?" lasse ich beiseite. Vielleicht hat der Lebenslauf keinen Platz für solche Details, aber nehmen wir an, es ist die Art von Dingen, die in einem Interview auftauchen könnten, und Sie möchten darüber nachdenken, wie Sie es im besten Licht präsentieren können. Auf jeden Fall lohnt es sich, auch wenn niemand mehr darüber spricht, über die Auswirkungen auf die eigene berufliche Entwicklung nachzudenken. Nun, hier ist die eine Bemerkung, die ich vorschlagen würde und die niemand sonst erwähnt hat:
Sie haben immer noch den Job.
Sie prüfen, wie Sie die Geschichte am besten präsentieren können, haben aber auch das Privileg, die Geschichte verändern zu können.
Sie haben also eine Ermessensentscheidung getroffen und sind ein Risiko eingegangen. Dadurch ist es Ihnen gelungen, einen Abgabetermin mit voller beobachtbarer Funktionalität einzuhalten, einen Kunden zufriedenzustellen und Ihre Manager zu beeindrucken. Aus diesem Grund lieferten Sie auch eine Lösung mit höheren Ausführungskosten als nötig, gefährdeten möglicherweise das Design der Codebasis und brachten Ihre Teamleiter in Verlegenheit. Das ist eine vernünftige Entscheidung, die Sie treffen müssen. Andere haben bereits erklärt, wie man das darstellen kann: Sie lassen den teaminternen Konflikt ganz aus der Geschichte heraus, Sie nennen ausdrücklich die technischen Probleme mit Ihrer Lösung, die Sie erkannt haben, zusammen mit dem Bewusstsein für die Geschäftsrealität, und Sie erklären, dass Sie einen Anruf getätigt haben.
Aber wenn Sie eine bessere Geschichte erzählen könnten, würde sie sowohl die Aufnahme als auch die Tilgung dieser Schulden beinhalten. Dazu würde auch gehören, dass Sie sich ein wenig Zeit für die Überprüfung nehmen, jetzt, wo die Frist nicht absehbar ist, vielleicht, um den Code besser zu kapseln und ein paar wichtige Unit-Tests hinzuzufügen. Es könnte bedeuten, zwei der zusätzlichen vier Minuten einzusparen, vielleicht nach Rücksprache mit Ihrem lokalen SQL-Experten. Dazu würde auch die Suche nach Möglichkeiten gehören, wie Sie die Lorbeeren gnädigerweise mit dem Rest Ihres Teams teilen können.
Wenn Sie nicht den Ruf haben wollen, der sich schnell bewegt und Dinge kaputt macht, bewerten Sie die technischen, geschäftlichen und zwischenmenschlichen Schlamassel, die Ihre Entscheidungen (einschließlich schwieriger, aber sehr vernünftiger Entscheidungen) anrichten, und übernehmen Sie die Verantwortung für deren Klärung.
Sie haben immer noch den Job.
Sie haben also eine Software erstellt, die vier Minuten zum Ausführen brauchte (weil Ihr Code nicht sehr gut war). Wenn ich 12 Stunden brauche, um die Arbeit von Hand zu erledigen, spart mir Ihre Software 11 Stunden 56 Minuten. Wenn Sie besseren Code geschrieben haben, der in 1 Sekunde läuft, spart mir das 11 Stunden, 59 Minuten und 59 Sekunden ein. Wenn der bessere Code eine Woche später geliefert wurde, so dass ich die Arbeit fünfmal von Hand erledigen musste, werden die zusätzlichen 3 Minuten 59 Sekunden die Zeit, die ich verloren habe, niemals wettmachen.
Oder sie noch extremer machen. Die Software muss in 24 Stunden laufen. Ihr Code ist schlecht, deshalb brauchen wir einen 5.000-Dollar-Computer, um ihn in 24 Stunden ausführen zu können. Mit einem besseren Code könnte ein 2.000-Dollar-Computer ihn in 24 Stunden ausführen. Einsparungen von 3.000 Dollar. Wenn Sie zwei Wochen brauchen, um den Code schneller zu machen, ist das ein Gesamtverlust.
In der Lage zu sein, liefern zu können, wenn es gebraucht wird, ist eine sehr, sehr gute Sache. Darüber hinaus kann ein sehr guter Entwickler schlechten Code so schreiben, dass er später leicht verbessert werden kann. Schlechte Entwickler schreiben schlechten Code, der sich nur mühsam in einen guten Zustand refaktorieren lässt, gute Entwickler schreiben unter Zeitdruck schlechten Code, der leicht zu verbessern ist.
Eine Paraphrase von Einstein,
Die Software-Qualität sollte so niedrig wie möglich gehalten werden, aber nicht niedriger.
Ich weiß, dass es viele Entwickler gibt, die stolz auf den Code sind, den sie schreiben, und die dem entschieden widersprechen. Aber aus geschäftlicher Sicht bedeutet eine weitere Verbesserung der Qualität, sobald das Software-Qualitätsziel erreicht ist, zusätzliche Arbeit, die für etwas aufgewendet wird, um das man nicht gebeten wurde oder wofür man nicht bezahlt wird. Absolute Qualität ist einfach nicht erreichbar: Ganz gleich, wie gut Ihre Software ist, es gibt immer Raum für Verbesserungen.
Offensichtlich wurden Sie nicht dafür gelobt, dass Sie die Code-Qualität droppen. Sie wurden dafür gelobt, dass Sie eine akzeptable Code-Qualität aufrechterhalten und gleichzeitig eine Frist eingehalten haben. So sollten Sie es in Ihrem Lebenslauf formulieren.
Ich habe keine bestimmte Meinung darüber, was man dafür in seinen Lebenslauf schreiben sollte, obwohl ich den Antworten, die besagen, dass so etwas nicht wirklich in einen Lebenslauf passt, eher zustimme.
Ich möchte jedoch darauf hinweisen, was passieren würde, wenn ich Sie befragen würde und Sie die Situation so beschreiben würden, wie Sie es in der Frage getan haben.
Mein erster Gedanke wäre: "Gut, ich mag jemanden, der kurzfristig das Notwendige tun kann und gleichzeitig die Kompromisse erkennt, die er eingeht. Aber es gibt auch ein ziemlich klar erkennbares Problem bei der Verwaltung der Software-Projekte Ihrer Firma, um dessen Lösung ich Sie bitten möchte.
Die Antwort, die ich gerne hören würde, ist, dass jemand, der nicht zum technischen Team gehört, einem Kunden zu einem bestimmten Termin etwas versprochen hat, ohne dass eine Schätzung des technischen Teams vorliegt, wann es geliefert werden kann. Das zu tun ist das Rezept für eine langfristige Katastrophe. Wenn Sie diese Art von Problem nicht erkennen könnten, wäre ich sehr vorsichtig, Sie in meinem Team zu haben.
Außerdem muss, sobald das Problem identifiziert ist, jemand langfristige Lösungen dafür implementieren, um sicherzustellen, dass das Problem allmählich reduziert und im Idealfall schließlich beseitigt wird. Ich würde Sie fragen, was Sie in Ihrer neuen Führungsrolle getan haben, um dies zu erreichen. Wenn Sie darauf keine gute Antwort geben könnten, wäre ich wiederum sehr vorsichtig, Sie einzustellen. Die Übernahme von Verantwortung für kostspielige kurzfristige Reparaturen ist großartig, aber wenn Sie nicht die Verantwortung für langfristige Reparaturen übernehmen, die diese kostspieligen kurzfristigen Reparaturen überflüssig machen und dem Unternehmen insgesamt Zeit und Geld sparen, dann würde ich Sie nur für eine Junior-Rolle für geeignet halten, bis Sie das gelernt haben.