Какие факторы должны влиять на то, как я определяю, когда отказаться от небольшого проекта с другом? [закрыто]

30

Я оказался в трудном положении в последнее время. Уже почти 8 месяцев работаю над игрой с приятелем по программированию. Мы оба начинали как новички в программировании примерно в августе прошлого года, он студент 2-го курса CS, я специалист по ИТ-поддержке по профессии и программист-самоучка с множеством книг и онлайн-подписок.

Проблема, с которой я постоянно сталкиваюсь, заключается в том, что когда мы пишем кусок кода, он часто будет немного взломан, будет иметь много сбоев, и если это будет совершенно новая концепция для одного из нас, полная наивных решений. Это хорошо, мы учимся, я ожидаю, что наш код будет немного взломан на первом или втором проходе. Проблема возникает, когда дело доходит до исправления и рефакторинга этих взломанных моделей поведения.

Мой напарник будет придерживаться только что сложившегося поведения, явно отказываясь видеть любую ошибку в тот момент, когда она начинает работать. Заявляя о совершенстве от части структуры, которую я даже не могу использовать, даже если у нее есть комментарии и подходящие названия методов и полей. Как бы я ни старался, я просто не могу заставить его увидеть явно очевидные недостатки, которые будут препятствовать любым дальнейшим изменениям или расширению поведения, не нарушая его полностью, и все, с чем оно так тесно связано, может быть в одном классе. Взломанные решения постоянно остаются взломанными, плохо продуманные проекты остаются такими же, какими они были, когда были впервые задуманы и протестированы.

Я трачу столько же времени на присмотр за новым кодом, сколько и сам, пишу его, я теряю то, что нужно делать. Мой партнер потерял его сегодня вечером и дал понять, что независимо от того, что, независимо от эталона, от обычной практики, от неопровержимых доказательств, его код останется таким, каким он его первым сделал. Даже если целые книги были написаны о том, почему вы хотите избежать чего-либо, он откажется признать их обоснованность, утверждая, что это просто чье-то мнение.

У меня есть личный интерес к нашему проекту, однако я не уверен, смогу ли я продолжать работать с моим партнером. Кажется, у меня есть три варианта.

  • Прекратите заботиться о кодовой базе, функционирующей после точки компиляции, и просто постарайтесь поддерживать и анализировать поведение, которое едва ли проявляется. Надеясь, что, как только вещи начнут серьезно ломаться, он увидит это и попытается сделать больше, чем просто нанести удар по принципиально некорректному дизайну.
  • Продолжайте бесконечные споры по вопросам, которые были выяснены десять лет назад другими, гораздо более способными людьми.
  • Прекратите программировать этот проект, оставив почти 10000 строк моего кода и потратив бесчисленные часы на разработку дизайна, и попробуйте найти новый проект самостоятельно.

Какой подход я могу использовать, чтобы определить, стоит ли продолжать этот проект с этим человеком? Или какие факторы должны влиять на мое решение? Мы написали много кода, и я не хочу отказываться от него без необходимости.

Дуглас Гаскелл
источник
3
Как насчет разработки согласованных руководств по стилю кодирования и процесса проверки кода? Избегайте любых спорных вопросов, просто вставьте достаточно в стандарт, чтобы вы оба могли согласиться с ним.
Брандин
25
Четвертый вариант (если это разрешительная лицензия): разветвите код и продолжайте работать самостоятельно.
Роберт Харви
4
Как лицензируется код? Вы можете раскошелиться и продолжить с кем-то еще?
Джейди
14
Как @enderland упоминает в своем ответе, в том, что вы написали, есть абсолютно массивный красный флаг: «Мой партнер потерял его сегодня вечером и дал понять, что независимо от того, что, независимо от эталона, от обычной практики, от Неопровержимое доказательство, его код останется таким, каким он его первым сделал ». Если вы можете избежать этого, сделайте это. Любой, с кем действительно стоит поработать, будет смиренен, чтобы признать, что иногда они ошибаются.
Ричард Дж. Фостер
3
Неважно, что вы решите, 10 тыс. Строк кода не потеряны: подумайте о том, что вы узнали из их написания; подумайте о том удовольствии, которое вы получили во время кодирования; и применение того, что вы узнали в (принудительной) третьей / четвертой / n + 1-й итерации, может даже сделать ее лучше, чем текущая версия. Кроме того, если вы знаете, что написать 10 тыс. Строк кода, вы можете написать 10 тыс. Строк за относительно короткое время; часто знание того, что писать, чтобы заставить вещи работать, занимает больше всего времени.
Каспер ван ден Берг

