Welche Faktoren sollten beeinflussen, wie ich feststelle, wann ich ein kleines Projekt mit einem Freund aufgeben soll? [geschlossen]

Ich habe mich in letzter Zeit in einer schwierigen Situation befunden. Ich arbeite jetzt seit fast 8 Monaten an einem Spiel mit einem Programmierfreund. Wir haben beide im August letzten Jahres als Anfänger in der Programmierung angefangen. Er ist ein CS-Student im zweiten Jahr, ich bin ein IT-Supporttechniker und ein Autodidakt mit einer Vielzahl von Büchern und Online-Abonnements.

Das Problem, das ich immer wieder gesehen habe, ist, dass wir beim Schreiben eines Codeblocks oft ein bisschen zusammen hacken, viele Fehler haben und wenn es für einen von uns ein brandneues Konzept ist, voller naiver Lösungen. Das ist in Ordnung, wir lernen, ich gehe davon aus, dass unser Code beim ersten oder zweiten Durchgang ein bisschen zusammen gehackt wird. Das Problem stellt sich, wenn es darum geht, diese gehackten Verhaltensweisen tatsächlich zu beheben und umzugestalten.

Mein Partner wird an seinem frisch gepflasterten Verhalten festhalten und sich krampfhaft weigern, irgendeinen Fehler zu sehen, sobald er anfängt zu funktionieren. Ich kann nicht einmal versuchen, eine Struktur zu verwenden, die nahezu perfekt ist, selbst wenn sie Kommentare und entsprechend benannte Methoden und Felder enthält. Egal wie sehr ich mich bemühe, ich kann ihn einfach nicht dazu bringen, die augenscheinlichen Mängel zu erkennen, die weitere Änderungen oder Erweiterungen des Verhaltens verhindern, ohne es vollständig zu brechen, und alles, was so eng damit verbunden ist, könnte genauso gut in derselben Klasse sein. Gehackte Lösungen bleiben immer gehackt, schlecht durchdachte Designs bleiben so, wie sie waren, als sie zuerst konzipiert und getestet wurden.

Ich verbringe so viel Zeit damit, neuen Code zu babysitten, wie ich es selbst schreibe. Ich verliere, was zu tun ist. Mein Partner hat es heute Abend verloren und klargestellt, dass sein Code so bleiben wird, wie er es zuerst gemacht hat, egal was, egal wie der Benchmark, egal wie die gängige Praxis, egal wie der unwiderlegbare Beweis. Selbst wenn ganze Bücher darüber geschrieben wurden, warum Sie etwas vermeiden wollen, wird er es ablehnen, ihre Gültigkeit anzuerkennen, da dies nur eine Meinung ist.

Ich habe ein berechtigtes Interesse an unserem Projekt, bin mir jedoch nicht sicher, ob ich mit meinem Partner weiterarbeiten kann. Mir stehen drei Möglichkeiten offen.

• Hören Sie auf, sich um die Codebasis zu kümmern, die nach dem Kompilieren noch funktioniert, und versuchen Sie lediglich, ein Verhalten beizubehalten und zu analysieren, das kaum nachlässt. In der Hoffnung, dass, sobald die Dinge ernsthaft zu brechen beginnen, er das sieht und versucht, mehr zu tun, als nur ein Pflaster über das grundlegend fehlerhafte Design zu legen.
• Halten Sie die endlosen Auseinandersetzungen über Themen aufrecht, die vor einem Jahrzehnt von anderen viel fähigeren Personen herausgefunden wurden.
• Stoppen Sie die Programmierung für dieses Projekt, indem Sie fast 10.000 Zeilen meines Codes und unzählige Arbeitsstunden für das Design aufgeben, und versuchen Sie, selbst ein neues Projekt zu finden.

Wie kann ich feststellen, ob es sich lohnt, dieses Projekt mit dieser Person fortzusetzen? Oder welche Faktoren sollten meine Entscheidung beeinflussen? Wir haben viel Code geschrieben und ich möchte nicht darauf verzichten, es sei denn, dies ist notwendig.

