Wie erklärt man einem Programmierer geschäftliche Prioritäten?

Ich würde nicht versuchen, seinen Programmierstil zu diktieren, sondern ihn so machen lassen, wie er will. Wenn die Leistung eine tatsächlich dokumentierte Geschäftsanforderung ist und er sie nicht erfüllt, rufen Sie ihn darauf hin.

Wenn er weiterhin die geschäftlichen Anforderungen nicht erfüllt, dann versagt er seiner Arbeit, beginnen Sie damit, ihm offizielle mündliche und dann schriftliche Verwarnungen zu erteilen, und lassen Sie ihn dann gehen, wenn Sie müssen.

Es sieht so aus, als hätten Sie eine Primadonna oder noch schlimmer, Michel Angelo, der für Sie arbeitet. Wie lange ist er schon im Programmiergeschäft? Ich stelle diese Frage, weil es einen großen Unterschied zwischen Programmieren und Programmieren gibt. Diejenigen, die schon länger in den Schützengräben sind, können ihm sagen, dass Perfektion hässlich sein kann.

Sein Code mag lehrbuchmäßig gut sein, aber die Realität ist, dass dieser Code funktionieren muss und Code, der 4 Stunden zum Ausführen braucht, statt 30 Sekunden – dieser Code kann kaum als leistungsfähig bezeichnet werden. Ich mache Software-Engineering, aber von der Devops-Seite des Hauses: Wenn der Code nicht skalierbar ist, ist dieser Code nicht gut, unabhängig davon, wie gut dieser Code geschrieben und dokumentiert ist. Und belastbarer, wartbarer Code, der schlecht funktioniert, ist nicht gut. Soweit es mich betrifft, versteht er entweder, was ich sage, oder er ist weg. Er hat den Spielraum, den Code in seinem eigenen Stil zu schreiben, aber dieser Code MUSS funktionieren.

Sagen Sie ihm nicht, er solle gegen das Muster vorgehen. Sagen Sie ihm, was Ihre Anforderung ist, geben Sie ihm eine Frist und geben Sie ihm den Spielraum, um herauszufinden, wie er diese erfüllen kann. Angesichts seiner Leidenschaft dafür, dass sein Code lehrbuchhaft geschrieben wird, hat er jeden Anreiz, Ihre Anforderungen zu erfüllen und gleichzeitig seinen Code so lehrbuchhaft wie möglich zu halten, und das ist keine schlechte Sache.

Als sein Manager müssen Sie ihm den Rang abtreten und das Gesetz festlegen. Sie müssen ihm sagen, dass er für die Leistung in seinem Kodex verantwortlich ist, und Sie müssen sicherstellen, dass Sie von den höheren Stellen die Befugnis haben, diese Verantwortlichkeit durchzusetzen. Ich werde ihm einen Anreiz geben, ihn zu belasten: Als sein Manager werden SIE zur Rechenschaft gezogen, wenn sein Kodex nicht funktioniert. Setzen Sie ihn in Verlegenheit, denn wenn Sie dies nicht tun, werden Sie die erste Person sein, die Ihr Top-Management verfolgt.

Sie sagen, dass Sie "technisch" sein Manager sind. Nun, entweder sind Sie sein Manager oder nicht. Entscheide dich (*)

Wenn Sie sein Vorgesetzter sind, ist er Ihnen gegenüber rechenschaftspflichtig, so wie Sie Ihrem Management gegenüber rechenschaftspflichtig sind. In diesem Fall ist die Zeit für Erklärungen, auf die er nicht hören will, vorbei. Die nicht verhandelbare Anforderung ist, dass der Code funktionieren muss, und er muss diese Anforderung erfüllen. Das ist alles dazu.

(*) Ich stieß 1987 auf ein ähnliches Problem mit einem Umweltingenieur, der sich nicht an unsere Best Practice hielt, wie sie von Ihnen festgelegt wurde. Und da mein Titel offiziell seinem gleichgestellt war, ignorierte er alles, was ich sagte. Ich vereinbarte einen Dreiertermin zwischen ihm, dem Chef der Abteilung und mir, bei dem ich ausdrücklich darlegte, welche Auswirkungen es hatte, wenn wir unseren Prozess nicht befolgten. Der Honcho befahl ihm, sich daran zu halten, und sagte hinterher unter vier Augen ein paar Worte zu mir über meine Schwerfälligkeit. Der Vorwurf machte mir nichts aus - mir war nur wichtig, dass ich mich fügen ließ und er keine Löcher mehr durch den Boden unseres Schiffes bohrte. Die Eskalation an die Unternehmensspitze war nicht schön anzusehen, aber sie hat funktioniert. Das ist alles, was mir wichtig war.

Als Senior Developer haben Sie beide Recht. Es geht darum, das Gleichgewicht zu finden, auf das Sie hinarbeiten müssen.

Zunächst sollten von Ihrer Seite Ihre Anforderungen klar detailliert werden. Ich würde empfehlen, den Ansatz der verhaltensgesteuerten Entwicklung (BDD) zu verwenden. Auf diese Weise können Sie Ihre Anforderungen detailliert darstellen und sicherstellen, dass die Software diese erfüllt.

Es ist derzeit bewährte Praxis, Praktiken der testgetriebenen Entwicklung (TDD) zu folgen. Dabei schreibt der Entwickler „gerade genug“ Code, um das Problem zu lösen – indem er fehlgeschlagene Tests schreibt und sie zum Bestehen bringt. Diese BDD-Definitionen wären der Ausgangspunkt. Weitere Unit-Tests würden ausfallen, aber sobald alle BDD-Tests grün sind, können Sie sicher sein, dass die Anforderungen erfüllt sind.

Währenddessen wird erwartet, dass Sie einen Dialog fortsetzen - normalerweise zu Beginn und am Ende der Entwicklung. Dadurch wird sichergestellt, dass beide Seiten die Anforderungen verstehen und Unklarheiten ausgeräumt werden. Darüber hinaus könnte dieses Gespräch die Wichtigkeit oder den Wert der Anfrage umreißen.

Es ist wichtig, dass der Code für die zukünftige Entwicklung und Wartung klar und verständlich ist. Es sollte jedoch ein Gleichgewicht zwischen ständigem Polieren und dem Liefern von Wert gezogen werden.

Wenn Sie und er dies nicht getan haben, würde ich vorschlagen, Clean Code: A Handbook of Agile Software Craftsmanship von Robert C. Martin zu lesen .

In Bezug auf Ihre ORM-Debatte – ORMs haben ihre Vor- und Nachteile. Wie Sie bereits betont haben, können sie langsam und ineffizient sein, wenn sie schlecht konfiguriert sind . Darüber hinaus kann das Schreiben von Inline-SQL eine zusätzliche Kopplung zwischen der Datenbank und dem Code hinzufügen. Warum nicht einfach gespeicherte Prozeduren aufrufen ?

Es gibt wahrscheinlich genauso viele Artikel darüber, warum Sie ein ORM im Web verwenden sollten, wie warum Sie es nicht verwenden sollten. Eine Abfrage, deren Ausführung vier Stunden dauert – insbesondere wenn sie auf 30 Sekunden optimiert werden kann – ist jedoch nicht akzeptabel.