Ответы:

26

Отправленный, несовершенный код лучше, чем совершенный код на доске, которая никогда не доставляется.

Что, как говорится...

Те из вас, у кого больше опыта, или которые были в подобных ситуациях. Что ты сделал? Что бы вы посоветовали мне сделать?

Я хотел бы рассмотреть следующее.

  • Какова цель этого проекта? Весело? Деньги? Учить?
    • Вы действительно достигли этой цели?
  • Действительно ли этот человек позволяет вам лучше достичь ваших целей?
  • Как близко вы на самом деле доставки?
  • Эти проблемы мешают запуску? Или это вопрос личной гордости?
  • Есть ли преимущества работы с кем-то на добровольной основе, когда это расстраивает?

Прекратите программировать этот проект, оставив почти 10000 строк моего кода и потратив бесчисленное количество часов на разработку дизайна, и попытайтесь найти новый проект самостоятельно.

Примите во внимание вышесказанное, попробуйте продумать дополнительную работу, необходимую

Вы должны выяснить свои приоритеты и определить, стоят ли проблемы, связанные с работой с этим человеком. Мы не можем понять это для вас.

Мой партнер потерял его сегодня вечером и дал понять, что независимо от того, что, независимо от эталона, от обычной практики, от неопровержимых доказательств, его код останется таким, каким он его первым сделал.

Вы знаете, что не хотите работать с таким человеком.

Вы делаете такой проект, предположительно, потому что вы хотите изучить программирование и найти элегантность в самом ремесле.

enderland
источник
1
Спасибо за ваш ответ. Я достигаю цели получать удовольствие (когда не борюсь) и учусь. Погода, на которой можно заработать деньги, - это совсем другая история. Он помогает в достижении моих целей, однако я верю, что смогу достичь их самостоятельно, он помогает с мотивацией. Игра - отличный пример ползучести, честно говоря, я понятия не имею, когда она может появиться. Мой партнер уже несколько месяцев пытается добиться перехода с 2D на 3D, я отказываюсь, так как мы уже давно вышли за рамки наших возможностей.
Дуглас Гаскелл
1
Я был бы готов отказаться от проекта, если бы он был только моим, он был бы отброшен несколько месяцев назад. Мой мотивирующий фактор - продолжать работать с кем-то еще, даже если из-за разборок у меня возникают вопросы. Единственное, что мешает мне отказаться от него, это дружба, такая как связь с ним вне кодирования, я бы предпочел не бросать это с проектом. Конечно, это не очень логичное объяснение, так как они связаны с личными чувствами, это действительно затуманивает мои способности принимать решения.
Дуглас Гаскелл
1
самый быстрый способ потерять друга - это работать с ними на равных!
58

Это может быть культурной вещью. В некоторых культурах признать, что вы допустили ошибку, неслыханно, а попросить кого-то признать ошибку - это самое грубое, что вы можете сделать. Если это та ситуация, убегайте.

По моему опыту работы с очень умными людьми, если вы скажете им, что то, что они делают, не совсем идеально, они либо (1) дадут вам правильную и простую для понимания причину, почему то, что они делают, на самом деле правильно, (2) расскажет Вы, что они знают, что это неправильно, но у них нет времени, чтобы исправить это из-за приоритетов, или (3) спасибо, что указали на это и исправили.

Отказ учиться - это худший атрибут, который может иметь разработчик программного обеспечения. Оставь его в покое. Жизнь слишком коротка и драгоценна, чтобы тратить на него свое время.

gnasher729
источник
Спасибо, Гнашер, я периодически вижу # 2, хотя у нас нет фактического графика, поэтому я не уверен, насколько верным является ответ. Я собираюсь поспать на этом и посмотреть, что я думаю в AM, это требует обдумывания, прежде чем принимать решение.
Дуглас Гаскелл
1
«Если это так, беги». - и в целом, если вы не можете приблизиться к консенсусу относительно своих целей, вы не можете сотрудничать с кем-либо. Похоже, он не согласится с тем, что вы измените «свой» код, независимо от причины.
Стив Джессоп
Что ж, похоже, что нехватка времени не является причиной для отказа от изменений.
gnasher729
1
Это отличный ответ. Вы не можете заставить кого-то изменить свои пути! Тем не менее, похоже, что много времени и усилий вложено в проект как с его стороны, так и с вашей. Я думаю, что он может не захотеть изменить свой код, потому что он не понимает, как вы думаете, это должно быть сделано. Либо это так, либо он непослушный, но если это так, что он этого не понимает, постарайтесь помнить, что он может быть разочарован, и думать, что вы «разговариваете» с ним, даже если вы имеете в виду очень хорошо. Мой совет - постарайтесь обсудить это с ним, когда вы оба готовы.
zfrisch
^ + Легко кого-то обидеть, когда вы начинаете на том же уровне, и они превосходят вас в навыках. Я не говорю, что это точно так, но, похоже, это как-то связано с этим.
zfrisch
12