Unvollständiger Code ist im Versand besser als perfekter Code auf dem Whiteboard, der nie ausgeliefert wird.

Davon abgesehen ...

Diejenigen von Ihnen mit mehr Erfahrung oder die in ähnlichen Situationen waren. Was haben Sie gemacht? Was würdest du mir empfehlen?

Ich würde folgendes berücksichtigen.

• Was ist der Zweck dieses Projekts? Spaß? Geld? Lernen?
  • Erreichen Sie diesen Zweck tatsächlich?
• Ermöglicht Ihnen diese Person tatsächlich, Ihre Ziele besser zu erreichen?
• Wie nah sind Sie dem Versand tatsächlich?
• Verhindern diese Probleme, dass Sie gestartet werden? Oder sind sie eine Frage des persönlichen Stolzes?
• Hat es Vorteile, freiwillig mit jemandem zusammenzuarbeiten, wenn es frustrierend ist?

Stoppen Sie die Programmierung für dieses Projekt, indem Sie fast 10.000 Zeilen meines Codes und unzählige Arbeitsstunden für das Design aufgeben, und versuchen Sie, selbst ein neues Projekt zu finden

Denken Sie über das oben Gesagte nach und überlegen Sie, welche zusätzlichen Arbeiten erforderlich sind.

Sie müssen Ihre Prioritäten herausfinden und feststellen, ob sich die Probleme im Zusammenhang mit der Arbeit mit dieser Person lohnen. Wir können das nicht für Sie herausfinden.

Mein Partner hat es heute Abend verloren und klargestellt, dass sein Code so bleiben wird, wie er es zuerst gemacht hat, egal was, egal wie der Benchmark, egal wie die gängige Praxis, egal wie der unwiderlegbare Beweis.

Sie wissen, dass Sie nicht mit dieser Art von Person arbeiten möchten.

Sie machen ein solches Projekt vermutlich, weil Sie Programmieren lernen und Eleganz im Handwerk selbst finden wollen.

Dies kann eine kulturelle Sache sein. In einigen Kulturen ist das Eingestehen, dass Sie einen Fehler begangen haben, unbekannt, und die Aufforderung, zuzugeben, dass Sie einen Fehler begangen haben, ist das Unhöflichste, was Sie tun können. Wenn es so ist, lauf weg.

Nach meiner Erfahrung mit sehr klugen Leuten werden sie, wenn Sie ihnen sagen, dass etwas, das sie tun, weniger als perfekt ist, entweder (1) einen korrekten und leicht verständlichen Grund angeben, warum das, was sie tun, tatsächlich richtig ist, (2) sagen Sie, dass sie wissen, dass es falsch ist, aber sie haben keine Zeit, es aufgrund von Prioritäten zu beheben, oder (3) danke, dass Sie darauf hingewiesen und es behoben haben.

Wenn man sich weigert zu lernen, handelt es sich um das schlimmste Attribut, das ein Softwareentwickler haben könnte. Lass ihn dran. Das Leben ist zu kurz und zu kostbar, um deine Zeit für ihn zu verschwenden.

Möglicherweise ist es am einfachsten, jemanden in das Projekt einzubeziehen - entweder irren Sie sich und seine Codebasis ist einfach zu clever für Sie, oder Sie haben Recht und es ist zu clever für alle. Sie werden es bald herausfinden und erhalten ein Backup, wenn sich herausstellt, dass es sich um unsauberen, verschlungenen Code für Junior-Programmierer handelt.

Auf der anderen Seite ist ein funktionierendes Produkt eine Reihe von Jahren fein abgestimmten, eleganten und klaren Codes wert. Machen Sie das Spiel, versenden Sie es, gehen Sie dann weg - lassen Sie ihn es warten und arbeiten Sie nicht an v2.

Hier sind einige Ideen, auch wenn sich einige gegenseitig ausschließen.

