Sie haben mehrere effektive (nicht effiziente) Wege gefunden, um Probleme zu lösen, ohne sie zu überarbeiten, und "Fertig ist besser als perfekt"

Eine Lösung zu finden, die gerade gut genug ist, ist eine wichtige Fähigkeit für einen Ingenieur da Sie sonst viel Zeit damit verbringen würden, etwas zu optimieren, das es nicht wert ist, optimiert zu werden. Wenn etwas nicht oft verwendet wird, lohnt es sich oft nicht, es zu optimieren. Es gibt einen schönen XKCD-Comic mit einer Tabelle, die Ihnen sagt, wie viel Zeit Sie in etwas investieren sollten.

Eine Lösung ist nur dann etwas wert, wenn sie verwendet wird (oder verwendet werden kann). Mit einem Hack haben Sie dem Kunden ermöglicht, weiter zu arbeiten, bis Sie eine Lösung gefunden haben.

Es gibt keinen Grund, jemandem mitzuteilen, dass Sie mit Ihrem Vorgesetzten nicht einverstanden sind. Entscheiden Sie sich einfach für etwas wie "Kann unter Zeitdruck effektive Lösungen herstellen".

Ich gebe zu, dass meine Lösungen technisch nicht solide sind, aber sie waren für die damaligen Geschäftsanforderungen solide und der Kompromiss zwischen Ineffizienz war in den meisten Fällen weitgehend irrelevant.

Sie hatten einen Job: "Finden Sie eine Lösung, die innerhalb der Fristen ausgeführt wird, die den Job lösen". Und genau das hast du getan.

Ich habe das Gefühl, dass hier nur das Management Antworten gegeben hat, weil es nichts als Lob gab, sich an unangemessene Fristen zu halten.

Hier gibt es einen anderen Standpunkt. Sie sollten die sozialen Störungen, die Sie im Entwicklerteam auslösen, nicht unterschätzen, wenn das Management Abstriche macht und die Meinungen älterer Entwickler ignoriert. Es gibt ein Sprichwort, das ungefähr so ​​lautet:

Solange es jemanden gibt, der das Feuer ständig löscht, hört das Management nicht auf, mit Streichhölzern zu spielen.

Es ist eine Sache, wenn Sie ein- oder zweimal den hackigen Weg gehen, weil Sie dazu gezwungen sind, aber eine ganz andere, wenn es die Norm bekommt. Und Ihrer Beschreibung nach scheint mir das Management mit der Praxis, Sie zum Schneiden von Ecken zu verwenden, ziemlich vertraut geworden zu sein. Sie sollten ernsthaft darüber nachdenken, dieses Problem bei Ihrem Management und leitenden Entwicklern anzusprechen, um ein gesundes Arbeitsumfeld aufrechtzuerhalten. Ein Unternehmen ist ein Gleichgewicht zwischen Entwickler und Management und nicht nur eine Top-Down-Struktur. Es gibt einen Grund, warum das Wort "Nein" existiert, und Sie sollten es üben.

Dies ist jedoch immer noch eher eine Frage des Managements als Ihres. Daher gibt es keinen Grund, dies in Ihrem Lebenslauf irgendwie zu erwähnen. Also würde ich mitmachen:

in der Lage, Termine einzuhalten

Wie das Sprichwort sagt "Perfekt ist der Feind des Guten" - technische Kompromisse einzugehen, um die geschäftlichen Anforderungen zu erfüllen, ist ziemlich wichtig. Die guten Entwickler / Programmierer / Ingenieure sind diejenigen, die die akzeptablen Kompromisse identifizieren können, die gemacht werden können.

In Ihrem API-Beispiel war der Kunde eindeutig eher bereit, a zu akzeptieren 4 Minuten Verzögerung bei der Bearbeitung für etwas, das funktioniert hat und pünktlich geliefert wurde.

Idealerweise sollten Sie versuchen, die technische Verschuldung zu minimieren, wenn Sie diese Kompromisse eingehen. Dies ist jedoch ein wesentlicher Bestandteil der Erfahrung und des Wissens, wo Sie Zeit sparen können und wann Sie sicherstellen müssen, dass etwas "richtig" gemacht wird Um auf lange Sicht mehr Zeit zu sparen.

