Was würden Sie Chefs sagen, die Programmierjobs für austauschbar halten?

Ich würde ihnen sagen, dass sie Recht haben. Wie werden wir dieses Ziel in der Praxis erreichen?

Grundsätzlich ist dies ein lobenswertes und erreichbares Ziel. Schauen wir uns die Besonderheiten an:

Wenn jeder einzelne Entwickler isoliert auf seiner eigenen kleinen Insel mit seinem eigenen Stil arbeitet und seine eigenen Entscheidungen unabhängig trifft, ist dies ein Rezept für eine Katastrophe. Wie lässt sich ihre Arbeit mit der anderer integrieren? Was ist, wenn sie krank oder im Urlaub sind? Was, Gott bewahre, wenn sie in einen Unfall geraten und arbeitsunfähig werden oder sogar sterben? Wenn sie die einzige Person sind, die weiß, wie ihr Code funktioniert, und ihre Kollegen viel Zeit investieren müssen, um die Arbeit dieser Person zu verstehen, gefährdet dies die Kontinuität des Unternehmens! (Dies wird manchmal als Bus-Faktor bezeichnet ) .

Gleichzeitig hat jeder Entwickler seine eigenen Fähigkeiten und Spezialisierungen. Nicht jeder wird mit allem gleich gut umgehen können und das ist in Ordnung! Deshalb arbeitet man doch als Team gemeinsam an einem gemeinsamen Ziel.

Was also tun, um eine tragfähige Situation zu erreichen?

Zunächst sollte sich das Team zusammensetzen und entweder eine Reihe von Codierungsrichtlinien auswählen, die übernommen werden sollen, oder eine eigene Reihe zusammenstellen. Dadurch wird der „Chaos“-Faktor aus dem Code eliminiert: Da jeder die Dinge auf die gleiche Weise tun wird, sollte es für andere Programmierer viel einfacher sein, zu verstehen, wie die Dinge funktionieren.

Zweitens sollte ein System eingerichtet werden, das Möglichkeiten zum Wissensaustausch bietet. Wenn erwartet wird, dass Sie Ihre gesamte Zeit mit dem Schreiben von Code verbringen, bleibt keine Zeit, Wissen zu teilen, sodass das Problem bestehen bleibt. Programmierer sollten entweder die Zeit haben, ihren Code zu dokumentieren oder ihr Wissen aktiv mit anderen zu teilen, oder idealerweise beides . Außerdem sollten Richtlinien für die Dokumentation des Codes festgelegt werden, um mögliche Probleme zu vermeiden, die sich aus einer unvollständigen oder unzureichenden Dokumentation ergeben würden. Während ein Experte eine Funktion möglicherweise mit ein paar kurzen Zeilen verstehen kann, benötigt jemand, der nicht regelmäßig mit der Funktion arbeitet, etwas mehr Informationen, um auf den neuesten Stand zu kommen. Für den zweiten Fall sollte die Dokumentation genügend Informationen liefern.

Idealerweise wird dieser Wissensaustausch durch regelmäßige Besprechungen der Arbeit der anderen unterstützt. Dies bietet dem Prüfer die Möglichkeit, sein Wissen über den Code zu erweitern, und hilft gleichzeitig Ihrem Team, die Gesamtqualität des Codes zu verbessern, da die zusätzlichen Augen helfen, mögliche Fehler zu erkennen. Es hilft dem Team auch, sein Verständnis für die Gesamtqualität des Produkts zu verbessern. Wenn viele Dinge auf „hackige“ Weise gelöst werden müssen, wird die Qualität des Produkts natürlich viel geringer sein, als wenn dieselben Probleme mit schönem, sauberem Code gelöst werden könnten.

Um die Barbier-Analogie zu stehlen, ist das Ideal, dass alle Barbiere (Codierer) in der Lage sind, die Arbeit des anderen zu beenden, weil:

• Sie verwenden alle die gleichen Frisuren

• Sie alle schneiden mit Techniken und Werkzeugen, die entweder gleich oder zumindest gleichwertig sind

