Как преобразовать копир / вставить / спагетти программист, чтобы увидеть свет?

35

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

Допустим, в вашей команде есть кто-то (или, может быть, большинство), чья стандартная рабочая процедура заключается в копировании / вставке и которая считает, что все можно решить, если только вы добавите достаточно вызовов функций и переменных. Этот человек никогда не слышал о TDD, DRY или SOLID, и за пределами 40 часов на работе, когда он занят работой, он ни разу не прочитал ни одной методологии / практики / книги о дизайне.

В прошлом я (и другие) спрашивал, как вы учите OOD . Но сейчас я думаю, что это не правильный вопрос. На самом деле вопрос в том, как вы подходите к такому человеку / команде и хотите узнать, как лучше поступить? Как вы вдохновляете их учиться? Без этого кажется, что все преподавание, встречи, лекции, дискуссии бесполезны, если они совершенно счастливы, возвращаясь к своему столу и делая то, что они всегда делали.

Я работаю с такими людьми. Они на самом деле довольно яркие люди, но я ненавижу, когда слышу: «Я закончил программировать, мне просто нужно провести рефакторинг и разбить его на несколько классов, чтобы сделать ДХМ счастливым». Они не делают рефакторинг для более чистого, читабельного, обслуживаемого кода, но только потому, что иначе их будут ругать. Я знаю, что они способны к обучению, просто кажется, что вообще отсутствует мотивация.

Когда я выполняю работу, в ней обычно гораздо меньше ошибок, и работа, которой я владел, никогда не становилась чудовищем класса из 5000 строк. Другие будут комментировать, например, «ваш код намного чище и удобнее для чтения, чем наши материалы», поэтому они видят разницу. Но в то же время, я чувствую, что они считают, что им платят за 40 часов, независимо от того, что они делают, поэтому они на самом деле не возражают, если они проведут 3 полных дня в QA в поисках ошибки, которая не должна была быть внесена в первое место. Или что они занимают неделю, чтобы изменить один класс, потому что есть так много зависимостей, которые они в конечном итоге касаются. Тем не менее, «возможно, этот класс должен быть написан по-другому», кажется, никогда не всплывает.

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

ПРИМЕЧАНИЕ: когда я говорю «отсутствие мотивации». Я не думаю, что это отсутствие мотивации, чтобы работать или делать хорошую работу, потому что они просто перестали заботиться. Большая часть нашей команды на самом деле совсем наоборот. Они определенно заботятся о продукте. У нас есть ребята, которые будут работать по вечерам и выходным. Часть, которую я пытаюсь пройти, - это улучшение привычек и навыков, им на самом деле не нужно было бы так много работать. Я думаю, что "40 часов" заставили этот пост звучать слишком негативно.

DXM
источник
Какая это страна?
3
@ ThorbjørnRavnAndersen - США. теперь вы должны написать ответ, потому что мне очень любопытно, как эта информация повлияла на это :) Я всегда думал, что мы все люди, и этот тип материала универсален. И нет, этот вопрос не имеет ничего общего с аутсорсингом.
ДХМ
8
Культурные различия между странами могут быть существенными, и любая попытка внести изменения должна учитывать это. То, что работает в одной культуре, скорее всего, не будет работать в другой. В вашем случае я считаю, что лучший способ - это заставить руководство официально поднять планку того, что приемлемо.

Ответы:

18

Вы нашли себе причину: «Я знаю, что они способны к обучению, просто кажется, что вообще отсутствует мотивация».

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

Это явление существует в каждой работе. Просто некоторые работы не очень увлекательны (вы видели бухгалтера, который любит свою работу и мечтал об этом уже в детстве?), Но в программировании есть много людей, которые действительно любят то, что делают (иначе Programmers.SE будет довольно пустым). Это означает, что как страстные разработчики, которые ежедневно общаются с другими страстными разработчиками, у нас больше шансов удивиться, увидев человека, который занимается программированием только за деньги.