Meine grundlegende Frage ist, ob es eine Möglichkeit gibt, diese Art von Dingen in meinem Lebenslauf aufzulisten, die mich nicht wie einen Hack-Programmierer aussehen lassen, der Untergräbt ältere Entwickler?

Wenn es um Ihren Lebenslauf geht, müssen Sie sich nicht mit den Einzelheiten Ihrer Lösung befassen - Sie können einfach sagen, dass Sie eine gute Erfolgsbilanz bei der termingerechten Lieferung haben -sensible Projekte und erwähnen Sie die Beispiele ohne Details der tatsächlichen Implementierung.

Was Sie tun, ist NICHT "hacken", sondern "Lösungen finden".

Ich arbeite seit 20 Jahren als Entwickler und Berater. Diese Fähigkeit ist das, wonach Arbeitgeber suchen: Lassen Sie sie nicht aus Ihrem Lebenslauf heraus, sondern betonen Sie genau das: Sie versuchen, Lösungen zu finden, auch wenn dies "ungewöhnliche" Wege bedeutet.

Schreiben Sie nicht, dass Sie dies hinter dem Rücken älterer Entwickler tun, sondern dass Sie dies tun, wenn Sie nach Lösungen gefragt werden, selbst wenn Sie erfahrenere Leute sind stimme nicht zu / sage, es ist nicht möglich.

Es gibt ein großartiges Zitat von Albert Einstein, das Ihre Situation genau beschreibt:

Jeder wusste, dass es unmöglich war, bis Ein Dummkopf, der es nicht wusste, kam und tat es.

Ich habe mit vielen Entwicklern zusammengearbeitet und kenne jede Facette davon:

Ich habe mit gearbeitet Ein Entwickler, der zu den Top 1% der JavaScript-Experten bei stackoverflow gehört. Er ist ein Genie und ich bewundere wirklich jede Codezeile, die er schreibt. Aber oft beendete er seine Projekte nicht: Er wollte lieber etwas nicht beenden, als es zu beenden, wenn er mit der Schönheit des Codes nicht zufrieden war.

Und ich habe mit Entwicklern zusammengearbeitet, die äußerst effizient waren, aber daher viele Verknüpfungen verwendeten, die die Lösungen fast nicht mehr wartbar machten (fest codierte Pfade, magische Zahlen usw.).

Und ich habe es immer vorgezogen, "fertig" gegenüber "schön" zu machen, und am Ende haben es auch meine Kunden getan: Sie hätten lieber "etwas", wenn die Frist abgelaufen ist, als "nichts, aber es wird in etwas mehr schön sein" Zeit X "

Nur eines: Problemumgehungen / Verknüpfungen /" Hacks "müssen verständlich, dokumentiert und wartbar sein, dann gibt es nichts gegen Lösungen wie Sie

Klingt für mich nach normaler technischer Verschuldung. Der Senior war wahrscheinlich älter und abgestumpft und wollte dem bereits überlasteten Projekt keine weiteren Schulden mehr hinzufügen (ein bisschen wie ich wäre ich derjenige, der dies zurückdrängt). Oder vielleicht haben sie nur versucht, das Team zu beschützen. Schauen wir uns Ihre Frage jedoch direkt an:

Gibt es eine Möglichkeit, diese Art von Dingen in meinem Lebenslauf aufzulisten, die mich nicht wie einen Hack-Programmierer aussehen lassen, der ältere Entwickler untergräbt? P. >

Vielleicht bin ich hier naiv, aber Sie sollten diese Art von Dingen nicht in Ihrem Lebenslauf auflisten. Nur die Gesamterfolge. Wenn dies also die Norm für dieses Unternehmen ist, ist es so, dass Sie "in engen Zeiträumen gearbeitet haben, um Lösungen für Kunden bereitzustellen", anstatt Details darüber, wie Sie ein oder zwei gespeicherte Prozeduren in wenigen Tagen aufgebockt haben, um etwas zu erreichen arbeitet für den Kunden. Wenn ich einen Lebenslauf lese, der besagt, dass Sie unter engen Zeitplänen liefern, verstehe ich das, sagte Nuff.