• Getrennte Quellenverantwortung. Wenn Sie an Modul A und an Modul B arbeiten, können Sie mit Ihren verschiedenen Stilen konkurrieren. Gibt er häufig Arbeitsfeatures frei? Kommt er an einen Punkt, an dem er seinen Code von Grund auf neu schreiben muss? Refactor den Code aus Ihren Modulen und berühren Sie ihn nicht,

• Lassen Sie ihn seinen schlechtesten Code warten. Wenn er es erfolgreich macht, haben Sie eine schreckliche Aufgabe vermieden. Wenn er nicht in der Lage ist, wird er den Schmerz fühlen.

• Betrachten Sie es aus Benutzer- oder Geschäftssicht. In einigen Fällen benötigen Sie nur ein funktionsfähiges Produkt, das Google oder Microsoft möglicherweise kaufen. In anderen Fällen bringen Sie ein Produkt auf den Markt und unterstützen Tausende von Kunden mit fehlerhaftem oder gehacktem Code. Ist nicht dasselbe, wenn dein Code Drohnen mit Atomraketen kontrolliert oder glückliche Videos für Teenager macht.

• Er macht den Unterricht, Sie machen die Tests. Das Refactoring von Code mit Tests ist einfacher und sicherer. Auf diese Weise müssen Sie nicht nur in der Junit-Leiste nachsehen. Dies setzt voraus, dass A) Sie Tests programmieren, B) Ihr Kollegencode testbar ist. Wenn Sie Schwierigkeiten haben, die Tests während der Codierungsphase zu erstellen, ist diese schlechter.

• Gehen Sie gemeinsam zu Schulungen oder Veranstaltungen. Wenn Sie den richtigen Weg nicht kennen, können Sie ihn natürlich nur so verwenden, wie Sie es kennen. Den Code eines anderen zu sehen, löst möglicherweise nicht alles, schadet aber nicht, es zu versuchen.

• Finden Sie Ihre komplementären Stärken. Refactoring kann manchmal Spaß machen. Wenn er Dinge schreibt, die zumindest funktionieren, können Sie das Refactoring durchführen. Er kann mit Spikes nach Lösungen suchen, die nicht im Seriencode enden.

• Möglicherweise möchte er den Code nicht umschreiben, stimmt jedoch möglicherweise zu, den neuen Code besser zu schreiben. Ich verstehe, dass das Umschreiben schwierig und langweilig ist und Probleme verursachen kann. Bauen Sie einige Qualitätsinseln an. Auf diese Weise wird er gute Beispiele dafür haben, wie man Dinge macht.

• Verwenden Sie die Pfadfinderregel . Lassen Sie die Dinge unberührt, es sei denn, Sie müssen daran arbeiten. Wenn ein Modul schlecht geschrieben ist, aber funktioniert und nicht geändert werden muss, lassen Sie es so. Wenn Sie einen Fehler beheben oder ein Feature vervollständigen müssen, verbessern Sie es ein wenig. Nach einiger Zeit verbessern sich die 20% der Klassen, die Sie in 80% der Fälle wechseln. Mehr Qualitätsinseln.

Wir können nicht vorschlagen, was die beste Lösung ist, ohne Sie beide zu kennen. Viel Glück.

Ok, hier ist eine Antwort, die dir wahrscheinlich nicht gefallen wird.

Korrigieren Sie den Code nur, wenn die Implementierung der Funktion fehlschlägt.

Hier ist meine Argumentation. Sie versuchen vermutlich, Geld zu verdienen. Um Geld zu verdienen, müssen Sie abgeschlossene Funktionen schnell versenden. Niemand wird Sie mehr für ein gut codiertes Computerspiel bezahlen.

Die meisten Unternehmen haben das gleiche Problem. Korrigieren Sie vorhandenen Code, um ihn zu verbessern, manchmal sogar objektiv in Bezug auf Geschwindigkeit oder Zuverlässigkeit, ODER schreiben Sie neue Funktionen.

99% der Zeit entscheiden sie sich, die neuen Funktionen zu schreiben, weil das Ergebnis einer einfachen Kosten-Nutzen-Analyse ist.