• Sie dokumentieren ihren Fortschritt beim Haarschnitt anhand eines vereinbarten Systems und notieren, was sie getan haben, wie sie es getan haben und warum sie es so gemacht haben

• Sie nehmen sich regelmäßig etwas Zeit, um die Arbeit des anderen zu überprüfen und sich damit vertraut zu machen

Um die „Einstellung“ des OP zu diesem Thema anzusprechen, kann es in Wirklichkeit sehr gut sein, dass dies mit der Zeit, die die Programmierer haben (aufgrund von Fristen und Erwartungen, wie ihre Zeit verbracht wird) und der hochspezialisierten Natur der Arbeit jedes Programmierers, dies ist Ziel ist in der Praxis nicht erreichbar. Unabhängig davon ist es viel einfacher, Ihren Managern zu helfen, selbst zu sehen, warum das Ziel unerreichbar ist, als zu behaupten, dass dies der Fall ist, und es dann verteidigen zu müssen. Wenn also jemand etwas vorschlägt, bei dem Sie große Probleme sehen, versuchen Sie, mit einer konstruktiven Haltung zu antworten, z. B. "Sicher, aber wie werden wir X, Y und Z lösen?" Anstatt mit einer negativen Antwort zu antworten, z. B. "Das wird nie funktionieren, wegen X, Y und Z!". Das trägt dazu bei, dass das Management Sie positiver wahrnimmt und am Ende wahrscheinlich ein besseres und angenehmeres Arbeitsumfeld schafft.

Wenn das Erreichen von Ziel A bedeutet, viel Zeit, Mühe oder Geld in die Lösung der Probleme X, Y und Z zu investieren, ist es die Mühe vielleicht nicht wert, aber das ist eine Entscheidung, die das Management treffen sollte, also ist es unsere Aufgabe als Mitarbeiter, sie zu treffen ihnen die notwendigen Informationen, um zu einer gut informierten Entscheidung zu kommen.

Kollektives Eigentum an Code ist eine Sache innerhalb der agilen Entwicklung und wird im Allgemeinen als eine gute Sache angesehen. Aber es scheint, dass Ihr(e) Chef(s) nur eine Sache aus dem agilen Manifest genommen haben, die zu ihnen passt, und alle anderen ignoriert haben.

Damit dies funktioniert, benötigen Sie ein Team, das eng zusammenarbeitet und häufig kommuniziert. Die meisten Aufgaben sollten durch Pairprogramming gelöst werden, Code-Reviews sollten üblich und früh sein, es sollte ein hohes Maß an Tests geben, um Vertrauen in die Qualität zu schaffen, vorzugsweise entwickeln Sie mit testgetriebener Entwicklung usw.

Dass es einen gemeinsamen Code-Standard gibt, ist nicht einmal eine agile Sache, sondern einfach gesunder Menschenverstand.

Ich denke, das Problem liegt bei Ihnen und nicht bei Ihren Vorgesetzten.

Unterschiedliche Menschen haben unterschiedliche Vorgehensweisen

Damit müssen Sie sofort aufhören, Coding-Standards setzen, anfangen, mit Designs zu arbeiten und austauschbar zu werden.

Wenn einer meiner Kollegen in den Urlaub fährt, erhalten wir ein Dokument darüber, woran er arbeitet, was dieser Fortschritt ist und welche ausstehenden Probleme es gibt und was am wichtigsten ist, wo sich die Dokumentation befindet.

Ich denke, der Kern des Problems besteht darin, dass Sie anfangen sollten, mehr als Team zu arbeiten.

Und wenn Sie es als Kollegen nicht schaffen, ist es die Aufgabe des Managements, dafür zu sorgen, sie werden dafür bezahlt.

Kollektives Eigentum an Code, bei dem jeder Programmierer an jedem Teil der Software gleich gut arbeiten kann, ist ein Ideal , das angestrebt werden sollte (weil die Vorteile real sind), aber harte Arbeit erfordert, um es zu erreichen.