Возможно, самый простой способ - привлечь кого-то еще в проект - либо вы ошибаетесь, а его кодовая база слишком умна для вас, либо вы правы и слишком умны для всех. Вскоре вы узнаете и получите резервную копию, если она окажется мусорным, запутанным кодом уровня младшего программиста.

С другой стороны, рабочий продукт стоит любое количество лет тонко настроенного, элегантного, ясного кода. Сделайте игру, отправьте ее, затем уходите - оставьте его, чтобы он поддерживал ее и не работал на v2.

gbjbaanb
источник
2
Спасибо за ответ. Забавно, что ты упоминаешь свой первый пункт. Он пытается найти и привлечь начинающего программиста, которого он может научить помогать с проектом. Я мог только ожидать, что это ужасно получится, если там, где два человека будут следовать одному и тому же стилю взломать и забыть Мне нравится второй вариант, сделай его, отправь и оставь. Проблема, с которой я мог бы столкнуться, заключается в том, что мы на полпути, хотя и создаем LLC, чтобы у нас было название, под которым мы будем поставлять нашу игру. Оба использования будут иметь 50% доли, конечно. Тем не менее, я мог бы просто закончить это и затем двигаться дальше. Проект большой, это может занять какое-то время.
Дуглас Гаскелл
20
Вы ни при каких обстоятельствах не хотите вступать в юридически обязательные деловые отношения с таким человеком.
gnasher729
3
@ douglasg14b пригласи младшего учить .. бедного ребенка. Предложите пригласить опытного парня, «поскольку он быстрее наберет скорость и поможет закончить продукт». Нацельтесь на финишную прямую - или вы оба намерены работать над этим увлечением вечно и во веки веков? (видел, что это произойдет, пока не будет отменено)
gbjbaanb
Я планирую закончить это, определенно. Хотя я считаю, что это был слишком большой проект, чтобы заниматься им как первым. Все началось с простого дизайна, и не предполагалось, что оно станет таким масштабом, как сейчас. Мой партнер постоянно сталкивается с ограничением возможностей, так как я частично виноват в этом, потому что я позволю этому случиться и даже согласен с некоторыми функциями. Суть в том, что если оставить его в покое, мы, вероятно, смотрим на завершение в течение года. К счастью, благодаря тому, как я это запрограммировал, детали можно легко вынуть и потом поместить в другие проекты.
Дуглас Гаскелл
4
Думайте о коде как о принадлежащем проекту, а не вам. Если у вас есть совместное владение продуктом, вы можете повторно использовать весь код для вашего следующего проекта. Если вы понятия не имеете, кому что принадлежит, обсудите это сейчас. Удачи.
gbjbaanb
9