Что мы можем сделать? Не очень много. Во всех случаях не вам, а человеческим ресурсам выбирать людей, которые действительно мотивированы ». И увольнять людей, которых нет.

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

Вы можете:

  • Убедите своего босса установить ряд строгих правил в вашей компании: правила стиля и т. Д. Это не побудит этих людей выполнять работу лучше, но, по крайней мере, они не смогут коммитить исходный код, который не соответствует требованиям ,

  • Работа над требованиями, особенно не функциональными требованиями . Как насчет требования, которое говорит о том, что конкретный проект должен содержать менее 5 000 строк кода IL (нет, я не говорю о бессмысленном LOC ) ³? Как насчет необходимости получать конкретные результаты при цикломатической сложности или сопряжении классов ?

  • Увеличьте количество часов, которые вы проводите в своей компании, просматривая код . Укажите, что проверяется: если у вас есть контрольный список, добавьте пункты, связанные с рефакторингом, удобочитаемостью, чистыми и полезными комментариями и т. Д. Если у вас нет контрольного списка, вы должны это сделать.

  • Используйте [больше] парного программирования . Это может помочь улучшить качество кода и мотивировать менее мотивированных сотрудников.

  • Используйте систему компенсации, аналогичную той, которая используется в Fog Creek.


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

² Им действительно все равно, даже если они получают меньше денег. Я довольно близок к одному из моих клиентов (я фрилансер), который считает, что его работа заключается в разработке веб-сайтов для своих клиентов. У него также есть дизайнер. Я много раз рассказывал им о том, как они могут повысить свою производительность на 2 и более. Если бы они просто наняли кого-то компетентного, они бы увеличили свой доход как минимум на 3. Но у них достаточно денег, и им нет дела до качества или того, сколько они стоят для невежественных клиентов, по сравнению с кем-то продуктивным.

³ Я имею в виду количество строк кода IL, которые вы видите в метриках кода в Visual Studio , метрика, которая на самом деле что-то значит. Реальный LOC не имеет значения , и вы не должны измерить; это один из самых глупых показателей за всю историю. Применение строк кода IL означает, что разработчики будут вынуждены фактически реорганизовать код, а не просто свести десять строк кода в одну нечитаемую строку.

Арсений Мурзенко
источник
3
Я не согласен: мотивация к работе и мотивация к учебе - это две совершенно разные вещи. Например, некоторые люди любят свою работу и работу, но они могут подумать, что «SOLID» - это просто еще одно модное словечко-бинго, или «TDD» - это какая-то концепция башни из слоновой кости, бесполезная в реальном мире.
nikie
5
@maple_shaft прав: некоторые люди работают 70 часов в неделю и вырабатывают худший объем спагетти-кода без каких-либо тестов (у них нет времени на такую ​​ерунду!). Хотя они страстные и постоянно совершенствуют свои навыки, но возвращаются домой через 40 часов, потому что они знают, что не могут быть продуктивными дольше, чем это в любом случае. Не путайте две вещи!
nikie
13
Нет нет нет. Готовность эксплуатироваться работодателем! = Способность производить качественный код. Слишком много этого «оставайся до 2 часов ночи, чтобы сделать это», чепуха, происходящая в нашей отрасли, уже без нашей связи с каким-то мифическим Идеальным Разработчиком. Если вы любите работать 80 часов в неделю, вам больше под силу. У меня есть вещи, которые важны для меня помимо работы. В заключение, я плох в том, что я делаю, потому что это в лучшем случае ложно. Ни одна другая отрасль не может избежать неприятностей с нашей, и мы должны изменить это, если оно изменится.
Дэн Рэй
6
Необходимость работать до 2 часов ночи для работы над проектом - очень эффективный способ убить любую любовь к указанному проекту, особенно для тех, у кого есть семейные обязанности.
2
Я думаю, что все приведенные здесь пункты верны, но некоторые из вас, возможно, неправильно поняли MainMa. Он никогда не говорил работу до 2 часов ночи, потому что вы вынуждены из-за сроков. Вместо этого он просто сослался на людей, которые так увлечены волнением от того, что видят что-то работающее, что иногда они предпочитают это сделать, чем ложатся спать. Я могу относиться к этому. Для меня одним из крайних примеров была задача, над которой я работал, чтобы добавить поддержку туннелирования в нашу библиотеку потокового видео. Это оценивалось в 5 дней, но с нашей новой конвейерной архитектурой все складывалось так хорошо, что я начал в пятницу днем ​​...
ДХМ
12