Das Team muss einen Programmierstil durchsetzen, damit der Code für alle sofort erkennbar ist. Das Team muss strenge Code-Reviews durchführen, damit das Wissen über einen Teil des Codes geteilt wird, sobald er geschrieben ist, und der gemeinsame Qualitätsstandard sichergestellt ist. Sie müssen eine „Definition of Done“ verwenden, die sicherstellt, dass nichts als „Done“ bezeichnet wird, bis es dokumentiert, getestet und überprüft wurde. Neue Teammitglieder brauchen Zeit und Training, um sich mit allen verwendeten Technologien vertraut zu machen.

Wenn die Manager die Ergebnisse eines solchen Prozesses verlangen, ohne vorher in dessen Umsetzung zu investieren, handeln sie unrealistisch.

Ich denke, Sie sollten mit Ihren Kollegen besprechen, welche Art von Änderungen Sie an Ihrem Workflow vornehmen möchten, um dies besser zu ermöglichen, wie z. B. mit Code-Reviews oder Pair-Programming zu beginnen oder sich auf einen gemeinsamen Codierungsstil zu einigen.

Gehen Sie dann zu Ihren Vorgesetzten und sagen Sie so etwas wie

Ich weiß, Sie möchten, dass alle Programmierer austauschbar sind, damit wir alle an allen auftretenden Problemen arbeiten können. Allerdings sind wir noch nicht so weit – wir alle kennen uns eigentlich nur mit einem Teil der Codebasis aus, und es ist schwierig, sich an die Arbeitsweise anderer anzupassen. Wir halten es jedoch für eine gute Idee und schlagen vor, X und Y zu implementieren, um auf dieses Ziel hinzuarbeiten.

Mir scheint, dass die Entwickler und die Manager auf dem Spektrum von individueller Code-Ownership bis hin zu gemeinsamer Verantwortung extreme Gegensätze eingenommen haben.

Die Entwickler könnten mehr tun, um sich dem Ideal der Manager anzunähern:

• Codierungsstandards. Es sollte kein Chaos sein, weil verschiedene Menschen unterschiedliche Vorgehensweisen haben.
• Ziehen Sie Paarprogrammierung in Betracht. Auf diese Weise verstehen mindestens zwei Personen jede Änderung.
• Gewöhnen Sie sich an, nach Ursachen zu suchen und nicht Patches auf Patches anzuwenden. Ich denke, die meisten erfahrenen Programmierer mussten Fehler in Code aufspüren, den sie nicht geschrieben haben. Es braucht Zeit und Mühe, es richtig zu machen.
• Dokumentieren, überprüfen, dokumentieren, überprüfen.... Das Design, an dem die Person einen Monat lang gearbeitet hatte, sollte von mehreren Personen geschrieben und verstanden worden sein.

Sie werden vielleicht nicht ganz die extreme Flexibilität erreichen können, die Manager wünschen, aber Sie sollten in der Lage sein, weit darüber hinauszugehen, dass es nur eine Person gibt, die an jedem Codestück arbeiten kann. Vielleicht müssen Sie ihnen manchmal sagen, „Joe oder Nancy könnten das schneller machen“, und sie entscheiden lassen, ob sie die Kosten für die Abholung durch jemand anderen übernehmen.

Kurze Antwort: Weisen Sie darauf hin, wie lächerlich es ist.

Ich bin tatsächlich schon einmal darauf gestoßen und habe einfach so etwas gesagt wie:

Würden Sie zu einem Podologen gehen, wenn Sie eine Gehirnoperation benötigen? Sie sind beide Ärzte, oder?!

Oder

Gehst du zum Schneider, um dir die Haare schneiden zu lassen, weil Schneider wie Friseure Scheren benutzen?

Weisen Sie dann darauf hin, dass mit jeder Spezialisierung sehr unterschiedliche Fähigkeiten verbunden sind. Sagen Sie ihnen, dass die Programmierung dasselbe ist. Einige Entwickler sind in einem Bereich hochqualifiziert, in einem anderen jedoch völlig ahnungslos.

Das heißt nicht, dass Sie die anderen Fähigkeiten nicht erlernen könnten, aber es würde Zeit und die Bereitschaft erfordern, es zu wollen.

Sie schrieben,