Als letzten Gedanken - ist dies Ihr einziger Entwickler? Vielleicht würde er vom Pair-Programming mit anderen profitieren? Vielleicht ist er einfach nicht geeignet, in Ihrem Unternehmen zu arbeiten?

Zunächst einmal liegen Sie beide falsch. Er liegt falsch, wenn er darauf besteht, dass Code gut aussieht, und Sie liegen falsch, wenn Sie darauf bestehen, ein Anti-Pattern zu verwenden. Der angemessene Weg, Software zu entwickeln, liegt irgendwo in der Mitte Ihrer beiden Ideologien. Es ist möglich, Best Practices zu folgen und trotzdem Code zu haben, der schnell entwickelt werden kann, eine gute Leistung hat und wartbar ist, und das ist es, wo Sie beide hinkommen müssen.

Es gibt viele Möglichkeiten, dies zu tun. Ihr Entwickler scheint der Typ zu sein, der „Best Practices“ sieht und niemals vom Weg abweicht, selbst wenn sich die Best Practices ändern. Der beste Weg, dies zu beheben, besteht darin, eine bessere Best Practice zu finden, die Ihren Anforderungen entspricht, und dann müssen Sie beide sie befolgen.

Es ist wichtig, sich nicht in der Terminologie oder der genauen Methodik aufzuhalten, und das klingt, als könnte dies ein Problem für Ihren Entwickler sein. Keine bewährte Methode ist gut, wenn Sie sie nicht implementieren können oder wenn sie zu schlecht funktionierendem Code führt. Anstatt mit Ihrem Entwickler zu streiten, sollten Sie versuchen zu verstehen, warum er sich weigert, Code zu schreiben, der nicht gut aussieht, und ihn dann zu einer Vorgehensweise anstacheln, die es ihm ermöglicht, sowohl gut aussehenden Code als auch Code mit guter Leistung zu schreiben.

Falls Sie nicht glauben, dass Formatierung ein Problem ist, googeln Sie einfach den Ausdruck "Leerzeichen- oder Einrückungsprogrammierung" und staunen Sie über all das. Wie Code formatiert ist, hat viel damit zu tun, wie er auf lange Sicht wartbar ist. Sehen Sie sich auch einige dieser Bücher an, die von Jeff Atwood empfohlen werden. Sie sind alle gut und werden Ihnen helfen, besser zu verstehen, warum Sie genauso falsch liegen wie Ihr Entwickler.

Letztendlich müssen Sie aufhören, mit dem Entwickler zu konkurrieren. Sie befinden sich auf entgegengesetzten Seiten des Spektrums, und wenn Sie beide nur sagen: „Ich habe Recht“, wird es Ihnen nie besser gehen. Sie müssen versuchen zu verstehen, woher er kommt, und hoffentlich wird er die Anstrengung sehen und dann versuchen zu verstehen, woher Sie kommen. Wenn Sie versuchen, die 4-Stunden-Abfrage mit einer anderen „Best Practice“ zu optimieren, die immer noch gut aussieht, wird er es vielleicht besser verstehen.

Einige Links zu einigen Entwicklungsmethoden:

• Agiles Manifest
• Gedränge
• Schnelle Anwendungsentwicklung
• Extremes Programmieren

Es gibt viele andere. Einige werden gut sein, einige werden schlecht sein. Einige werden aus einem bestimmten Grund nicht mehr verwendet. Unsere Arbeit zahlte sich für einen Agile-Workshop aus, in dem wir Agile im Allgemeinen behandelten und eine Teilmenge dieser Prinzipien zur Implementierung auswählten. Es hat uns in vielerlei Hinsicht geholfen und uns in einigen Fällen auch behindert. Es ist viel besser als das, was wir vorher gemacht haben, aber in unserem Fall war das Problem alles prozessbezogen.

Wir haben festgestellt, dass die größte Hilfe darin bestand, sich auf das Minimum Viable Product zu konzentrieren. Das heißt, wir geben dem Kunden zunächst das kleinste bisschen Funktionalität, um seine Bedürfnisse zu erfüllen, und erweitern es bei Bedarf. Dadurch wird verhindert, dass die Software mit Dingen aufgebläht wird, nach denen der Kunde nie gefragt hat.

Ich habe noch nie eine kompetente Person in irgendeinem Bereich getroffen, die die strikte Einhaltung von Regeln und Formen über Ergebnisse und Funktion stellt. Wenn das Einhüllen in die Fahne die erste Zuflucht des Schurken ist, dann ist das Einhüllen in ein starres Regelwerk die erste Zuflucht des Inkompetenten.

Ich wäre besorgt, dass Sie mit einem "Cargo Cult"- oder "Kochbuch"-Programmierer stecken bleiben, dh einem, der sein Handwerk nicht versteht, sondern lediglich die Beispiele anderer nachahmt.

Vielleicht klammert er sich mit einer solchen Hartnäckigkeit an Muster und Formatierungen, um sich zu tarnen, dass er die Nuancen nicht wirklich versteht, wann er welche Muster und Praktiken verwenden soll. Er verwendet moralische Argumente über persönliche und berufliche Integrität, von denen er behauptet, dass er Code auf die „einzig wahre Art“ schreiben muss, um die Tatsache zu verbergen, dass er keine andere Art kennt, Code zu schreiben.

Ich denke, das ist ziemlich klar, weil alle wirklichen Aussagen zu „ Best Practices “ immer mit dem Vorbehalt kommen, „ für die folgenden Umstände oder Parameter. “ Es gibt kein universelles Set von „Best Practices“, das immer die optimale Wahl sein wird für jedes Projekt.

Insbesondere kann die Best Practice zwischen kleinen Shops wie Ihrem und großen Institutionen enorm variieren. In kleineren Shops sind primäre Anforderungen Schnelligkeit, Flexibilität, Abwicklung und vor allem Versand. Wenn du klein bist und nicht versendest, stirbst du. Dinge wie Formatierung und Stil spielen keine große Rolle, da die Leute, die den Code pflegen, wahrscheinlich auch diejenigen sein werden, die ihn geschrieben haben. Kleine Geschäfte erledigen eher schlüsselfertige Arbeiten, bei denen die Leistung von Hand optimiert wird, um einen wichtigen Mehrwert zu schaffen.

Umgekehrt sind die Hauptanforderungen in großen Institutionen, Unternehmen oder Behörden, oft die Integration in größere Projekte, kombiniert mit langfristiger Wartbarkeit durch Einzelpersonen, die den Code nicht geschrieben haben. Leistung ist oft kein so großes Problem, weil die großen Jungs oft einfach mehr Hardware auf das Problem werfen können.

Es klingt für mich so, als ob Ihr Programmierer auf "Best Practices" für die Programmierung großer Institutionen fixiert ist, anstatt auf Best Practices für die Programmierung kleiner Unternehmen. Die meisten Bücher und sogar die formale Bildung dieser Tage scheinen sich auf diesen Markt zu konzentrieren. Wenn er also tatsächlich nur das nachahmt, was er gelesen hat, versteht er möglicherweise nicht wirklich, dass sich „beste Praktiken“ mit der Umgebung ändern.

Ich denke, Sie müssen ihn testen, um genau herauszufinden, was für ein Programmierer er eigentlich ist, dh ob er ein arroganter, eselhafter Primo Uomo mit Fähigkeiten oder ein Inkompetenter ist, der sich hinter einer Perfektionismus-Fassade versteckt. Fordern Sie ihn auf, einen handoptimierten Code zu erstellen, wie Sie ihn geschrieben haben, sehen Sie nur, ob er es tatsächlich tun kann.