Вот некоторые идеи, даже если некоторые из них являются взаимоисключающими.

  • Отдельные источники ответственности. Если вы работаете над модулем A, а он над модулем B, вы можете соревноваться с разными стилями. Он часто выпускает рабочие функции? Достигает ли он точки, когда ему нужно переписать свой код с нуля? Рефакторинг кода из ваших модулей и не трогайте его,

  • Пусть он сделает обслуживание своего худшего кода. Если он делает это успешно, вы избежали ужасной задачи. Если он не в состоянии, он почувствует боль.

  • Рассмотрим это с точки зрения пользователя или бизнеса. В некоторых случаях вам нужен только жизнеспособный продукт, который может купить Google или Microsoft. В других случаях вы запускаете продукт на рынок, и поддержка тысяч клиентов с ошибочным или взломанным кодом будет адом. Не то же самое, если ваш код контролирует дронов с ядерными ракетами или делает счастливые видео для подростков.

  • Он делает уроки, вы делаете тесты. Рефакторинг кода с помощью тестов проще и безопаснее. Таким образом, вам не нужно заглядывать внутрь кода только в панель Junit. Это предполагает, что A) вы программируете тесты, B) код вашего коллеги тестируемый. Если вам сложно построить тесты на этапе кодирования, последний будет хуже.

  • Идите вместе на тренировки или мероприятия. Когда вы не знаете правильный путь, это вполне естественно, используйте единственный способ, которым вы знаете. Просмотр чужого кода может решить не все, но попытка не помешает.

  • Найдите свои дополнительные сильные стороны. Рефакторинг иногда может быть веселым. Если он пишет вещи, которые хотя бы работают, вы можете выполнить рефакторинг. Он может делать шипы, чтобы исследовать решения, которые не заканчиваются в производственном коде.

  • Возможно, он не захочет переписывать код, но может согласиться написать новый код лучше. Я понимаю, что переписать сложно, скучно и может сломать вещи. Вырасти несколько островов качества. Таким образом, у него будут хорошие примеры того, как делать вещи.

  • Используйте правило бойскаута . Оставляйте вещи нетронутыми, если вам не нужно над этим работать. Если модуль плохо написан, но работает и не нуждается в замене, оставьте его таким. Если вам нужно исправить ошибку или завершить функцию, немного улучшите ее. Через некоторое время 20% классов, которые вы меняете 80% времени, улучшатся. Больше островов качества.

Мы не можем предложить лучшее решение, не зная вас обоих. Удачи.

Borjab
источник
4

Хорошо, вот ответ, который вам, вероятно, не понравится.

Не «исправляйте» код, если он не может реализовать эту функцию.

Вот мои рассуждения. Вы, вероятно, пытаетесь заработать деньги. Чтобы заработать деньги, вы должны быстро отправить завершенные функции. Никто не заплатит вам больше за «хорошо закодированную» компьютерную игру.

У большинства компаний такая же проблема. Рефакторинг существующего кода, чтобы сделать его «лучше», иногда даже объективно лучше с точки зрения скорости или надежности ИЛИ писать новые функции.

99% времени они выбирают написание новых функций, потому что это результат простого анализа затрат и выгод.

Ewan
источник
15
Это подпадает под весь аргумент "технического долга", верно? Когда вы пишете эту новую функцию (или изменяете существующую), занимает ли она в три раза больше времени и производит ли она в десять раз больше ошибок, чем если бы вы не отставали от своего рефакторинга? Если так, то, возможно, пропуск рефакторинга был ложной экономикой.
Бен Ааронсон
1
Вы бы так подумали, но я работал во многих успешных компаниях, и я (почти) никогда не вижу рефакторинга в качестве первоочередной задачи. Мой вывод заключается в том, что это просто не окупается.
Эван
Это достаточно справедливо, и я уверен, что по этому поводу существует целый ряд мнений, просто кажется, что отказ от того или иного ответа является существенным упущением в ответе. Также я могу ошибаться, но читая между строк в вопросе, я думаю, что плохой код, о котором беспокоится ОП, может быть намного хуже, чем тот код, о котором вы думаете.
Бен Ааронсон,
хе да но также кажется, что стоимость внесения изменений очень высока. В своем ответе я стараюсь дать цель «Вы в этом за деньги?» ответ, плюс мое субъективное мнение о том, где лежит баланс вероятности
Ewan
1
В некоторых случаях это оправданно, но если чей-то «рабочий код» заставляет другого человека тратить в два раза больше времени на его код или совместную интеграцию систем или будущую работу, это больше не является простым решением «корабль против корабля». Многие крупные проекты умирают, потому что они не принимают решения, чтобы сделать это правильно, а не быстро.
enderland
3

Мне нравятся все ответы до сих пор. Взяв один из пунктов ответа Эндерланда :

Есть ли преимущества работы с кем-то на добровольной основе, когда это расстраивает?

Я хотел бы воспользоваться этим временем, чтобы подключиться к обмену стеками обзора кода . Это прекрасное место, где вы можете получить критику своего кода профессионалами. И, честно говоря, многие обзоры кода очень полезны для тех, кто в них участвует - для тех, кто спрашивает, кто отвечает, и тех, кто спотыкается и читает их. Вы редко получаете такие полезные отзывы в профессиональной обстановке (что может иметь место только в тех местах, где я работал по любой причине).