Ich mag alle Antworten bis jetzt. Nehmen Sie einen der Punkte aus der Antwort von Enderland :

Hat es Vorteile, freiwillig mit jemandem zusammenzuarbeiten, wenn es frustrierend ist?

Ich möchte diese Zeit in Anspruch nehmen, um für den Austausch des Code-Überprüfungsstapels zu sorgen . Es ist ein wunderbarer Ort, an dem Sie Ihren Code von Profis kritisieren lassen können. Und ehrlich gesagt, sind viele der dortigen Code-Reviews für die Beteiligten äußerst hilfreich - die Fragenden, die Antwortenden und diejenigen, die darüber stolpern und sie lesen. In einem professionellen Umfeld erhalten Sie selten so nützliche Rezensionen (was möglicherweise nur an Orten der Fall ist, an denen ich aus irgendeinem Grund gearbeitet habe).

Ich rate Ihnen, einen Teil Ihres Codes zur Überprüfung einzusenden. Ich würde nicht vorschlagen, es als Munition zu verwenden, um zu beweisen, dass dieser Typ Unrecht hat - ich bezweifle, dass er sich das zu Herzen nimmt -, aber Sie können sehr nützliche Informationen sowohl über den von Ihnen geschriebenen Code als auch über den von ihm geschriebenen Code erhalten. Ich würde empfehlen, die Code-Teile einzureichen, um die Sie beide am meisten streiten. Höchstwahrscheinlich liegen Sie beide zu einem gewissen Grad falsch, und Sie können die Überprüfung verwenden, um einen objektiven Dritten dazu zu bringen, einzugreifen. Dies wird einige Dinge bewirken:

• Sie können sich von der emotionalen Spannung der Situation lösen.

• Sie erhalten professionelle Beratung in Echtzeit. Ein großer Schub für das, was Sie lernen.

• Jemand wird dir sagen, dass du falsch liegst. Was gut ist, denn jeder, der längere Zeit programmiert, wird es hören. Sie können schlecht damit umgehen wie der Typ, mit dem Sie arbeiten, oder Sie können lernen, damit umzugehen.

Ich denke, wenn Sie die Code-Überprüfungen richtig verwenden, haben Sie viel zu gewinnen, wenn Sie mit dieser äußerst frustrierenden Person umgehen. Und es ist weitaus interaktiver als ein Buch oder eine Website, auf der "Mach das, weil es die meiste Zeit der richtige Weg ist" steht.

Ebenso gibt es den Stack-Austausch für Spieleentwickler . Es ist nicht so sehr ein Ort, an dem Sie eine Postleitzahl zur Überprüfung senden, sondern nach Konzepten / Ideen fragen, mit denen Sie zu kämpfen haben. Auch hier ist dieser Ort sehr hilfreich für alle Beteiligten.

Möglicherweise haben Sie diese beiden Websites bereits zuvor gesehen. Ich wollte nur sicherstellen, dass sie Teil Ihres Toolsets sind.

Es klingt ziemlich hoffnungslos. Ich würde wahrscheinlich aufgeben und weitermachen, wenn ich es genauso empfinde wie Sie. Es kommt auf jeden Fall eine Zeit zu gehen und Sie können dort sein.

Wenn Sie noch nicht bereit sind, fortzugehen, müssen Sie einen Weg finden, um eine bessere Einigung über Ihren Prozess zu erzielen. Es hört sich so an, als hätten Sie Codierungsstandards, aber keine vereinbarten Standards. Wenn du das nächste Mal an eine Kreuzung kommst, wenn du das nächste Mal ein bisschen Code mit einem Affen spielen willst und dein Kumpel es in Ruhe lassen willst, mache ein Gespräch wie folgt:

douglas: Ich möchte es ändern, weil X, was hier in unseren Richtlinien steht.

Kumpel: Es ist in Ordnung, wie es ist.

douglas: Sie sagen also, wir sollten die Richtlinien ändern?

Kumpel: Nein, ich denke nur, dass es in Ordnung ist, wie es ist.