Wenn er über die Fähigkeiten verfügt, aber einfach Wert auf Funktion legt, dann können Sie ihm vielleicht bewusst machen, dass es so etwas wie universelle „Best Practices“ und definitiv keine universelle „beste Formatierung“ gibt.

Aber ich wette, Sie werden feststellen, dass ihm die Fähigkeiten fehlen. Er ist bestenfalls ein Kochbuch-Programmierer und kein Cowboy-Hacker, der ohne Struktur und Regeln arbeiten kann, wenn es sein muss (auch wenn er es nicht mag). Ich wette, Sie müssen ihn gehen lassen.

Wie erklärt man einem Programmierer geschäftliche Prioritäten?

Sie nicht, zumindest nicht für diesen Programmierer, der es nicht hören will. Er ist kein Manager und möchte offensichtlich nicht ermächtigt werden, Entscheidungen zu treffen oder ohne Anweisung Maßnahmen zu ergreifen, um das Geschäft zu verbessern.

Er möchte Eingaben in Form von Funktionsanfragen und Ausgabe in Form von perfektem Code bereitstellen.

Ihr Wunsch, ihn zum Entscheidungsträger auszubilden oder sich um das Geschäft zu kümmern, ist kein schlechter Wunsch, aber in diesem Fall sollten Sie diesen Wunsch beiseite legen und sich auf die geschäftlichen Prioritäten konzentrieren - diesen Programmierer produktiv zu machen.

Wenn Sie ein System haben, das nicht funktioniert, können Sie es öffnen und an den Interna basteln, oder Sie können an der Eingabe herumfummeln, bis es die richtige Ausgabe erzeugt.

In diesem Fall schlage ich vor, dass Sie mit der Eingabe an den Programmierer herumspielen, anstatt zu versuchen, den Programmierer zu ändern.

Ich habe eine wiederkehrende Meinungsverschiedenheit mit einem Programmierer über die Codequalität.

Hör auf darüber zu streiten.

Kurz und bündig:

• Lassen Sie ihn nicht das Gespräch führen und es über "Codequalität" machen.
• Sagen Sie ihm nicht, dass er es falsch macht oder Zeit verschwendet.
• Glauben Sie nicht, dass er sich unprofessionell verhält, auch wenn Ihnen klar ist, dass er es ist.
• Akzeptieren Sie seine „Das ist nicht meine Aufgabe“-Erklärung und teilen Sie ihm die ANFORDERUNGEN mit.
• Alle zukünftigen Aufgabenanfragen müssen jetzt schriftlich (E-Mail ist in Ordnung) mit anschließender Diskussion gestellt werden.
• Alle Aufgabenanfragen haben feste, objektive Grenzen für die Zeit, die er für die Aufgabe aufwenden kann, und wie leistungsfähig die Aufgabe sein muss.

Wenn Sie ihm also das nächste Mal eine Aufgabe mitteilen, tun Sie dies ähnlich wie folgt:

Beschreibung:

Wir müssen Feature X bis Freitag, den 3. Juni, implementieren, testen und bereitstellen.

Anforderungen:

• Muss einen Testfall enthalten, der außerhalb der Grenzen liegt, und einen korrekten Betrieb.
• Die Ausführung auf der Produktionsdatenbank SOME_DATABASE darf nicht länger als 180 Sekunden dauern
• Muss LINT/etc.-Tests für Unternehmenscodierungsstandards bestehen.

Finden Sie dann während des Gesprächs heraus, ob er irgendwelche Probleme mit den Anforderungen hat. Wenn ja, dann erledigen Sie die Aufgabe oder überarbeiten die Anforderungen, um sie an seine Fähigkeiten anzupassen. Nimm ihm die harte Arbeit ab und kümmere dich selbst darum – es sollte eine klare Abgrenzung zwischen deiner und seiner Arbeit geben. Wenn er versagt, versuchen Sie nicht, ihn zu „reparieren“ – finden Sie heraus, warum er Ihre Erwartungen nicht erfüllt hat, und entwerfen Sie eine Anforderung, die ihm hilft, Ihre Erwartungen für die nächste ähnliche Aufgabe zu kommunizieren.

An dieser Stelle hoffe ich, dass Sie verstehen, dass Ihr derzeitiger Versuch, ihn dazu zu bringen, sich an Ihre Bedürfnisse anzupassen, nicht funktionieren wird. Sie müssen seine Fähigkeiten verstehen und ihm dann nur die Arbeit zuweisen, zu der er fähig ist. Wenn Sie an einem Punkt angelangt sind, an dem er Ihren Bedürfnissen nicht mehr entspricht, dann entlassen Sie ihn besser – wenn die Geschäftsbeziehung zwischen seinen Vorteilen und seiner Leistung für Sie keinen Sinn mehr macht, dann trennen Sie sie und finden Sie jemand anderen, der seine Rolle erfüllt . Nicht unbedingt in dieser Reihenfolge.

An diesem Punkt würde ich normalerweise ein paar versöhnliche Geräusche darüber machen, wie die Leute in der Lage sein sollten, ihre Fähigkeiten zu ändern und ständig zu verbessern, aber im Moment müssen Sie sich nur darauf konzentrieren, Ihre eigenen Anforderungen zu verstehen und sie ihm dann klar zu kommunizieren. Sobald Sie die Kommunikation herausgefunden haben, können Sie ihm helfen, seine Fähigkeiten zu verbessern, damit er eine ORM-Abfrage schreiben kann, die rechtzeitig ausgeführt wird. Bis dahin kommuniziere, kommuniziere, kommuniziere und akzeptiere, dass es einige Aufgaben gibt, die du einfach selbst erledigen musst.

Hier geht es mehr um Code-Praktiken als um geschäftliche Prioritäten.

Ich bin ein Programmierer und ein bisschen festgefahren, aber dieser Programmierer ist vom Netz. Ich verstehe nicht, warum jemand Stil über Geschwindigkeit stellen würde. ORM sind bequem, aber nicht effizient. Es ist kein schlechter Stil, SQL zu verwenden. Es ist kein schlechter Stil, eine Datenbank aus Leistungsgründen zu denormalisieren. Vorzeitige Optimierung ist eine schlechte Code-Praxis, aber die Optimierung von Engpässen ist eine gute Code-Praxis. Ich werde jede Anfrage überprüfen, die länger als 2 Sekunden dauert.

Mein Lieblingsärgernis sind benutzerdefinierte Steuerelemente. Das Unternehmen wird nach einem ganz bestimmten Look fragen und ich werde antworten, aber die Standardsteuerung präsentiert die Informationen. Standardsteuerungen sind schnell und getestet. Bei einem Upgrade müssen wir nicht mehrere Bibliotheken koordinieren.

Warum sollte ein Programmierer ein ORM verwenden wollen, dessen Ausführung 4 Stunden dauert? Der Test würde 4 Stunden dauern. Wenn der Programmierer darum kämpfen würde, mit SQL eine 8-Sekunden-Abfrage um 4 Sekunden zu verkürzen, und das Unternehmen sagte, dass 8 Sekunden gut genug sind, wollen wir aus Gründen der Wartbarkeit ORM bleiben, dann würde ich diese Debatte bekommen.