Das ist alles, was Sie Ihrem Lebenslauf wirklich hinzufügen sollten, selbst dann würde ich es locker halten, wenn Sie für Blah Inc. als arbeiten Ein Entwickler, der mit SQL und anderen technischen Dingen arbeitet. Warum muss dies überhaupt in Ihrem Lebenslauf stehen?

Sie beschreiben technische Schulden, und technische Schulden sind nicht immer schlecht. Die Analogie der Verschuldung erstreckt sich auf viele legitime Gründe, warum ein Unternehmen Finanzschulden aufnehmen würde. Der Schlüssel ist, dass es beabsichtigt ist und es einen realistischen Plan gibt, um es auszuzahlen. Martin Fowler hat ausführlich darüber geschrieben, insbesondere was er den technischen Schuldenquadranten nennt:

Es klingt als ob Sie eine umsichtige Entscheidung bezüglich der technischen Verschuldung getroffen hätten. Das Erkennen, wo technische Schulden umsichtig sind, und das Wissen, wie man damit umgeht, sind äußerst wertvolle Fähigkeiten.

Ich muss sagen, ich würde Sie nicht einstellen wollen, und das liegt nicht daran, dass Sie Kompromisse geschlossen haben. Das ist ein wichtiger Teil des Jobs und eine schwer zu erwerbende Fähigkeit. Dies liegt daran, dass Sie blinde Kompromisse geschlossen haben, ohne die Erfahrung des Restes Ihres Teams zu nutzen.

Das Erforschen potenzieller Designs widerspricht keinem erfahrenen Entwickler. Das Gespräch hätte ungefähr so ​​verlaufen sollen:

Sie: Was wäre, wenn wir X machen würden?

Senior dev: Das würde wahrscheinlich die Verarbeitungszeit verdoppeln. Ich glaube nicht, dass der Kunde damit zufrieden wäre.

PM: Eigentlich denke ich, dass sie es lieber langsam als gar nicht haben würden. Ich werde mich mit ihnen in Verbindung setzen, um sicherzugehen.

Anderer Junior: Bob weiß viel über SQL. Wenn wir ihn dazu bringen können, zu helfen, könnte er wahrscheinlich viel Zeit sparen.

Senior Dev: Aber ich mache mir immer noch Sorgen um den Eckfall Y. Es würde einige Zeit dauern, um das richtig zu testen . Das wäre wirklich peinlich, wenn wir das falsch verstehen würden.

PM: Ich stimme zu. Wenn Sie an den Tests arbeiten und OP mit Bob zusammenarbeitet, um die API zu ändern, wie er sagte, könnte dies geschehen?

Senior dev: Ich denke schon für die Frist, aber ich würde zurückgehen wollen und bereinigen Sie es für die nächste Version. Andernfalls riskieren wir jedes Mal, wenn der Kunde dies tut, Y-Wartungskopfschmerzen.

PM: Okay.

Außerdem tauchen diese Dinge auf auf Interviews. Der Interviewer sieht so etwas wie "anerkannt für Kompromisse, um Wert innerhalb enger Fristen zu liefern" und fragt nach einem Beispiel. Anschließend stellt er so ziemlich die gleichen Fragen, die Ihr leitender Entwickler haben würde.

Ich werde die Frage hinterlassen: "Ist Ihr Lebenslauf der richtige Ort für diese Geschichte?" zu einer Seite. Vielleicht hat der Lebenslauf keinen Platz für solche Details, aber sagen wir, 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. Selbst wenn niemand mehr darüber spricht, lohnt es sich auf jeden Fall, über die Auswirkungen auf Ihre eigene berufliche Entwicklung nachzudenken. Hier ist die einzige Beobachtung, die ich vorschlagen würde, die von niemand anderem erwähnt wurde:

Sie haben noch den Job.

Sie ' Ich schaue mir an, wie ich die Geschichte am besten präsentieren kann, habe aber auch das Privileg, die Geschichte ändern zu können.