Niemand besitzt etwas, und niemand ist für irgendetwas verantwortlich. Oder anders gesagt: Jeder besitzt alles und jeder ist für alles verantwortlich

Das sind zwei Extreme (vielleicht sollten Sie nach einem Mittelweg zwischen den beiden Extremen suchen) und eine falsche Dichotomie.

Ist das für Softwareunternehmen üblich?

Je nach Anzahl der Programmierer gibt es verschiedene Möglichkeiten.

Eine besteht darin, jeder Komponente ein Team (aus mehreren) zuzuweisen. Erwarten Sie, dass jeder im Team (falls erforderlich) für (alles innerhalb) der gesamten Komponente verantwortlich ist. Ein Team kann einen einzigen Chefentwickler oder Teamleiter haben oder nicht, der auch der offizielle Kontaktpunkt des Teams zur Außenwelt (Management und QA) sein kann oder nicht.

Ein Minimum, das ich empfehle, sind Code-Reviews. Jede Person ist für ihre eigene Entwicklung verantwortlich und braucht Tage, um ein neues Feature zu programmieren, und dann verbringen eine oder mehrere andere Personen Stunden damit, zu überprüfen, was fertiggestellt und getestet und eingecheckt wurde. Der/die Code-Reviewer kann Änderungen vorschlagen und kann vernünftigerweise (vom Management) erwartet werden, dass sie verstanden haben, was sie überprüft haben. Zum Beispiel könnte ein Bewertungskommentar (bevor sie die Änderung akzeptieren oder „abmelden“) lauten: „Ich verstehe das nicht, Sie sollten es besser ein wenig überarbeiten und/oder besser erklären“ oder „Was bedeutet das? tun, was ist die Funktion (z. B. sichtbar in der funktionalen Spezifikation), die es implementiert, wo ist der automatisierte funktionale Regressionstest, der dies testet").

Nachdem (falls) sie eine Änderung absegnen, ist es vernünftig, dass ein Manager vorbeikommt und sagt: „Sehen Sie, Bob ist im Urlaub und/oder hat das Unternehmen verlassen; wir glauben, dass es ein Problem mit diesem Modul gibt, das Sie überprüft haben, und/oder wir möchte ein neues Feature hinzufügen. Könnten Sie sich das ansehen? Sie kennen es bereits (ganz zu schweigen davon, dass Sie dafür verantwortlich sind), da Sie Code-Reviews durchgeführt haben, als es implementiert wurde.

Codeüberprüfungen haben viele Zwecke, einschließlich:

• Cross-Training, was Komponenten tun und wie sie implementiert werden
• Gewährleistung gemeinsamer/konsistenter Standards (der Kodierung, Dokumentation und/oder Prüfung)
• Qualitätskontrolle (d. h. „White-Box“-Tests, Suche nach potenziellen Fehlern)

Einmal hatte sich ein Typ mehr als einen Monat lang auf ein neues Modul vorbereitet, nahm dann Urlaub und kurz bevor er ging, sagte er unserem Chef, dass alle Probleme gelöst seien und es bereit sei, mit dem Programmieren zu beginnen. Also am nächsten Tag Scrum, sagte mein Chef zu mir, wir müssen das nächste Woche erledigen, kannst du es bitte abholen?

Da haben Sie einen Manager, der sein Gehirn fallen gelassen hat.

Ja, für jeden Entwickler sollte es mindestens einen anderen geben, mit dem er bei jeder einzelnen Aufgabe (einschließlich des Ausarbeitens des Designs für ein neues Modul) eng zusammenarbeitet (Pair-Programming und dergleichen), der daher in der Lage sein sollte, ohne unangemessenes Recht zu übernehmen jederzeit nacharbeiten.

Aber das ist nicht dasselbe wie zu sagen, dass es keinen Overhead gibt, mitten im Flug zu wechseln:
Es sollte ungefähr der gleiche Overhead sein, oder idealerweise etwas weniger, als ob der ursprüngliche Entwickler diese Aufgabe fallen gelassen hätte, ohne lose Enden zu binden, um einen Notfall zu bewältigen, und dann musste nach einer Woche Arbeit an etwas anderem wieder hochfahren.