Мой совет - выложить часть кода для проверки. Я бы не советовал использовать его как боеприпасы, чтобы доказать, что этот парень не прав - я сомневаюсь, что он примет это близко к сердцу - но вы можете получить очень полезную информацию как о написанном вами коде, так и о коде, который он написал. Я бы порекомендовал представить фрагменты кода, которые вы оба сражаетесь больше всего. По всей вероятности, вы оба в какой-то степени неправы, и вы можете использовать обзор как способ заставить объективную третью сторону вмешаться. Это позволит выполнить несколько вещей:

  • Вы можете отключиться от эмоциональной напряженности ситуации.

  • Вы получите профессиональную консультацию в реальном времени. Большой импульс к тому, что вы изучаете.

  • Кто-то скажет вам, что вы не правы. Это хорошо, потому что любой, кто занимается программированием в течение любого промежутка времени, услышит это. Вы можете справиться с этим плохо, как этот парень, с которым вы работаете, или вы можете научиться справляться с этим.

Я думаю, что если вы правильно используете рецензии кода, вы сможете получить много пользы, имея дело с этим крайне разочаровывающим человеком. И это гораздо более интерактивно, чем книга или веб-сайт, на котором написано: «Делай это, потому что в большинстве случаев это правильный путь».

Точно так же есть обмен стека разработчиков игр . Не столько место, чтобы опубликовать код для обзора, но чтобы спросить о концепциях / идеях, с которыми вы боретесь. Опять же, это место очень полезно для всех участников.

Возможно, вы видели оба этих сайта раньше; Я просто хотел убедиться, что они являются частью вашего набора инструментов.

Shaz
источник
2

Это звучит довольно безнадежно. Я бы, наверное, сдался и пошел дальше, если бы чувствовал к этому то же самое, что и вы; определенно наступает время, чтобы уйти, и вы можете быть там.

Если вы еще не готовы уйти, вам нужно найти способ прийти к лучшему соглашению о вашем процессе. Похоже, у вас есть стандарты кодирования, но не согласованные стандарты. В следующий раз, когда вы придете к перекрестку, в следующий раз, когда вы захотите поиграть с небольшим количеством кода, а ваш собеседник захочет оставить его в покое, стреляйте в разговор по следующим направлениям:

Дуглас: Я хочу изменить это, потому что X, что прямо здесь, в наших рекомендациях.

приятель: это нормально, как это.

Дуглас: То есть вы говорите, что мы должны изменить правила?

приятель: нет, я просто думаю, что это нормально, как это.

Дуглас: Так, каковы рекомендации?

приятель: я не знаю - ты их написал.

Дуглас: Какие руководящие принципы вы бы написали?

приятель: я бы не стал писать рекомендации Это пустая трата времени.

Дуглас: Значит, мы должны просто выбросить руководящие принципы и написать какую-нибудь ерунду, о которой мы думаем в то время?

приятель: это не дерьмо.

Дуглас: Это идеально? Это идеально?

приятель: он выполняет свою работу; давайте перейдем к следующей функции.

Дуглас: Есть ли что-то, с чем мы можем согласиться, что X - это хороший код, а Y - плохой код?

приятель: оставь меня в покое; Я просто хочу код!

Ну, это не очень хорошо, не так ли? Я думаю, у меня такое чувство, что ты и Бадди хотите разных вещей. Если есть что-то, о чем вы можете договориться, отлично; начать с этого и строить на нем. Но вы не можете заставить его согласиться хотеть то, что вы хотите - больше, чем вы можете заставить себя хотеть то, что он, кажется, хочет. Если вы можете найти это общее желание и прийти к общему согласию оттуда, возможно, вы можете работать вместе.

Дуглас: Что ты хочешь?

приятель: я просто хочу код

Дуглас: Я тоже хочу кодировать, но я хочу гордиться своим кодом.

приятель: я горжусь своим кодом.

Дуглас: Вот функция, которой я горжусь - что вы об этом думаете?

приятель: Ну, все в порядке, но вы не должны пересчитывать X внутри цикла; это неэффективно.

Дуглас: Так вы говорите, что мы всегда должны вычислять постоянные значения вне циклов?

приятель: Ну, да!

Дуглас: Как вы думаете, это должно быть в наших рекомендациях?

приятель: конечно.

Дуглас: Хорошо, я добавлю его в наши правила и обновлю свой код ...

Дуглас: Как это сейчас?

приятель: хорошо.