Sie haben also ein Urteil gefällt und sind ein Risiko eingegangen. Aus diesem Grund haben Sie es geschafft, eine Frist mit voller beobachtbarer Funktionalität einzuhalten, einen Kunden zufrieden zu stellen und Ihre Manager zu beeindrucken. Aus diesem Grund haben Sie auch eine Lösung mit höheren Ausführungskosten als erforderlich geliefert, möglicherweise das Design der Codebasis beeinträchtigt und Ihre Teamleiter in Verlegenheit gebracht. Dies ist eine vernünftige Entscheidung. Andere haben bereits erklärt, wie man das präsentiert: Sie lassen den teaminternen Konflikt ganz aus der Geschichte heraus, geben explizit die technischen Probleme mit Ihrer Lösung an, die Sie erkannt haben, zusammen mit dem Bewusstsein für die geschäftliche Realität, und Sie erklären, dass Sie eine gemacht haben Anruf.

Aber wenn Sie eine bessere Geschichte erzählen könnten, würde dies das Aufnehmen und Löschen dieser Schulden beinhalten. Es würde ein wenig Überprüfungszeit in Anspruch nehmen, da sich die Frist nicht abzeichnet, um den Code möglicherweise besser zu kapseln und einige wichtige Komponententests hinzuzufügen. Dies kann bedeuten, dass Sie zwei der zusätzlichen vier Minuten sparen und sich möglicherweise an Ihren lokalen SQL-Experten wenden. Dazu gehört die Suche nach Möglichkeiten, den Kredit mit dem Rest Ihres Teams zu teilen.

Wenn Sie keinen Ruf als der Typ haben möchten, der sich schnell bewegt und Dinge kaputt macht, bewerten Sie die technischen, geschäftlichen und zwischenmenschlichen Probleme, die Ihre Entscheidungen (einschließlich harter, aber sehr vernünftiger Entscheidungen) treffen, und übernehmen Sie die Verantwortung für deren Aufklärung.

Sie haben noch den Job.

Das Problem ist, dass die Leistung immer zu engen Kundenfristen erbracht wurde, und ehrlich gesagt habe ich entschieden, dass das Engineering in bestimmten Fällen weniger als herausragend sein kann (dem das Management zugestimmt hat).

Ich bin mir nicht sicher, welche Konsequenzen es hätte haben können, wenn die Frist nicht eingehalten worden wäre, aber sie waren so hoch, dass der CEO unseres 1000-Personen-Unternehmens mir eine Dankes-E-Mail für die Zustellung geschickt hat.

Ist da? Eine Möglichkeit, diese Art von Dingen in meinem Lebenslauf aufzulisten, die mich nicht wie einen Hack-Programmierer aussehen lässt, der ältere Entwickler untergräbt?

Ihr Lebenslauf sollte die Errungenschaft "... hervorgebracht" hervorheben Enge Kundenfristen und eine Dankes-E-Mail vom CEO erhalten. "

Wie Sie dorthin gekommen sind, kann in einer Interview-Umgebung auftauchen oder nicht, aber es gehört nicht in den Lebenslauf.

Manchmal erfordern Geschäftsentscheidungen Schnelligkeit. Ich kann Ihnen aus persönlicher Erfahrung sagen, dass Manager Menschen schätzen, die einen Weg finden, wichtige Dinge zu erledigen.