Douglas: Also, was sind die Richtlinien für?

Kumpel: Ich weiß nicht - du hast sie geschrieben.

Douglas: Welche Richtlinien würden Sie schreiben?

Kumpel: Ich würde keine Richtlinien schreiben. Es ist Zeitverschwendung.

Douglas: Also sollten wir einfach die Richtlinien wegwerfen und den Mist schreiben, an den wir gerade denken?

Kumpel: Das ist kein Mist.

Douglas: Ist es perfekt? Ist es ideal

Kumpel: Es erledigt die Arbeit; Fahren wir mit der nächsten Funktion fort.

Douglas: Gibt es etwas, worüber wir uns einig sein können, dass X ein guter Code und Y ein schlechter Code ist?

Kumpel: Lass mich in Ruhe; Ich möchte nur codieren!

Nun, das ist nicht gut gelaufen, oder? Ich glaube, ich habe das Gefühl, dass du und Buddy verschiedene Dinge wollen. Wenn es irgendetwas gibt, auf das Sie sich einigen können, großartig; von dort aus starten und darauf aufbauen. Aber Sie können ihn nicht dazu bringen, zu wollen, was Sie wollen - genauso wenig, wie Sie sich dazu bringen könnten, zu wollen, was er zu wollen scheint. Wenn Sie diesen gemeinsamen Wunsch finden und sich von dort aus einig werden, können Sie vielleicht zusammenarbeiten.

Douglas: Was willst du?

Kumpel: Ich möchte nur codieren.

douglas: Ich möchte auch codieren, aber ich möchte stolz auf meinen Code sein.

Kumpel: Ich bin stolz auf meinen Code.

douglas: Hier ist eine Funktion, auf die ich stolz bin - was denkst du darüber?

Kumpel: Nun, es ist in Ordnung, aber Sie sollten X innerhalb der Schleife nicht neu berechnen. es ist ineffizient.

douglas: Wollen Sie damit sagen, wir sollten außerhalb von Schleifen immer konstante Werte berechnen?

Kumpel: Nun, duh!

Douglas: Würden Sie denken, dass das in unseren Richtlinien sein sollte?

Kumpel: Natürlich.

douglas: OK, ich füge es unseren Richtlinien hinzu und aktualisiere meinen Code ...

Douglas: Wie ist es jetzt?

Kumpel: Gut.

Jetzt trägt Buddy (jedoch indirekt) zu den Richtlinien bei, und so hat er ein gewisses Gefühl von Eigenverantwortung. Vielleicht - nur vielleicht - wird er anfangen, sie ernster zu nehmen. Ich glaube, ich wäre geneigt, die Tafel abzuwischen und mit den Richtlinien von vorne zu beginnen, sodass die meisten oder alle zuerst von Buddy kommen. Mach weiter und schreibe Scheißcode, damit er das Bedürfnis verspürt, die Richtlinien zu ergänzen. lass sie von ihm kommen. Vielleicht fängt er dann an, den Grund für sie zu verstehen.

Aber wenn Sie lieber aufgeben und weitermachen möchten, ist dies möglicherweise auch keine so schlechte Option.

Angenommen, Sie entscheiden sich, das Projekt abzubrechen:

• Geben Sie den Code ein und überarbeiten Sie ihn, indem Sie ihn als Vorher / Nachher-Portfolioelement verwenden
• Da das Ziel (hauptsächlich oder teilweise) darin bestand, Programmieren zu lernen, und da das Erlernen von etwas 2 bis 4 Mal so lange dauert, wie Sie etwas bereits wissen, wird diese Arbeit nicht wirklich verschwendet.
• 'Sunk Cost Attachment' (die Investition, die Sie bereits in ein Unternehmen getätigt haben, bevor Sie erfahren haben, dass dies eine schlechte Idee war) ist einer der häufigsten menschlichen Fehler bei der Entscheidungsfindung
• Um die Freundschaft zu erhalten, sollten Sie Ihre Entscheidung so gestalten, dass die Freundschaft Vorrang vor der Kodierung hat