Wie kann man den Programmierer überzeugen? Ich würde es eher ein Problem der Code-Praktiken als geschäftliche Prioritäten nennen. Ein Unternehmen muss nicht begründen, dass eine 30-Sekunden-Suche besser ist als eine 4-Stunden-Suche. Ich mache nur ORM, weil das Schreiben von rohem SQL eine schlechte Praxis ist und einfach nicht akzeptabel ist. Wenn die Sprache und die Plattform rohes SQL unterstützen, ist dies akzeptabel. Der Programmierer muss auf ein Korrekturmaßnahmenprogramm gesetzt werden, und die Personalabteilung muss einbezogen werden. Wenn Sie nicht sein Chef sind, dann gehen Sie zu seinem Chef.

Argumentieren Sie von Grundprinzipien.

Kein Klient oder Kunde kümmert sich wirklich um „Best Practices“. Aber Qualität liegt ihnen auf jeden Fall am Herzen . Vor allem möchten sie, dass ihr Problem gelöst wird, und je schneller, einfacher und billiger, desto besser. (Sie wollen auch langfristig Zeit, Geld und Mühe sparen, was einen großen Teil der „Qualität“ ausmacht.)

Ja, einige Klienten/Kunden verwenden „Best Practices“ als Proxy für Qualität, Effizienz und so weiter. Aber nur, weil ihre primären Interessen Qualität, Effizienz usw. sind.

Daher sollte jeder, der einen Service anbietet (sogar ein Programmierer, der Dienstleistungen für ein Unternehmen anbietet), seine Arbeit anhand von Fragen wie „Ist es von hoher Qualität?“, „Wird es schnell geliefert?“, „Erfüllt es das, was der Kunde will? spart es langfristig Zeit/Geld/Ressourcen?"

Das sind schwer zu beantwortende Fragen. Es ist viel einfacher, Fragen wie „Befolge ich die Programmierkonventionen?“, „Implementiere ich die Spezifikation richtig?“ und „Habe ich eine Javadoc-Beschreibung für jede Methode?“ zu beantworten. Solche Fragen sind eine einfache Möglichkeit, die schwierigen Fragen zu vermeiden. Aber ein guter Programmierer stellt die schwierigen Fragen seines/ihres Codes.

Best Practices sind wichtig. Sie helfen bei der Erstellung von Qualitätsprodukten, die auf lange Sicht Zeit/Geld/Ressourcen sparen. Sie sind besonders nützlich, wenn Sie versuchen, eine Entscheidung zu treffen, und nur wenige eindeutige Beweise dafür haben, welche Alternative die bessere ist. Aber wenn Sie klare Informationen über eine Alternative haben (z. B. würde es 10 Minuten statt 4 Stunden dauern, mit sehr geringer Wahrscheinlichkeit, dass später Probleme entstehen), dann übertrumpft der gesunde Menschenverstand die beste Vorgehensweise!

Wenn Ihr Programmierer der Meinung ist, dass ein Stück Code "schrecklich ist und niemals verwendet werden sollte", bitten Sie ihn, dies anhand von Grundprinzipien (und nicht anhand bewährter Verfahren) zu begründen. Hat es einen Fehler? Besteht das Risiko, dass es eine Sicherheitslücke enthält? Wird es wahrscheinlich viel Zeit für die Wartung oder neue Funktionen in der Zukunft benötigen? Wird es andere Programmierer verwirren? Und sind die damit verbundenen Probleme tatsächlich die Zeit wert, die für die Implementierung einer "besseren" Alternative aufgewendet wird? Achte darauf, dass du zuhörst, was er sagt. Wenn er ein starkes Argument vorbringt, lass dich nicht von deinem Ego überstimmen.

Eine Anmerkung zu Integrität und Gewohnheit

Gute Gewohnheiten sind wertvoll. Wenn Ihre Entwickler ständig üben und ihre Fähigkeit verfeinern, klaren, sauberen und gut dokumentierten Code zu schreiben, werden sie dabei effizient und sind weniger versucht, faul zu sein und Abstriche zu machen. Das ist großartig für die Qualität Ihrer Codebasis!

Ihr Programmierer hat eindeutig Integrität. Versuchen Sie nicht, es zu töten – verwenden Sie es! Geben Sie ihm Aufgaben, bei denen es auf Qualität ankommt . Bitten Sie ihn zB, unordentlichen Code zu bereinigen, der von jemand anderem geschrieben wurde und der schwer zu warten ist. Bitten Sie ihn, Funktionalität dort zu implementieren, wo es wichtig ist, dass der Code wartbar ist.

Er besteht darauf, dass sein gesamter Code nach den höchsten Standards geschrieben ist (dh dass er genauso aussieht wie die Beispiele in den Lehrbüchern für Programmierstile), unabhängig von den Auswirkungen, die dies auf die Funktionalität hat. Ich hingegen halte es für wichtiger, dass der geschriebene Code den Anforderungen des Unternehmens entspricht, dh dass er effizient arbeitet, nicht zu lange in der Entwicklung dauert und einigermaßen wartbar ist.

Dir ist klar, dass ihr beide das gleiche Ziel habt, oder?

Best Practices sind aus gutem Grund so. Sie existieren, um den Code gut organisiert und getrennt zu halten, damit er effizient funktioniert, die Entwicklung nicht zu lange dauert und einigermaßen wartbar ist.

Sicher, Ihr Entwickler könnte von einer Prise Pragmatismus oder einem besseren Verständnis dafür profitieren, wann die Regeln sicher gebogen werden können. Aber es klingt auch so, als könnten Sie von einer längerfristigen Betrachtung profitieren, wie die Qualität der Codebasis Ihre Geschäftsziele unterstützt.

Ihre Frage bezieht sich darauf, wie Sie dem Programmierer Geschäftsprioritäten erklären können, aber es hört sich so an, als hätten Sie das getan. Was Sie noch nicht getan haben, ist auf die geschäftlichen Prioritäten Ihres Programmierers zu hören . Ihr zwei werdet Kompromisse eingehen müssen. Es gibt viel mehr Lösungen für das Problem als "direktes SQL verwenden" und "ORM verwenden". Sie können versuchen, die Leistung des ORM zu verbessern. Sie können versuchen, das SQL zu isolieren, damit es für den Programmierer weniger lästig ist.

Kurz gesagt, um zu bekommen, was Sie wollen, müssen Sie aufhören zu streiten und anfangen zu kooperieren.

Um ehrlich zu sein, würde ich den Kerl disziplinieren und ihn notfalls feuern. Die hier bereits geposteten Antworten enthalten mehrere gute Punkte in Bezug auf die Flexibilität bei der Herangehensweise an Probleme, daher werde ich sie nicht erneut aufwärmen.

Es hört sich so an, als ob der Mitarbeiter, mit dem Sie Probleme haben, bereits auf oder in der Nähe der Führungsebene ist und viel vom Programmieren versteht. Das ist aber nicht alles seine Aufgabe. Wenn Sie technisch gesehen sein Manager sind, muss er Ihnen zuhören, egal ob es ihm gefällt oder nicht. Natürlich haben wir nicht beobachtet, wie Sie beide über Themen diskutieren, aber es muss ziemlich angespannt werden. Ja, es gibt mehr als einen Weg, um die meisten Probleme zu lösen, und Sie sollten beide lernen, flexibler zu sein, aber einige der Dinge, die Sie gesagt haben, deuten darauf hin, dass diese Person dem Unternehmen schadet und nicht von Vorteil ist.