Wenn Sie nicht derjenige sind, mit dem er an dieser Aufgabe gearbeitet hat, haben Sie nur seine Notizen, und so gut sie auch sind (was wahrscheinlich nicht herausragend ist oder wenn Sie Ihre Beschreibung eher als sehr lückenhaft bis nicht existent betrachten), sie sind einfach kann nicht alle Details umfassen, die Ihr Kollege in diesem Monat ausgearbeitet hat.

Es ist, als würde man ins Krankenhaus gehen und sich die Zeit nehmen, dass ein Arzt Ihren Zustand über einen Monat lang mit wiederholten Untersuchungen, Blutproben, EKG, Röntgenaufnahmen und allem, was sonst nützlich erscheint, sorgfältig beurteilt und dann sofort zum Chirurgen geht, um Sie zu behandeln, niemals Lassen Sie die beiden etwas Nützliches kommunizieren.

Wenn Sie nicht derjenige sind, mit dem er zusammengearbeitet hat, sollten Sie darauf hinweisen, welcher Kollege es getan hat, und warnen Sie auch, dass , obwohl es ihm viel leichter fallen würde, zu übernehmen als Sie, es immer noch erhebliche Kosten gibt, da er es war. nicht derjenige, der die Zubereitung selbst durchführt .

Wenn sonst niemand mit diesem Präparat vertraut ist, sollten Sie erwähnen, dass es hätte geben müssen und (je nachdem, wie die Forschung dokumentiert wurde), dass Sie möglicherweise zwischen x% (Ihre beste Schätzung hinsichtlich der Dokumentation und was Sie gehört haben) bis hin zur vollen Zeit, bei Null anzufangen.

Am Ende scheint es ein Managementfehler zu sein:
Der Teamleiter muss sich mit den anderen Entwicklern zusammensetzen und einen Codierungsstandard erarbeiten, sowie anfangen, tatsächlich Pair-Programming, Unit-Tests und Code-Reviews durchzuführen und alle anderen Aktivitäten zur Qualitätssicherung und Wissensverbreitung im Team.

Ist es üblich? Nicht sehr viel. Aber es kann so eingerichtet werden, dass es funktioniert.

Die Idee dahinter ist, Menschen als Single Points of Failure zu vermeiden . Natürlich ist es mit Kosten verbunden, und die Programmierer tragen die Kosten. Deshalb wird es schwierig sein, Ihren Chef davon zu überzeugen, dass es eine schlechte Idee ist. Er hat alle Vorteile und du alle Nachteile. Trotzdem macht es Sinn.

Es ist sinnvoll, Zeit mit anderen Programmierern zu verbringen, um Wissen und Praxis auszutauschen. Dies kann durch Überprüfungen, Paarprogrammierung oder alles andere geschehen, was für Sie funktioniert. Ich war in einem 22-köpfigen Team, in dem ein Berater (seit Jahren dort) die meiste Zeit damit verbrachte, in den Korridoren herumzulaufen, anstatt zu programmieren. Er war der Kitt des Teams, und mindestens 15 Leute im Team konnten an den Programmen arbeiten, die ich machte. Es kann alles andere sein, was dem Bedarf entspricht, informelle Gespräche, Wissensaustausch an der Kaffeemaschine.....

Aber es hat seinen Preis. Lohnt sich IMHO zu zahlen, aber wenn alle an der gleichen Technik arbeiten, soll es nicht zu teuer werden. Die Kosten sind ein hoher Kommunikationsaufwand. Das sollten Sie eher Ihrem Chef mitteilen, da seine Idee an sich nicht schlecht ist. Er muss nur verstehen, dass es sich um eine Investition mit nicht unmittelbaren Belohnungen handelt.

Die Begründung dafür ist, dass, wenn jeder für alles zuständig ist, wenn jemand Urlaub nimmt, andere einfach einspringen können/sollten und ihn/sie decken, damit er/sie jederzeit Urlaub machen kann/sollte.

Ich kenne ein Unternehmen ( Menlo Innovations ), das „jeden“ nach einem festgelegten Zeitplan um „jedes“ Projekt rotieren lässt. Es gibt einen Weg, damit es funktioniert.

