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

30

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.

Douglas Gaskell
quelle
3
Was ist mit vereinbarten Richtlinien für den Codierungsstil und einem Codeüberprüfungsprozess? Vermeiden Sie umstrittene Themen, schreiben Sie einfach so viel in den Standard, dass Sie beide zustimmen können.
Brandin
25
Vierte Option (wenn es sich um eine Lizenz handelt): Geben Sie den Code ein und arbeiten Sie selbstständig weiter.
Robert Harvey
4
Wie ist der Code lizenziert? Kannst du es herausholen und mit jemand anderem weitermachen?
Jaydee
14
Wie @enderland in seiner Antwort erwähnt, gibt es eine absolut massive rote Fahne in dem, was Sie geschrieben haben: "Mein Partner hat es heute Abend verloren und deutlich gemacht, dass egal was, egal der Benchmark, egal die gängige Praxis, egal die Der unwiderlegbare Beweis, dass sein Code so bleiben wird, wie er es zuerst gemacht hat. " Wenn Sie davon abkommen können, tun Sie dies. Jeder, mit dem es sich wirklich lohnt zu arbeiten, wird die Demut haben zu akzeptieren, dass er manchmal etwas falsch macht.
Richard J Foster
3
Egal, für was Sie sich entscheiden, die 10-KB-Codezeilen gehen nicht verloren. Denken Sie daran, was Sie beim Schreiben gelernt haben. Denken Sie an das Vergnügen, das Sie während der Zeitkodierung hatten. und wenn Sie das, was Sie in einer (erzwungenen) dritten / vierten / n + 1ten Iteration gelernt haben, anwenden, wird es möglicherweise sogar besser als die aktuelle Version. Außerdem können Sie , wenn Sie wissen, wie man 10.000 Codezeilen schreibt, 10.000 Zeilen in relativ kurzer Zeit schreiben. Oft ist es das Wissen, was zu schreiben ist, um Dinge zum Laufen zu bringen, was die meiste Zeit benötigt.
Kasper van den Berg

Antworten:

26

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.

Enderland
quelle
1
Danke für Ihre Antwort. Ich erreiche den Zweck, Spaß zu haben (wenn ich nicht kämpfe) und zu lernen. Das Wetter, in dem man Geld verdienen kann, ist eine ganz andere Geschichte. Er hilft bei der Erreichung meiner Ziele, obwohl ich glaube, dass ich sie allein noch erreichen kann, er hilft bei der Motivation. Das Spiel ist ein großartiges Beispiel für Feature Creep. Ich habe ehrlich gesagt keine Ahnung, wann es ausgeliefert werden kann. Mein Partner versucht seit Monaten, den Wechsel von 2D zu 3D voranzutreiben, was ich ablehne, da wir unseren Rahmen schon lange überschritten haben.
Douglas Gaskell
1
Ich wäre bereit, das Projekt fallen zu lassen, wenn es nur mein eigenes wäre, wäre es vor Monaten fallen gelassen worden. Mein motivierender Faktor, um fortzufahren, ist es, jemanden zu haben, mit dem ich zusammenarbeiten kann, auch wenn ich das einige Tage in Frage stelle. Das einzige, was mich davon abhält, es aufzugeben, ist eine freundschaftliche Beziehung zu ihm außerhalb des Programmierens. Ich würde es lieber vermeiden, das mit dem Projekt zu werfen. Natürlich ist dies keine sehr logische Erklärung, da es sich um persönliche Gefühle handelt, die meine Entscheidungsfähigkeit wirklich verschlechtern.
Douglas Gaskell
1
Der schnellste Weg, einen Freund zu verlieren, ist, mit ihm auf Augenhöhe zu arbeiten!
58

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.

gnasher729
quelle
Vielen Dank, Gnasher. Ich sehe in regelmäßigen Abständen die Nummer 2, obwohl wir keinen Zeitplan haben. Daher bin ich mir nicht sicher, wie gültig eine Antwort ist. Ich werde darüber schlafen gehen und sehen, was ich in der AM denke. Dies erfordert viel Überlegung, bevor ich eine Entscheidung treffe.
Douglas Gaskell
1
"Wenn es so ist, lauf weg." - und nur im Allgemeinen können Sie nicht mit jemandem zusammenarbeiten, wenn Sie nicht nahe an einem Konsens sind, was Ihre Ziele sind. Klingt so, als würde er nicht zustimmen, dass Sie "seinen" Code ändern, egal aus welchem ​​Grund.
Steve Jessop
Nun, es scheint, dass Zeitdruck nicht der Grund ist, Änderungen abzulehnen.
gnasher729
1
Das ist eine großartige Antwort. Sie können niemanden zwingen, sich anders zu verhalten! Es hört sich jedoch so an, als würde viel Zeit und Mühe in das Projekt gesteckt, sowohl für ihn als auch für Sie. Ich denke vielleicht, dass er seinen Code nicht ändern möchte, weil er nicht versteht, wie Sie denken, dass es getan werden sollte. Entweder das oder er ist verärgert, aber wenn es so ist, dass er es nicht versteht, denken Sie daran, dass er möglicherweise frustriert ist, und denken Sie, dass Sie mit ihm "runterreden", obwohl Sie es sehr gut meinen. Mein Rat ist, es mit ihm zu besprechen, wenn ihr beide bereit seid.
zfrisch
^ + Es ist leicht, von jemandem beleidigt zu werden, wenn Sie auf dem gleichen Niveau anfangen und er Sie in der Fähigkeit übertrifft. Ich sage nicht, dass dies mit Sicherheit der Fall ist, aber es hört sich mit Sicherheit so an, als ob es etwas damit zu tun haben könnte.
zfrisch
12

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.