«Я закончил программировать, просто нужно провести рефакторинг и разбить его на несколько классов, чтобы сделать ДХМ счастливым».

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

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

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

Вы поддерживаете лучшие практики и стандарты, указывая команде, как они улучшили процесс разработки программного обеспечения или качество программного обеспечения.

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

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

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

maple_shaft
источник
1
+1 за акцент на сосредоточении внимания на отношениях, а не на принципах
sunwukung
5

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

  • Они думают, что слишком заняты, чтобы изучать что-то новое, или думают, что новый способ работы (например, написание всех этих тестов) займет у них больше времени, и у них нет на это времени. Тогда очевидный ответ: дать им больше времени. Изучение чего-либо или попытка чего-то подобного TDD, когда вы всегда делаете что-то по-другому , в первые пару раз займет больше времени. Если у ваших программистов нет этого времени, вы не можете винить их за то, что они не пытались.
  • Они по-разному воспринимают свои навыки, т. Е. Считают себя очень хорошими программистами, создающими высококачественный код. Это сложный психологический ландшафт, потому что разрушение этой веры может быть очень демотивирующим. Может быть, какая-то неформальная конкуренция может помочь (кто производит наименьшее количество дефектов / функций, самый короткий код, наименьшее количество WTF / минут в обзоре кода?).
  • Может быть реальная проблема с мотивацией (то есть они просто хотят «сделать свое время и остаться один» до закрытия). К счастью, это слишком общее / не связанное с программированием, потому что у меня действительно нет ответа на это.
  • Они новички, и они не знают лучше. В этом случае может помочь обучение, проверка кода или «книжный клуб», где член команды должен обсуждать новую техническую книгу каждый месяц.
  • Они видели серебряные пули раньше (и были горько разочарованы), и они думают, что то, что вы пытаетесь продать им, это просто еще одно модное слово, которое звучит хорошо в теории и мало полезно на практике. В этом случае демонстрация преимуществ во время анализа кода и парных сеансов программирования может работать. Старайтесь не быть всезнайкой, когда будете это делать.

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

nikie
источник
Хорошие моменты. Мне особенно нравится первый - и я бы даже обобщил: сначала вы должны дать понять, что обучение на работе поощряется , и что можно явно выделить время для него.
Слёске
Если люди по-разному воспринимают свои навыки, может, они просто измеряют успех по разным параметрам? Если вы измеряете качество кода, и они думают о том, как быстро код может быть создан, очевидно, что результат будет другим - в таких случаях следует спросить, как они измеряют успех. Разные люди по-разному думают об этом.
tp1
3

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

Это оно! Это действительно настоящий вопрос.

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

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

Я не знаю, прав ли я; но часто я верю в диалог Матрицы фильма - «Это вопрос, который движет нами!» Самое главное - заставить их думать, заставить их спросить, почему! И, конечно же, большинство из тех, кто думает, что они уже знают все о некоторых шаблонах проектирования, потому что они получили хорошие оценки на университетских курсах, - являются самыми трудными там.