Das Management hat sich dies als Ziel gesetzt, hat sich jedoch vollständig der Verantwortung entzogen, das Notwendige zu tun, damit es funktioniert. Es müssen mehr Leute eingestellt werden, zusammen mit längeren Lieferzeiten. Sie können dies rechtfertigen, indem sie langfristige Ergebnisse demonstrieren und nicht von einem Guru als Geisel gehalten werden, der glaubt, er sei die einzige Person auf dem Planeten, die in der Lage ist, sein spezielles Projekt zu programmieren.

Das eigentliche Problem dabei ist, zu versuchen, eine Praxis isoliert zu implementieren. Sie sollten komplementäre Praktiken wie Teamentwicklung, Tests, umfangreichere Dokumentation, tägliche Meetings zum Teilen und um alle auf dem Laufenden zu halten, was andere tun, in Erwägung ziehen.

Ich denke, das Folgende ist ein ausgewogener Abschluss, leider hört es jemand einfach nicht gerne. Ich habe wiederholt Aufforderungen erhalten, sie zu entfernen. In einer demokratischen Welt verdient jede Stimme gehört zu werden. Das hört man nicht gerne, aber mich zum Schweigen zu bringen ist eine andere Sache, die meiner Meinung nach nicht sehr gut ist. Also hier ist es wieder, mein Fazit, getötet von meiner OP.

Fazit

Ich denke, es ist an der Zeit, dass wir die Diskussion beenden und jetzt weitermachen. Nach sorgfältiger Prüfung habe ich die eine "konstruktive Antwort, die eine konstruktive Lösung vorschlägt" als Antwort ausgewählt. Aber tatsächlich sind alle Antworten sehr gut, ich wünschte, ich könnte mehr als eine als Antwort auswählen.

Aus den Antworten wurde mir klar, dass es sich um ein ziemlich kontroverses Thema handelt, das mir die Augen öffnet, weil ich vorher dachte, meine Chefs seien ahnungslos. Jetzt merke ich, dass ich vorher ahnungslos war.

Wie Patricia Shanahan sagte, „haben die Entwickler und die Manager extreme gegensätzliche Positionen auf dem Spektrum von individuellem Codebesitz bis hin zu gemeinsamer Verantwortung eingenommen“ , und ich kann deutlich sagen, welche Antworten/Kommentare von Managern stammen:

• "Ein Manager sollte immer in der Lage sein, jemanden zu bitten, einen Entwickler im Urlaub abzuholen"
• „Ich denke, der Kern des Problems ist, dass Sie anfangen sollten, mehr als Team zu arbeiten.“
• "Was Sie tun müssen, ist, Ihren Vorgesetzten nicht einzubeziehen"
• "Das Team muss einen Weg finden, dieses Wissen zu teilen, indem es Code-Reviews, Design-Reviews, Pair-Programming und allgemein - miteinander spricht"

Bevor Sie eine solche Schlussfolgerung ziehen, bedenken Sie bitte noch einmal die folgende Tatsache, dass dieser Typ es mehr als einen Monat lang vorbereitet hat, aber seine Erkenntnisse nie mit jemand anderem geteilt hat, und jetzt möchte mein PM, dass ich es ohne Vorkenntnisse aufnehme und fertigstelle innerhalb einer Woche . Und außerdem, dass wir für die Urlaubsantragstellung mindestens einen Monat brauchen, häufiger aber zwei oder drei Monate vor dem Urlaub. Daraus, glaube ich, würde jeder wissen, wo eigentlich das Problem liegt. Ich stimme TripeHound vollkommen zu,

Wahrscheinlich wichtiger als "Das Team muss ..." ist "Das Management muss dem Team erlauben ..." und zu akzeptieren, dass die Produktivität währenddessen erheblich beeinträchtigt wird.