Jetzt weigert er sich, an diesem Teil des Programms zu arbeiten.

Inakzeptabel und kindisch, aber auch eine Arbeitsverweigerung , was für mich ein Kündigungsgrund ist.

aber er sagt nur "Nein, ist es nicht" und schreibt weiter seinen eleganten, ineffizienten Code, den ich dann manchmal gründlich umschreiben muss, bevor er verwendet werden kann.

Hier gilt das gleiche.

Ich kann mir nur vorstellen (und hoffe), dass Sie in Ihrer Frustration ein wenig ausgeschmückt haben, und ich hoffe , dass Sie als sein "technischer" Manager in der Lage sind, sich an einem höheren Standard zu halten und nicht in kindische Meinungsverschiedenheiten mit dieser Person zu geraten. Wenn die Situation jedoch so ist, wie Sie es sagen, ist der Mitarbeiter zu einem Fehler unflexibel. Sie könnten möglicherweise etwas Aufklärung und Anleitung im Umgang mit schwierigen Menschen gebrauchen, aber am Ende des Tages weigert sich dieser Mitarbeiter rundweg, ein Produkt auf der Grundlage esoterischer Standards zu verbessern. Es gibt nur eine Möglichkeit, wie sich dies auf Ihre Kunden auswirken kann, und das ist schlecht. Egal wie gut dieser Programmierer sein mag, er wird irgendwann zu einer Belastung für das Unternehmen (vielleicht ist er es bereits).

Letztendlich setzen Sie sie ein, um ein funktionierendes Produkt zu produzieren, keinen hübschen Code. Wenn sie das nicht können, dann machen sie ihren Job nicht.

Nachdem Sie meinen Beitrag gesagt haben, versuchen Sie sich daran zu erinnern, dass es nicht schwarz und weiß ist und Sie definitiv nicht gegen sie sind, Sie haben nur unterschiedliche Vorstellungen davon, was richtig ist. Meine Kommentare hier basieren auf dem Verständnis, dass Sie versucht haben , geschäftliche Prioritäten zu erklären, und die Person scheint sich nicht darum zu kümmern, was meiner Meinung nach bedeutet, dass sie nicht gut zu Ihrem Unternehmen passt. Vielleicht würde dieser Typ auf einer Website, die Best Practices oder so etwas lehrt, gut abschneiden.

Vielleicht müssen Sie herausfinden, was er für wichtig hält. "Guter Stil" ist genau das, Stil. Es muss sich den geschäftlichen Anforderungen anpassen, und das muss er wissen. Es kann jedoch eine zugrunde liegende Angst geben, mit der er es zu tun hat und die angegangen werden muss.

Als Fallstudie arbeitete ich in einem Team, das Software konsequent langsamer produzierte, als die Kunden es benötigten. Das Management war ständig wütend auf uns. Wir hatten einen guten Grund für die Langsamkeit. Das Management hatte eine feindliche Entwicklungsumgebung eingerichtet, in der kein Stück Code ohne ausdrücklichen Befehl unseres Kunden geändert werden konnte. Leider hatten wir die ausdrückliche Anforderung, diese Software jahrzehntelang zu warten, während nur wenige unserer Kunden, wenn überhaupt, jemals mehr als einen Monat im Voraus dachten, was es unmöglich machte, sie von langfristigen ROIs zu überzeugen. Uns wurde große Verantwortung für die Software übertragen, aber wenig bis gar keine Befugnis, etwas dagegen zu unternehmen. Unser Mantra lautete: „Der erste funktionierende Prototyp, der dem Kunden gezeigt wird, wird Ihre endgültige Implementierung sein.“ Wir haben diese Straßensperre nie gelöst. Das Management hat nie mit uns zusammengearbeitet, um das Programm in einer Weise zu unterstützen, die unserer Verantwortung entspricht (uns wurde tatsächlich befohlen, nicht zu versuchen, es zu lösen, weil das bloße Aufbringen des Problems die weitere Finanzierung riskieren würde). Das Programm starb stattdessen, weil sich niemand mit dem zugrunde liegenden Geschäftsversagen befassen wollte.

Danach verbrachten wir als Entwickler viel Zeit damit, herauszufinden, was genau schief gelaufen war und was wir möglicherweise beim nächsten Mal tun könnten, um dies zu vermeiden. Einer unserer Erkenntnisse aus dieser Übung war der Wert, mehrere Möglichkeiten zu haben, um ein Problem anzugehen. Er mag einen ORM-Stil, während Sie mit ein oder zwei SQL-Befehlen Äonen an Rechenleistung sparen? Machen Sie es so, dass beide nebeneinander existieren können. Oftmals ist der Wert eines Ansatzes für die andere Seite erst lange nach seiner Fertigstellung ersichtlich. Lassen Sie zu, dass beide Stile in freier Wildbahn koexistieren, und finden Sie heraus, welcher die Strapazen des Geschäfts überlebt. Entwickeln Sie ein Gefühl der Harmonie zwischen den Ansätzen, anstatt zu versuchen, den einen Ansatz zu diktieren, um sie alle zu beherrschen. Vielleicht führt er seine gesamte primäre Entwicklung mit seinem extremen Stil durch, aber das Endprodukt erfordert das Hinzufügen von Hacks.

Wenn er das nicht akzeptiert, dann ist er eigentlich im Unrecht. Er ist nicht die Stimme des Unternehmens, er ist lediglich ein Mitarbeiter. Seine Stimme ist Teil des Ganzen und nicht das Zentrum des Ganzen (es sei denn, Sie haben ihn als Zentrum eingestellt). Ein Mitarbeiter, der sich nicht beugen kann, weil er sich an Prinzipien hält, die gegen die Bedürfnisse des Unternehmens verstoßen, muss entlassen werden. Aber umgekehrt haben Entwickler eine Sicht auf die Software, die nirgendwo anders zu finden ist. Das Unternehmen muss sich beugen, wenn der Entwickler auf ein Problem hinweist, das für andere schwer zu erkennen ist.

Das Ziel besteht darin, herauszufinden, wie die beiden Sichtweisen lange genug koexistieren können, um sie richtig zu untersuchen. Das kann jedoch irgendwann scheitern, wenn eine Seite besonders im Schlamm steckt. An diesem Punkt müssen Sie eine höfliche Diskussion führen, in der Sie erklären, dass sein Programmierstil nicht der Mittelpunkt der Welt ist, und wenn dies dem Geschäft im Wege steht, wird er Aufgaben erhalten, die ihm immer weniger Freiheit bei der Herangehensweise geben er darf mitnehmen. Alternativ steht es ihm frei, Dinge wie die „Höhe des Gehaltsschecks“ im Austausch für die Freiheit, seinen Job zu machen, zurückzunehmen.

Ich wollte keine weitere Antwort erstellen, die eine iterative Entwicklung vorschlägt, aber ich wollte sie an das Ende meiner Antwort anhängen. Die iterative Entwicklung gibt ihm die Möglichkeit, „guten Stil“ in einer Iteration zu erkunden und Sie dann die geschäftlichen Daumenschrauben anwenden zu lassen, um daraus ein nützliches Produkt zu machen. Sie wissen vielleicht nicht a priori, dass eine Aufgabe in 30 Sekunden erledigt werden kann. Nach der ersten Iteration sollten Sie jedoch ein Zeitgefühl haben. Dieses Zeitgefühl sollte es Ihnen ermöglichen, Timing-Anforderungen in der zweiten Iteration bereitzustellen.