Как вы задаете им такие вопросы? Мой общий подход - «бросайте их в пруд, если хотите, чтобы они научились плавать» . Я согласен, что люди могут не соглашаться; и я с удовольствием соглашусь не соглашаться с ними. Когда вы бросаете их в пруд - они на самом деле не учатся плавать автоматически; но это вызывает инстинкт самосохранения, который заставляет их думать - как только это произойдет, они естественно будут думать о том, КАК и ПОЧЕМУ.

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

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

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

PS: просто случайно я разместил ответ здесь https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - и я получил всю побои; в первую очередь большинство людей считают, что предприятия не могут тратить ресурсы впустую! Я уверен, что этот ответ может получить подобное лечение здесь. Но правда в том, что заставлять людей работать и заставлять их верить в то, что они делают хорошую работу, является предметом человеческой психологии о том, как составить учебную программу курса.

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

Дипан Мехта
источник
спасибо за то, что вы подняли матрицу, теперь я должен потратить 2 часа своей жизни, чтобы посмотреть ее снова :) Забавно, но я обнаружил, что именно «освежители» поглощают все, что вы на них бросаете. Будучи выпускником прекрасной программы CS, я ясно даю понять, что я думаю об их «образовании», и в основном они согласны со мной. Я считаю, что самые большие проблемы - это парни, которые занимаются этим 10, 15, 20+ лет. Я также согласен с вашим подходом "испытание огнем". Именно так я узнал, что не нужно делать. Проблема в том, что а) требуется много времени, которое большинство команд не могут себе позволить, и б) при работе в команде ...
ДХМ
... обстановка (смею сказать "полу-проворная", не ненавидь меня, С. Лотт :)), у нас нет единоличного владения, которое требует пробная стрельба. Если они напишут что-то не полученное, кто-то вмешается и исправит это. Как человек, который был в пруду и в основном разбирался в этом, я хотел бы подумать, мне было любопытно, можно ли что-то сделать, чтобы перенести это мышление без того, чтобы вся ваша команда прошла через пруд.
ДХМ
@DXM Я согласен с твоими опасениями, что лучше не бросать всю команду в пруд сразу. Да. Дело в том, начните бросать некоторые из них один за другим тогда! По крайней мере, это хорошее соглашение между нами. Я думаю, что образ мышления, который вырос за многие годы, займет некоторое время и настойчивость, чтобы измениться.
Дипан Мехта
@DXM, чтобы дать вам более конкретные вещи - попробовать небольшие инициативы за один раз - показать наглядные примеры достижений и показать, что менеджмент означает бизнес для хорошей работы здесь. И продвигать мышление - шаг за шагом. настойчивость была бы необходимостью, но я достиг такого в моей последней компании. Со временем руководство продолжало давать моей команде пример того, как сделать это хорошо.
Дипан Мехта
1
Мне нравится ваш ответ, особенно если он работает для вас, поэтому ниже приведена не критика, а просто примечание: к сожалению, это работает не во всех случаях. У меня было несколько случаев, когда немотивированные разработчики начинали большие проекты. Каждый раз это заканчивалось одним и тем же: проект проваливался, и они обвиняли руководство или их коллег в том, что не было достаточно времени или ресурсов или что требования были недостаточно ясны. Интересно, в чем разница между теми, кто научится плавать, и теми, кто с большей вероятностью будет винить воду?
Арсений Мурзенко
2

Как вы указываете, его мотивация. Не путайте их, не заботясь о них, не зная. Они четко знают, что делать. Им просто все равно . Если это так, то реальный вопрос здесь ... что ваше руководство делает неправильно, что делает их такими немотивированными? Вы самый новый член команды? Возможно, они уже прошли через все это, и это только приводило к проблемам со стороны их руководства. Таким образом, они просто придерживаются самого низкого объема работы, необходимой для сохранения своей работы, потому что они не думают, что на выполнение большего труда ответит работодатель.