Sie haben also eine Software erstellt, deren Ausführung vier Minuten dauerte (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 ausgeführt wird, spart ich 11 Stunden, 59 Minuten und 59 Sekunden. Wenn der bessere Code eine Woche später geliefert wurde und ich die Arbeit fünfmal manuell ausführen musste, werden die zusätzlichen 3 Minuten und 59 Sekunden die verlorene Zeit nie wieder wettmachen.

Oder machen Sie es extremer. Die Software muss in 24 Stunden ausgeführt werden. Ihr Code ist schlecht, daher benötigen wir einen Computer im Wert von 5.000 US-Dollar, um ihn innerhalb von 24 Stunden ausführen zu können. Mit besserem Code könnte ein Computer im Wert von 2.000 US-Dollar ihn in 24 Stunden ausführen. Einsparungen von 3.000 USD. Wenn Sie zwei Wochen brauchen, um den Code schneller zu machen, ist dies ein Gesamtverlust.

Es ist sehr, sehr gut, liefern zu können, wenn es gebraucht wird. 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 schwer in eine gute Form zu bringen ist. Gute Entwickler schreiben unter Zeitdruck schlechten Code, der leicht zu verbessern ist.

"Was ist das, sagst du?"

Das Problem ist, strike> die Leistung (!) i> lieferte b> immer enge Kundenfristen und ehrlich gesagt, strike> Ich tat es b>, indem ich entschied, dass das Engineering in bestimmten Fällen weniger als hervorragend sein könnte (dem das Management zugestimmt hat). b>

Und ... (!)

Ich bin mir nicht sicher, welche Konsequenzen das Fehlen des Die Frist wäre abgelaufen, aber sie waren so hoch, dass der CEO unseres 1000-Personen-Unternehmens i> eine Dankes-E-Mail an mich (!) i> b> gesendet hat liefern es.

"Dude .... !!!" b> Ich möchte you!!! i> b>

... es sei denn, Sie werden zuerst Unternehmensberater!

Einstein umschreiben,

Die Softwarequalität sollte so niedrig wie möglich gehalten werden, aber nicht niedriger.

Ich weiß, dass es viele Entwickler gibt, die stolz sind im Code schreiben sie und stimmen dem überhaupt nicht zu. Aus geschäftlicher Sicht bedeutet eine weitere Verbesserung der Qualität jedoch, sobald das Softwarequalitätsziel erreicht ist, zusätzliche Arbeit für etwas, das Sie nicht tun oder für das Sie nicht bezahlt wurden. Absolute Qualität ist einfach nicht erreichbar: Egal wie gut Ihre Software ist, es gibt immer Raum für Verbesserungen.

Natürlich wurden Sie nicht dafür gelobt, dass Sie die Codequalität verlieren. Sie wurden dafür gelobt, dass Sie eine akzeptable Codequalität beibehalten und gleichzeitig eine Frist einhalten. So sollten Sie es in Ihrem Lebenslauf formulieren.

Ich habe keine besondere Meinung darüber, was Sie in Ihren Lebenslauf aufnehmen sollen, obwohl ich eher den Antworten zustimme, die besagen, dass so etwas nicht wirklich in einen Lebenslauf passt.

Allerdings Ich möchte darauf hinweisen, was passieren würde, wenn ich mit Ihnen sprechen 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 kann, was kann kurzfristig notwendig, während er die Kompromisse erkennt, die er eingeht. " Es gibt aber auch ein ziemlich klar erkennbares Problem bei der Verwaltung der Softwareprojekte in Ihrem Unternehmen, das Sie identifizieren sollten.

Die Antwort, die ich hören möchte, ist, dass jemand, der nicht zum technischen Team gehört, etwas versprochen hat ein Kunde innerhalb einer bestimmten Frist ohne einen Kostenvoranschlag des technischen Teams, wann er geliefert werden könnte. Dies zu tun ist ein Rezept für eine langfristige Katastrophe. Wenn Sie diese Art von Problem nicht identifizieren könnten, wäre ich sehr vorsichtig, Sie in meinem Team zu haben.

Sobald das Problem identifiziert ist, muss jemand langfristige Korrekturen implementieren, um dies zu beheben Stellen Sie sicher, dass das Problem schrittweise reduziert und im Idealfall schließlich behoben 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 finden könnten, wäre ich wieder ziemlich vorsichtig, wenn ich Sie einstellen würde. Die Verantwortung für kostspielige kurzfristige Korrekturen zu übernehmen ist großartig, aber wenn Sie nicht die Verantwortung für langfristige Korrekturen übernehmen, die diese kostspieligen kurzfristigen Korrekturen überflüssig machen und dem Unternehmen insgesamt Zeit und Geld sparen, würde ich Sie in Betracht ziehen Nur für eine Junior-Rolle geeignet, bis Sie das gelernt haben.