Wenn Sie eine geschäftliche Anforderung angeben, dass eine Abfrage weniger als 5 Minuten dauern soll, und er sagt, dass dies nicht möglich ist, nehmen Sie ihm die Aufgabe höflich ab und erledigen Sie sie selbst. Lassen Sie ihn Däumchen drehen, bis er merkt, dass sein Gehaltsscheck in Gefahr ist.

Die beste Antwort, die ich zu diesem Thema gelesen habe, stammt aus der C++-FAQ.

https://isocpp.org/wiki/faq/big-picture#biz-dominates-tech

Das gefällt Ihnen vielleicht nicht, aber die kurze Antwort lautet: „Nein“. (Mit dem Vorbehalt, dass sich diese Antwort an Praktiker richtet, nicht an Theoretiker.)

Ausgereifte Softwaredesigner bewerten Situationen basierend auf geschäftlichen Kriterien (Zeit, Geld und Risiko) zusätzlich zu technischen Kriterien, wie z. B. ob etwas „gutes OO“ oder „gutes Klassendesign“ ist oder nicht. Dies ist viel schwieriger, da es um geschäftliche Aspekte geht (Zeitplan, Fähigkeiten der Mitarbeiter, herauszufinden, wohin das Unternehmen gehen möchte, damit wir wissen, wo wir Flexibilität in die Software einplanen können, Bereitschaft, die Wahrscheinlichkeit zukünftiger Änderungen zu berücksichtigen - Änderungen, die sind eher wahrscheinlich als nur theoretisch möglich usw.) zusätzlich zu technischen Fragen. Es führt jedoch zu Entscheidungen, die viel wahrscheinlicher gute Geschäftsergebnisse bringen.

Als Entwickler haben Sie gegenüber Ihrem Arbeitgeber die treuhänderische Verantwortung, nur auf eine Weise zu investieren, die eine angemessene Renditeerwartung für diese Investition hat. Wenn Sie nicht zusätzlich zu den technischen Fragen auch die geschäftlichen Fragen stellen, werden Sie Entscheidungen treffen, die zufällige und unvorhersehbare geschäftliche Konsequenzen haben.

Ob Sie es mögen oder nicht, was das in der Praxis bedeutet, ist, dass Sie wahrscheinlich besser dran sind, Begriffe wie „gutes Klassendesign“ und „gutes OO“ undefiniert zu lassen. Tatsächlich glaube ich, dass präzise, ​​rein technische Definitionen dieser Begriffe gefährlich sein können und Unternehmen Geld kosten können, und letztendlich vielleicht sogar Menschen ihren Arbeitsplatz kosten. Das klingt bizarr, aber es gibt einen wirklich guten Grund: Wenn diese Begriffe in präzisen, rein technischen Begriffen definiert werden, neigen wohlmeinende Entwickler dazu, geschäftliche Überlegungen zu ignorieren, um diese rein technischen Definitionen von „gut“ zu erfüllen.

Jede rein technische Definition von „gut“, wie „gutes OO“ oder „gutes Design“ oder irgendetwas anderes, das ohne Rücksicht auf Zeitplan, Geschäftsziele (damit wir wissen, wo wir investieren müssen), erwartete zukünftige Veränderungen, Unternehmenskultur mit bewertet werden kann in Bezug auf die Bereitschaft, in die Zukunft zu investieren, das Qualifikationsniveau des Teams, das die Wartung durchführen wird, usw., ist gefährlich. Es ist gefährlich, weil es Programmierern vorgaukelt, sie würden „richtige“ Entscheidungen treffen, obwohl sie in Wirklichkeit möglicherweise Entscheidungen treffen, die schreckliche Folgen haben. Oder diese Entscheidungen haben möglicherweise keine schrecklichen geschäftlichen Konsequenzen, aber das ist der Punkt: Wenn Sie geschäftliche Überlegungen beim Treffen von Entscheidungen ignorieren, werden die geschäftlichen Konsequenzen zufällig und etwas unvorhersehbar sein. Das ist schlecht.

Es ist eine einfache Tatsache, dass geschäftliche Probleme technische Probleme dominieren, und jede Definition von „gut“, die diese Tatsache nicht anerkennt, ist schlecht.

Betrachten Sie diese Aussage:

• Als Programmierer gehört es zu Ihrem Job, einigermaßen effizienten Code zu erstellen, genauso wie ein einigermaßen schneller Schreiber zu sein, Teil des Jobs einer Schreibkraft ist.

Zeigen Sie ihm dann ein Beispiel dafür, wie sein Code drastisch verbessert werden kann.

Wenn er diese Aussage nicht mit Ihrem Beispiel verbinden kann (oder will), müssen Sie ihn loswerden. Es ist, als hätten Sie einen Kundendienstmitarbeiter, der sich weigert, sein Telefon zu benutzen, weil er es vorzieht, Kunden E-Mails zu schreiben.

Es gibt eigentlich zwei verschiedene Fragen: Die eine ist, dass ein Softwareentwickler (verständlicherweise) Code von höchster Qualität erstellen möchte, während das Unternehmen möchte, dass er Code erstellt, der gleichzeitig so viele Funktionen wie möglich bietet.

Es muss ein Kompromiss eingegangen werden: Irgendwann bringt exzessives Polieren des Codes keinen Vorteil mehr. Auf der anderen Seite, wenn die Codequalität nicht gut genug ist, erhalten Sie Code, der falsche Ergebnisse liefert, abstürzt, zu langsam ist oder nicht gewartet werden kann.

Sie müssen Ihre Entwickler davon überzeugen, es nicht zu übertreiben, und sie müssen Sie davon überzeugen, dass die Nichteinhaltung eines begrenzten Standards manchmal kurzfristig und oft langfristig kostspielig ist. Andererseits kann es akzeptabel sein, langfristig kostspielig zu sein, wenn das Unternehmen nur durch die Lieferung in kurzer Zeit lange genug überlebt, um sich langfristig Sorgen zu machen. Wenn Sie Ihre Entwickler nicht davon überzeugen können, das Richtige zu produzierenMenge Qualität, und es kostet Sie Geld, müssen Sie möglicherweise trennen. (Wenn jemand in acht Stunden niedrige Qualität produziert und jemand anderes in acht Stunden hohe Qualität produziert und nicht dazu gebracht werden kann, in sechs Stunden niedrige Qualität zu produzieren, bevorzugen Sie natürlich immer noch den zweiten Entwickler. Oder wenn dieser Entwickler glücklich ist, wenn er hohe Qualität erstellt und produktiv, und indem Sie ihn zwingen, Qualität aufzugeben, machen Sie ihn unglücklich und unproduktiv, das ist auch nicht gut).

Die andere Frage: Anscheinend besteht Ihr Entwickler auf einem formellen Ansatz, der ineffizient ist, anstatt einen informellen Ansatz zu verwenden, der sehr effizient ist (wenn die Ineffizienz tatsächlich ein Problem für das Unternehmen darstellt). Das sehe ich als ernsthaftes Problem an. Wenn das Unternehmen ein Problem hat, das gelöst werden muss, dann ist jede Technik, die das Problem nicht löst, nicht akzeptabel, und auf einer solchen Technik zu bestehen, während man eine andere kennt, die das Problem löst, das finde ich nicht akzeptabel.