Теперь Бадди вносит свой вклад в руководство (хотя и косвенно), и поэтому у него есть чувство причастности. Возможно - просто возможно - он начнет относиться к ним более серьезно. Я думаю, что я был бы склонен вытереть планшет и начать все сначала с инструкций, позволяя сначала большинству или всем из них прийти от Бадди. Идите вперед и напишите код дерьма, чтобы он почувствовал необходимость добавить к руководству; пусть они исходят от него. Может быть, тогда он начнет понимать причину их.

Но если вы предпочитаете сдаться и двигаться дальше - это может быть не таким уж плохим вариантом.

Карл Манастер
источник
2

Предполагая, что вы решили отказаться от проекта:

  • Форк код и рефакторинг, используя его в качестве элемента портфеля «до / после»
  • Поскольку целью было (в основном или частично) научиться программированию, а изучение чего-либо занимает в 2-4 раза больше времени, чем то, что вы уже знаете, эта работа на самом деле не тратится впустую.
  • «Потеря вложенных затрат» (инвестиции, которые вы уже вложили в предприятие до того, как узнали, что это плохая идея), является одной из самых распространенных человеческих ошибок при принятии решений.
  • Чтобы сохранить дружбу, сформулируйте свое решение как расстановку приоритетов над кодированием
Эми
источник
1

ТЛ; Др, вы, вероятно, должны отказаться от проекта.

Не зная больше об этом, чем вы сказали нам, я бы предположил, что трение, которое вы испытываете, связано с опытом.

Несмотря на то, что вы не программист по профессии, как ИТ-профессионал, вы, вероятно, с трудом научились правильно делать все с первого раза, но ваша ссылка на себя в будущем указывает на то, что вы его облажали в прошлом и научились не для.

Ваш студент 2-го курса CS, даже если он достаточно одарен, вероятно, не имеет возможности сделать это (если вы, как я, неоднократно :).

Он / она никогда не поверит в ценность исправления вещей, пока вы идете, пока у него / нее не появятся ожоговые шрамы от невыполнения этого требования или его наставничество в культуре с исключительной инженерной дисциплиной или обоими.

Этот человек может быть вашим партнером по программированию, но не вашим партнером по проекту, поэтому выполнение этой игры как однорангового проекта, скорее всего, потеряно. Если вы не готовы просто съесть будущую стоимость. Может быть, отношения достаточно ценны для вас. В этом случае дайте ему / ей достаточно веревки, чтобы повеситься и вмешайтесь, чтобы помочь навести порядок, когда этот человек вынужден признать проблему.

В противном случае внесите залог и сделайте проект с пэром, или сделайте проект наставника / ученика, где это динамично с самого начала.

Джаред Смит
источник
1

Чтобы добавить дополнительные очки ко всем отличным ответам:

  • Сколько еще усилий потребуется для завершения проекта? Обратите внимание, что завершение «последних 10%» занимает гораздо больше времени, чем ожидают люди. Это включает в себя тестирование / настройку игры, исправление юзабилити, работу с различными целевыми платформами, выпуск, ... Если это игра для iOS, то есть подписание кода и прохождение обзора Apple. Честно говоря, отделка может занять столько же, сколько и первые «90%». И будет очень сложно, если код будет таким плохим, как вы предлагаете. (Можете ли вы начать играть в тестирование сейчас?)
  • Реально, насколько вероятно, что люди будут наслаждаться вашей игрой?
  • Остерегайтесь " эвристики затонувших затрат ". Оцените эти 10000 вложенных строк кода в свете общей картины, оглядываясь на готовый продукт и без излишнего оптимизма.
  • Можете ли вы продолжать идти, если это займет еще 3 года? У вас двоих разные стили разработки (плохой командный матч). Звучит так, словно вы уже на пороге терпения, и если вы продолжите идти, может быть трудно оставаться друзьями.
Jerry101
источник
3
«Последние 10%» занимают намного больше времени, если 90% кода является мусором :-(
gnasher729
0

Вы должны просто продолжать делать свой код так, как вы думаете, правильно, с комментариями и тому подобным, и делать копию своей версии кода (на случай, если он изменит ваш код).

Не борись, не злись, просто улыбайся, когда видишь его плохие решения.

Жалуйтесь только как пользователь, если он работает, не жалуйтесь.

Не сдавайся, важно привыкнуть к людям, которые отличаются от тебя, что случится на реальной работе.

мандрил
источник