Sie sollten das Projekt wohl aufgeben.

Ohne mehr darüber zu wissen, als Sie uns gesagt haben, würde ich spekulieren, dass die Reibung, die Sie erfahren, erfahrungsbedingt ist.

Auch wenn Sie von Beruf kein Programmierer als IT-Profi sind, haben Sie wahrscheinlich auf die harte Tour gelernt, Dinge gleich beim ersten Mal richtig zu machen. Ihr Bezug zu Ihrem zukünftigen Selbst zeigt jedoch an, dass Sie ihn in der Vergangenheit durcheinander gebracht und gelernt haben nicht zu.

Ihr CS-Student im zweiten Jahr, auch wenn er sehr begabt ist, hat wahrscheinlich nicht die Perspektive, dies getan zu haben (wenn Sie wie ich sind, wiederholt :).

Er / sie wird nie wirklich an den Wert der Reparatur von Dingen glauben, solange er / sie keine Brandnarben hat oder in einer Kultur mit außergewöhnlicher Ingenieursdisziplin oder in beidem unterrichtet ist.

Diese Person ist möglicherweise Ihr Programmier-Peer, aber nicht Ihr Projekt-Peer. Daher ist es wahrscheinlich eine verlorene Sache, dieses Spiel als Peer-Projekt zu betreiben. Es sei denn, Sie sind bereit, nur die zukünftigen Kosten zu essen. Vielleicht ist die Beziehung für Sie wertvoll genug. Geben Sie in diesem Fall genug Seil, um sich aufzuhängen, und treten Sie ein, um das Durcheinander zu beseitigen, wenn diese Person gezwungen ist, das Problem anzuerkennen.

Andernfalls können Sie ein Projekt mit einem Kollegen abschließen oder ein Mentor / Mentee-Projekt durchführen, bei dem dies von Anfang an die Dynamik ist.

So fügen Sie allen tollen Antworten zusätzliche Punkte hinzu:

• Wie viel Aufwand wird es dauern, um das Projekt abzuschließen? Beachten Sie, dass das Beenden der "letzten 10%" viel länger dauert, als die Leute erwarten. Dazu gehören das Testen / Optimieren des Spiels, das Korrigieren der Benutzerfreundlichkeit, das Bewältigen einer Vielzahl von Zielplattformen, das Freigeben usw. Wenn es sich um ein iOS-Spiel handelt, wird der Code signiert und Apple überprüft. Ehrlich gesagt, kann die Fertigstellung so lange dauern wie die ersten "90%". Und es wird besonders schwierig, wenn der Code so schlecht ist, wie Sie es vorschlagen. (Können Sie es jetzt testen?)
• Wie wahrscheinlich ist es realistisch, dass die Leute Ihr Spiel genießen werden?
• Vorsicht vor der " Sunk Cost Heuristic ". Bewerten Sie diese Investition in Höhe von 10.000 Zeilen Code im Hinblick auf das Gesamtbild, indem Sie auf ein fertiges Produkt zurückblicken und ohne übermäßigen Optimismus.
• Kannst du weitermachen, wenn es noch 3 Jahre dauert? Ihr zwei habt unterschiedliche Entwicklungsstile (kein gutes Teammatch). Es hört sich so an, als wären Sie fast am Ende Ihrer Geduld und wenn Sie weitermachen, könnte es schwierig sein, Freunde zu bleiben.

Sie sollten Ihren Code einfach so machen, wie Sie es für richtig halten, mit Kommentaren und dergleichen und eine Kopie Ihrer Version des Codes anfertigen (falls er Ihren Code ändert).

Kämpfe nicht, werde nicht böse, lächle nur, wenn du seine schlechten Entscheidungen siehst.

Beschweren Sie sich nur als Benutzer, wenn es funktioniert, beschweren Sie sich nicht.

Gib auch nicht auf, es ist wichtig, dich an Menschen zu gewöhnen, die sich von dir unterscheiden und die in einem richtigen Job vorkommen.