GrandmasterB
источник
Я являюсь руководителем команды и проработал в ней почти 9 лет, но лидировал примерно год назад. Я думаю, что есть разница между «не заботятся о работе или качестве моего кода» и «не заботятся о приобретении новых навыков». На самом деле мы сделали много улучшений в части управления, и многие из наших товарищей по команде теперь очень довольны. Тем не менее, некоторые довольны тем, что делают всегда. На самом деле они тратят дополнительные часы, даже не спрашивая, очень отзывчивые, но все еще кажутся довольными, отлаживая свои ошибки в 75% случаев.
ДХМ
1
Ну, тогда, как и в любой профессии, не все собираются быть на верхней половине кривой звонка. Возможно, у вас есть только некоторые люди для зарплаты.
GrandmasterB
Знаете, каждый год мы выбираем командную цитату, и 2011 год был «это то, что есть», но мы собираемся начать новый год, и, по крайней мере, на данный момент я откажусь признать, что это то, что есть, хотя я согласен с вами, что большую часть времени это действительно так. Я больше думал об этом вопросе и на самом деле у меня есть идея, которая может иметь потенциал. Поскольку я не могу ответить на свой собственный вопрос (личный вопрос, а не ограничения системы), если еще 2 человека проголосуют за повторное открытие programmers.stackexchange.com/questions/127080/… Я опубликую там :)
DXM
2

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

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

Я думаю, что есть две части этого - образование и методы работы.

  • Обучение можно начинать один раз в неделю - все едят вместе, вы проводите 20–30-минутную презентацию с вопросами и ответами. Вы начинаете с основ, которые вы хотите - SOLID может занять первые 2–4 недели - со временем вы заставите команду говорить по очереди, и вы сможете решить, кто решает, о чем говорить между вами. Дайте ораторам некоторое время на подготовку к работе. Кроме того, поощряйте посещение местных групп пользователей (сделав это, по крайней мере, частично социальным, если это возможно)
  • Практика работы ... ну, это зависит от того, что вы делаете сейчас и какие инструменты у вас есть, но вы, возможно, захотите взглянуть на согласованные стандарты кодирования, введение рецензирования кода (это верно), модульное тестирование (необязательно сначала тестировать) запуск сервера непрерывной интеграции и поиск более автоматизированного тестирования (в дополнение к модульным тестам). Но они должны быть введены с согласия / соглашения (а не сервера build / CI!), И вы должны стремиться продвигать качество как команда. Всегда есть вещи, которые можно улучшить (Кайдзен)

Также стоит посмотреть на Канбан (который рассматривается как движущая сила перемен / улучшений).

Еще одна мысль - я программист по профессиональному образованию, и я хотел бы, чтобы моя команда была такой же, но работать более 40 часов в неделю - это не очень хорошая вещь, поэтому нужно иметь команду, которая выполняет свою работу эффективно и хорошо в нормальной рабочей неделе и в отношении этого аргумента для улучшения рабочей практики является то , что более вероятно , например: добавление модульных тестов , чтобы продемонстрировать ошибочный случай , когда (до) ошибки фиксирование дает уверенность в том , что он являетсяисправлено; Наличие сервера сборки дает вам уверенность в том, что вы можете правильно строить свои решения - если эта сборка также генерирует пакеты развертывания, это означает, что развертывание значительно упрощается; Код SOLID по определению легче модифицировать; и по всем направлениям, чем меньше технических долгов вы берете на себя, тем меньше вам приходится расплачиваться ...

Murph
источник
0

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

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

Дэвид Пойнтер
источник
1
Я начал так же, хотя и не случайно. Это очень похоже на то, что сказал Дипан Мехта в своем посте. Вы бросаете человека в пруд, следите, чтобы он не был слишком глубоким, и позволяете ему плавать. Вы были одним из тех, кто научился плавать, но это не универсально (см. Его ответ с комментариями). Кроме того, я считаю, что этот тип подхода работает лучше для новых людей, чем те, которые уже имеют укоренившиеся привычки. Кроме того, им нужно не только плавать, но и против существующих устоявшихся практик.
ДХМ