Geben Sie es zu oder nicht, gazzz0x2z hat auf das eigentliche Problem hingewiesen: „Es ist mit Kosten verbunden, und die Programmierer zahlen die Kosten. Deshalb wird Ihr Chef schwer davon zu überzeugen sein, dass es eine schlechte Idee ist. Er hat alle Vorteile, und Sie alle Nachteile" , und ich persönlich stimme RemcoGerlich zu: "Wenn die Manager die Ergebnisse eines solchen Prozesses verlangen, ohne vorher in dessen Umsetzung zu investieren, sind sie unrealistisch" , denn schließlich, wie kein Komprende formuliert, "es braucht Zeit selbst den eigenen Code wieder verstehen, nachdem man ihn eine Weile nicht gesehen hat, also würde es sicherlich einige Zeit dauern, den eines anderen zu verstehen.Es gibt eine praktische Grenze für das Teilen der Verantwortung für Code" ,"Es wäre gut, wenn das gesamte Managementteam auch Jobs tauschen könnte" .

Ok, ich weiß, ich habe es zu weit getrieben, und die meisten Manager hier stimmen mir vielleicht nicht zu. Lassen Sie mich betonen, dass dies meine eigenen persönlichen Ansichten sind, und lassen Sie uns die Diskussion beenden und weitermachen. Das ist auch der Hauptgrund, warum ich die eine „konstruktive Antwort, die eine konstruktive Lösung vorschlägt“ als Antwort ausgewählt habe – Manager und Entwickler müssen einander besser verstehen, und meistens sind es die Manager, die die Entwickler besser verstehen müssen. Mit diesem Verständnis und der konstruktiven Lösung werden wir da sein, aber es wird nicht über Nacht passieren.

Ich bin in dieser Softwarefirma, und komischerweise habe ich bisher nur zwei Manager erlebt, aber diese beiden Manager sehen Programmierjobs nicht viel anders als Ziegelsteine ​​zu legen. Sie haben immer betont, ihr sollt jederzeit die Jobs des anderen übernehmen.

Das ist eine durch und durch lächerliche Vorstellung. Programmieren ist ein hochspezialisiertes Gebiet und verschiedene Aspekte des Programmierens erfordern sehr unterschiedliche Fähigkeiten. Das Beste, was Sie tun können, ist, sie darauf hinzuweisen. Während Analogien zu anderen Berufen treffend und passend sein können (Schneider, Haare schneiden usw.), glauben Ihre Chefs ihnen vielleicht nicht, also weisen Sie auf einige der massiven Unterschiede in der Programmierung hin, wie zum Beispiel, wie unterschiedlich das UI-Design von Leistungstests ist.

Aber ja, Sie sollten auf jeden Fall versuchen, diese Vorstellung von Ihren Managern zu zerstreuen, damit sie nicht ein sehr hartes Erwachen erleben, wenn sie herausfinden, wie falsch sie liegen.

Sie können Programmierkonventionen, Tools, Ordner und Vorgehensweisen standardisieren. Aber Sie können es nicht mit dem Wissen über einige intrinsische Funktionen und die Funktionsweise einiger Codeteile gleichsetzen. Das gehört nur denen, die Stunden damit verbringen, darüber nachzudenken. Erklären Sie Ihren Chefs, dass es überhaupt keine Ziegelsteine ​​sind, ich musste mit so ignoranten Chefs umgehen, sie kommen aus der Baubranche und versuchen, die gleichen Standards in der Softwareindustrie anzuwenden, ich kann Ihnen nicht erklären, dass dies zu großen Katastrophen führt, gescheiterte Projekte und hohe Fluktuation wirklich guter Entwickler. Erkläre ihnen das. Jedes Stück hat seine eigene Arbeitsweise und ist spezifisch für die geschäftlichen Anforderungen. Zum Beispiel haben Sie einen "Ziegel", der einige Plus-Operationen ausführen kann, eine andere Minus- und Divisionsoperation, Eines Tages fragt ein Typ nach einem Ableitungs- oder Matrixfunktionskalkül. Kannst du einen solchen "Baustein" mit dem vorherigen vergleichen? Der Typ, der den neuen Matrizenkalkül programmiert hat, hat Zeit, sein Wissen zu teilen und gleichzeitig Zeit im Zeitplan zu bleiben? Ich glaube nicht.