Falls erforderlich, sollte der Entwickler gerne Kommentare zum Code hinzufügen, in denen er schimpft, warum die von ihm verwendete Technik so viel schlechter ist als die andere Technik, aber aus Effizienzgründen erforderlich war. (Das könnte eigentlich eine gute Idee sein, die Gründe aufzuschreiben, falls er gefragt wird, warum er diesen Ansatz in zwei Jahren verwendet hat.) Trotzdem muss getan werden, was getan werden muss.

Dies ist ein Problem mit seiner Einstellung, und es muss sich ändern.

Seine Absichten scheinen edel genug zu sein – er versucht, Code zu implementieren, den er in der Schule gelernt hat, von dem er gelernt hat, dass er sicher und hygienisch für das Programm ist, und hält sich an Best Practices für die Codierung. Dieser Aspekt ist etwas, das Sie von einem Programmierer erwarten.

Was Sie nicht wollen, ist, dass er das Gefühl hat, dass er Entscheidungen auf höchster Ebene darüber treffen kann, wie die Anwendung funktionieren soll. Er ist, nehme ich an, ein Junior -Programmierer, und er hat noch nicht gelernt, sich an spezielle Situationen anzupassen, ganz zu schweigen von den Feinheiten Ihrer eigenen Anwendung.

Wenn sich dieser Vorfall wiederholt, schlage ich vor, dass Sie mit ihm darüber sprechen, dass Best Practices zwar gut zu befolgen, aber nicht immer die richtige Lösung sind. Erinnern Sie ihn auch daran, dass Sie sein Boss sind und dass Sie es nicht tolerieren werden, dass er Ihre Entscheidungen zurückweist oder hinter Ihrem Rücken „seinen“ Weg programmiert.

Und auf individueller Ebene sollte Ihre Gruppe sowieso eine Codeüberprüfung durchführen, bevor Sie sich festlegen – nutzen Sie also die Gelegenheit, seinen gut formatierten, aber höchst ineffizienten Code durchzugehen und Schritt für Schritt darzulegen, warum er ineffizient ist.

Wenn er sich weigert, sich zu ändern, übertragen Sie die Änderung jemand anderem oder übernehmen Sie selbst. Leider könnte dies ein Zeichen dafür sein, dass er in Gruppen absolut nicht gut funktioniert, und Sie müssen ihn möglicherweise irgendwann gehen lassen oder eine andere Gruppe finden, die mit seinem „immer strengen“ Programmierstil besser funktioniert.

In Ihrer Frage sprechen Sie nicht davon, dass der Code korrekt funktioniert . Vielleicht verbringt Ihr Programmierer zu viel Zeit damit, den Code hübsch aussehen zu lassen, aber vielleicht ist er bei seiner Fehlerprüfung gründlich. Guter Code hat einige Anforderungen:

• Es muss eine akzeptable Zeit lang funktionieren
  • Akzeptabel kann mindestens 95 % oder nie weniger als 100 % bedeuten – es ist Ihre Definition
• Es darf keine Nebeneffekte in anderen Codes/Systemen erzeugen (siehe erster Punkt)
• Es muss wartbar sein
  • Gut formatierter Code ist viel einfacher zu pflegen als schlecht formatierter Code
• Es muss fristgerecht geliefert werden (wann immer dies der Fall ist, und daran denken, dass Fristen je nach den Bedürfnissen des Unternehmens zurückgesetzt werden können).
• Es muss bezahlbar sein
• Wahrscheinlich noch viele andere Punkte

Als Manager/Vertreter des Unternehmens als Ganzes möchten Sie Code, der qualitativ hochwertig, günstig und schnell entwickelt ist. Leider hat die Erfahrung gezeigt, dass man davon immer nur zwei bekommen kann. Hochwertiger, schnell entwickelter Code ist teuer. Schnell entwickelter, billiger Code ist von geringer Qualität. Hochwertiger, billiger Code braucht lange, um entwickelt zu werden.

Einige Programmierer gehen keine Kompromisse bei der Qualität ein (ich gebe zu, dass ich einer von ihnen bin), weil eine enorme Menge an zusätzlicher Zeit erforderlich ist, um Fehler zu beheben, Fehler zu beheben und anschließend neu zu schreiben. Ich werde wissentlich nicht zulassen, dass ein neuer Fehler live geht.

Ich habe einmal an einem riesigen, schlecht geschriebenen Projekt gearbeitet. Der Code wurde von einem Drittanbieter geerbt und wir hatten wirklich gute Entwickler, die daran gearbeitet haben. Das Geschäft forderte immer wieder, es zu verbessern, und wir sagten immer wieder: "So gut geht es nicht". Wir haben den Code schließlich dazu gebracht, eine bessere Leistung zu erzielen, aber es dauerte 6 Monate bis zu einem Jahr, bis dies geschah, und wir hatten zu diesem Zeitpunkt nie eine klare Vorstellung davon, wie wir den Code schneller laufen lassen könnten. Als wir sagten „Das ist so gut wie es nur geht“ meinten wir eigentlich „Wir haben alle unsere aktuellen Ideen ausgeschöpft“.

Ihr Programmierer könnte sich in einer ähnlichen Situation befinden. Er tut buchstäblich sein Bestes und kann sich keine besseren Wege vorstellen, Dinge zu tun. Wahrscheinlich schätzt er es nicht, mit bestimmten Ideen zwangsernährt zu werden, und wird sie automatisch ablehnen. Wenn er unabhängig voneinander auf die gleiche Idee kommt, gewinnen Sie beide! Da er ein kleines Unternehmen ist, hat er wahrscheinlich nicht viel Gelegenheit, Ideen von anderen Leuten auszutauschen oder Querdenkerideen von Leuten zu erhalten, die dem Projekt nicht so nahe stehen.

Nachdem ich am Code anderer Leute gearbeitet habe, kann ich Ihnen sagen, dass ich manchmal eine halbe Stunde damit verbringen musste, den Code neu zu formatieren, bevor ich anfangen konnte, ihn zu verstehen. Das Formatieren von Code ist für die Effizienz Ihres Programmierers unerlässlich, auch wenn er möglicherweise identisch ausgeführt wird.

Versuchen Sie nicht, Ihren Programmierer davon zu überzeugen, "schlechten Code" zu akzeptieren. Erklären Sie, warum es mehrere Möglichkeiten gibt, dasselbe zu tun, und nur weil eine "guter Code" ist, werden die anderen nicht automatisch zu "schlechtem Code". Du musst ihm zeigen, dass du auf seiner Seite bist. Sie wollen auch guten Code! Aber definieren Sie dann, was guter Code ist. Wenn es wichtig ist, leistungsfähig zu sein, dann geben Sie ihm die Herausforderung, es leistungsfähig zu machen! Geben Sie das erwartete Ergebnis klar an. Beispielsweise müssen wir diese Abfrage 1000 Mal pro Stunde ausführen, was bedeutet, dass sie mindestens einmal alle 3,6 Sekunden ausgeführt werden muss (was wahrscheinlich eine schreckliche Leistung ist!).