gbjbaanb
quelle
2
Danke für Ihre Antwort. Komisch, dass Sie Ihren ersten Punkt erwähnen. Er versucht, einen neuen Programmierer zu finden und zu gewinnen, den er lehren kann, um bei dem Projekt zu helfen. Ich konnte nur erwarten, dass sich das fürchterlich entwickeln würde, wenn zwei Leute den gleichen Hack- und Vergessensstil verfolgen würden. Ich mag die zweite Option, mache es, versende es und lasse es dann. Das Problem, auf das ich stoßen könnte, ist, dass wir uns auf halbem Weg befinden, um eine LLC zu gründen, damit wir einen Namen haben, unter dem wir unser Spiel ausliefern können. Natürlich haben beide einen Anteil von 50%. Ich könnte es jedoch einfach beenden und dann weitermachen. Das Projekt ist groß, das könnte eine Weile dauern.
Douglas Gaskell
20
Sie nicht unter keinen Umständen wollen so eine rechtlich bindende Geschäftsbeziehung mit einer Person einzugeben.
gnasher729
3
@ douglasg14b bring einen junior zum unterrichten .. armes kind. Schlagen Sie vor, einen erfahrenen Mitarbeiter hinzuzuziehen, "der schneller auf Touren kommt und das Produkt fertigstellt". Visieren Sie eine Ziellinie an - oder wollen Sie beide für immer und ewig an diesem Hobby arbeiten? (gesehen, dass passieren, bis es abgesagt wird)
gbjbaanb
Ich plane es definitiv zu beenden. Obwohl ich glaube, dass es ein viel zu großes Projekt war, um es als unser erstes anzugehen. Es begann als einfaches Design, es sollte nicht annähernd so groß sein, wie es jetzt ist. Die Grenzen unseres Geltungsbereichs werden von meinem Partner ständig durch Feature-Creep erweitert. Ich bin teilweise schuld daran, dass ich dies zulasse und sogar einigen Features zustimme. Der Umfang ist so groß, dass wir, wenn wir alleine sind, wahrscheinlich mit der Fertigstellung innerhalb eines Jahres rechnen. Dank meiner Programmierung können Teile einfach herausgenommen und später in andere Projekte eingefügt werden.
Douglas Gaskell
4
Stellen Sie sich den Code als Teil des Projekts vor, nicht für Sie. Wenn Sie Miteigentum an dem Produkt haben, können Sie den gesamten Code für Ihr nächstes Projekt wiederverwenden. Wenn Sie keine Ahnung haben, wem was gehört, dann führen Sie diese Diskussion jetzt. Viel Glück.
gbjbaanb
9

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.

Borjab
quelle
4

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.

Ewan
quelle
15
Dies fällt jedoch unter das gesamte Argument der "technischen Verschuldung", oder? Wenn Sie dieses neue Feature schreiben (oder ein vorhandenes ändern), dauert es dreimal so lange und produziert zehnmal so viele Bugs, als wenn Sie mit Ihrem Refactoring Schritt gehalten hätten? Wenn ja, dann war das Überspringen des Refactorings vielleicht eine falsche Wirtschaft.
Ben Aaronson
1
Sie würden es glauben, aber ich habe in vielen erfolgreichen Unternehmen gearbeitet und sehe (fast) nie ein Refactoring mit hoher Priorität. Mein Fazit ist, dass es sich einfach nicht auszahlt.
Ewan
Das ist fair genug und ich bin mir sicher, dass es eine Reihe von Meinungen dazu gibt. Es scheint nur so, als würde man nicht darauf eingehen, dass die eine oder andere Art eine signifikante Lücke in der Antwort ist. Ich kann mich auch irren, aber wenn ich zwischen den Zeilen in der Frage lese, denke ich, dass der schlechte Code, über den das OP besorgt ist, viel schlimmer sein kann als die Art von Code, an den Sie denken.
Ben Aaronson
heh, yup! aber es hört sich auch so an, als ob die Kosten für die Durchführung der Änderungen sehr hoch sind. In meiner Antwort versuche ich, das Ziel zu geben: Bist du dabei für das Geld? antworte, plus meiner subjektiven ansicht, wo das gleichgewicht der wahrscheinlichkeiten liegt
ewan
1
Dies ist in einigen Fällen sinnvoll, aber wenn jemandes "Arbeitscode" eine andere Person veranlasst, doppelt so viel Zeit mit dem Code zu verbringen oder Systeme zusammen zu integrieren oder in Zukunft zu arbeiten, ist dies keine einfache Entscheidung mehr "Schiff gegen Schiff". Viele große Projekte sterben, weil sie sich nicht dafür entscheiden, es richtig und nicht schnell zu machen.
Enderland
3

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.

Shaz
quelle
2

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.

Carl Manaster
quelle
2

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
Amy
quelle
1

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.

Jared Smith
quelle
1

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.
Jerry101
quelle
3
Die "letzten 10%" dauern viel länger, wenn 90% des Codes Müll sind :-(
gnasher729
0

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.

Mandrill
quelle