Er wurde als technischer Experte eingestellt, nicht als Geschäftsexperte. Daher sind seine beruflichen Ziele möglicherweise nicht so, wie Sie es sich wünschen. Sie müssen erklären, wie sich das, was er tut, auf den Rest des Geschäfts auswirkt, und gleichzeitig verstehen, wie sich der Rest des Geschäfts auf seine Arbeit auswirkt. Ich würde ihm kein Leistungsmanagement empfehlen, es sei denn, Sie planen, ihn zu feuern.

Sie könnten auch die Möglichkeit eines automatischen Code-Formatierers untersuchen. Auf diese Weise konnte er sich auf das Programmieren konzentrieren und ein Makro oder ein kleines Dienstprogramm verwenden, um den Code in weniger als einer Sekunde so umzuformatieren, wie er es möchte. Beim SQL stimme ich ihm zu, dass direkt geschriebene Abfragen schlecht sind, aber zum Beispiel in PHP kann man mit PDO genau die gleichen Abfragen mit bereinigter Eingabe ausführen. Das ist gute Praxis! Es sollte einen Kompromiss geben, bei dem Sie die gewünschte Geschwindigkeit erhalten und er den "guten Code", den er möchte.

Ich würde auch vorschlagen, ihn dazu zu bringen, den Code zu profilieren, um die Engpässe zu finden und sie zu einer Priorität für die Effizienz zu machen. Wenn sein hübscher Code am Ende des Tages schnell funktioniert (und er ihn schnell schreibt), macht es Ihnen nichts aus, oder? Sie möchten, dass er Ihren Standpunkt sieht, also zeigen Sie, dass Sie seinen Standpunkt sowohl sehen als auch schätzen können. Sie müssen den Schaden reparieren, der Ihrer beruflichen Beziehung zugefügt wurde, und es ist wichtig, dass Sie sich gegenseitig vertrauen.

Das kann schwierig sein. Es hängt viel davon ab, was sein Verhalten negativ beeinflusst.

Programmleistung

Ein guter Programmierer sollte die Trennung von Schnittstelle und Implementierung verstehen. Voraussetzungen sind sozusagen die „Schnittstelle“ des Projekts und gutes Design

Ich gehe davon aus, dass Sie zumindest teilweise für die Anforderungen dieses Projekts verantwortlich sind. Sie können eine Anforderung für dieses Skript erstellen, dass es innerhalb von 6 Minuten ausgeführt wird.

Solange er die Anforderungen erfüllt, ist es dir egal, was er tut. (Dies ist die Implementierung.)

Es kann ihm helfen zu sehen, dass sein Programm aus der Sicht aller anderen (die seinen Quellcode nicht sehen können) beschissen ist .

Entwicklungszeit

Das ist etwas kniffliger. Einerseits könnten Sie die Zeit bis zur Fertigstellung eines Projekts als „Anforderung“ festlegen, aber die Schätzung der Zeit bis zur Fertigstellung eines Projekts wird (angemessen) der Person überlassen, die es erstellt.

Das hat sehr viel mit seiner Arbeitsleistung zu tun. Sie sollten es wie jedes andere Problem mit der Arbeitsleistung angehen. Dies bedeutet wahrscheinlich ein ernsthaftes Treffen, in dem Sie Ihre Bedenken hinsichtlich seiner Fähigkeit äußern, die Arbeit rechtzeitig fertigzustellen usw. Hier gibt es keine einfachen Lösungen.

Die Tatsache, dass dieser Programmierer sich weigert, an dieser Komponente zu arbeiten, ist für mich ein klares Zeichen dafür, dass dies eine Angelegenheit der Verantwortung für die Komponente ist.

Aus Sicht Ihrer Kunden ist Ihre Optimierung der richtige Weg: Die Blackbox Ihres Programms performt besser, und Ihr Unternehmen als Ganzes ist für die gesamte Box verantwortlich.

Innerhalb Ihres Unternehmens sind einzelne Personen für einzelne Komponenten verantwortlich, und wenn eine Komponente kaputt geht, liegt die Schuld beim Betreuer dieser Komponente.

Sie können diese Verantwortung nicht von der Entscheidungsbefugnis abkoppeln.

Das Aufheben der Entscheidung ist Ihr Vorrecht als Manager, aber gleichzeitig übernehmen Sie die volle Verantwortung für die Entscheidung, die einen Papierpfad umfasst, der die Einwände Ihres Programmierers dokumentiert und warum sie außer Kraft gesetzt wurden, mit einer Kopie für alle.

Ihr Programmierer sagt voraus, dass dies später negative Folgen haben wird, und versucht, seinen unteren Hintern zu bedecken.

Sagen Sie ihm, dass seine Aufgabe NICHT darin besteht, Programme an sich zu schreiben – seine Aufgabe ist es , Code zu schreiben, der dem Unternehmen Gewinn bringt.

Erinnern Sie ihn daran Damit er als Angestellter wirtschaftlich lebensfähig ist, muss der Code, den er schreibt, wirtschaftlich lebensfähig sein. Wenn er dazu nicht in der Lage ist, ist er eine kommerzielle Verbindlichkeit gegenüber dem Unternehmen und wird als solche behandelt. Sie sagen, Sie sind eine kleine Firma, also besteht die Möglichkeit, dass er die ganze Firma zu Fall bringt.

Außerdem können Sie erklären, dass er in seiner Freizeit aus Spaß und Vergnügen (oder um seine Fähigkeiten zu verbessern) Programme schreiben kann, was viele Programmierer tun. Aber Programme, die in der Zeit des Unternehmens geschrieben wurden, müssen dem Unternehmen Gewinn bringen.

Wenn er sich weigert, seinen Stil zu ändern (möglicherweise um den Code möglicherweise weniger hübsch zu machen, aber die Leistung erheblich zu verbessern), fragen Sie ihn, wie er es gerne hätte, wenn das Unternehmen ihn auf die gleiche Weise bezahlen würde: nur 10 % seines Gehalts, aber mit wirklich schönen Farben. gedruckter Scheck. Kunstwerk, handgeschrieben und handsigniert vom CEO, er kann es an die Wand hängen :-)

Ja, pragmatische Lösungen sammeln manchmal technische Schulden an – ( Wikipedia ), um einen WERT für das Geschäft zu liefern.

Die Weigerung, technische Schulden zu akzeptieren, ist dasselbe wie die Weigerung, finanzielle Schulden zu akzeptieren: Manchmal besteht eine gültige Lösung darin, Geld zu leihen, um ein Produkt zu liefern (auch wenn Sie später Schulden bezahlen müssen).

Weniger als ideal wartbarer, aber leistungsfähigerer Code ist vergleichbar mit dem Bezahlen revolvierender Kredite: Er ermöglicht es dem Unternehmen, im Geschäft zu bleiben.

Wenn es 10-mal mehr Zeit kostet, eine Lösung zu liefern, verdient er nur 10 % des Gehalts. Wenn er keinen Wert für das Geschäft liefert, sollte er durch jemanden ersetzt werden, der dies tut. (Ich bin mir sicher, dass mir das ein paar Downvotes einbringen wird, weil es direkter Trottel ist und keine warme und verschwommene Sprache - na ja, das Leben ist zu kurz. Und ja, Downvotes strömen herein. Deshalb trage ich nicht mehr zu diesem Forum bei ).