Comments 38
И все же мне не совсем понятно, как это организовать в моем очень частном случае.
Большую часть времени я сижу на диване, хожу по комнате, выхожу гулять. Так было и в офисе: я сидел на бескаркасных пуфах, гулял по офису, выходил подышать воздухом. Иногда я мог подойти к доске и начать что-то писать. Конечно, может показаться, что я всячески избегал работы, но на деле мне так легче думается. Результат это всегда подтверждал. Только вот запись результата занимала 1-2 часа. Иногда это время было разбито между описанными активностями.
Не знаю, как у других, но вот уже 6 лет я работаю именно так. Потому хотелось бы спросить у автора: есть ли возможность как-то в этом случае начать практиковать ПП?
Также, хотелось бы спросить у хабровчан: как долго вы сидите перед компом? Как вам лучше думается?
Большую часть времени я сижу на диване, хожу по комнате, выхожу гулять. Так было и в офисе: я сидел на бескаркасных пуфах, гулял по офису, выходил подышать воздухом. Иногда я мог подойти к доске и начать что-то писать. Конечно, может показаться, что я всячески избегал работы, но на деле мне так легче думается. Результат это всегда подтверждал. Только вот запись результата занимала 1-2 часа. Иногда это время было разбито между описанными активностями.
Не знаю, как у других, но вот уже 6 лет я работаю именно так. Потому хотелось бы спросить у автора: есть ли возможность как-то в этом случае начать практиковать ПП?
Также, хотелось бы спросить у хабровчан: как долго вы сидите перед компом? Как вам лучше думается?
Я, к сожалению, не смогу дать точного совета, как тебе поступить.
Но я хотел бы напомнить, что ПП это не только непосредственное написание кода. Это инструмент, который можно использовать на разных задачах. И я думаю, что ты мог бы это попробовать стоять у доски (рисуя новую архитектуру, или алгоритм, или что-то еще) с кем-то в паре. И придумывать вместе. Это как вариант.
Еще в предыдущей статье я рассказывал как ПП помогает в процессах шаринга знаний, обучения коллег и уменьшения «башен знаний».
Ну и даже при таком подходе к работе как у тебя, ты мог бы попробовать раз в спринт, например, на 1 час сесть с кем-то в паре и написать код. Можно сколько угодно говорить о ПП. Ругать. Хвалить. Но пока сам несколько раз не попробуешь, ты не поймешь что и как именно тебе подходит.
Ну и не стоит забывать, что я не утверждаю, что ПП подходит всем.
Но я хотел бы напомнить, что ПП это не только непосредственное написание кода. Это инструмент, который можно использовать на разных задачах. И я думаю, что ты мог бы это попробовать стоять у доски (рисуя новую архитектуру, или алгоритм, или что-то еще) с кем-то в паре. И придумывать вместе. Это как вариант.
Еще в предыдущей статье я рассказывал как ПП помогает в процессах шаринга знаний, обучения коллег и уменьшения «башен знаний».
Ну и даже при таком подходе к работе как у тебя, ты мог бы попробовать раз в спринт, например, на 1 час сесть с кем-то в паре и написать код. Можно сколько угодно говорить о ПП. Ругать. Хвалить. Но пока сам несколько раз не попробуешь, ты не поймешь что и как именно тебе подходит.
Ну и не стоит забывать, что я не утверждаю, что ПП подходит всем.
не нужно заставлять людей практиковать парное программирование, они должны прийти к этому самостоятельно
Не нужно внедрять сверху парное программирование, те программисты, которым это подходит и которые полагают для себя этот метод не просто приемлемым, но желательным и эффективным, должны прийти к этому самостоятельно.
Тоже попробовали «Code with me», удобная вещь, хоть и не без неприятных моментов вроде того, что у кого то может синхронизация накрыться и новые файлы не появляются (спасает переподключение). Решение на
Если кто-то еще сможет посоветовать что-то удобное для совместной работы по SSH, вроде Team Shell (их сайт увы более не доступен, даже не успел опробовать), то буду признателен.
Если кто-то еще сможет посоветовать что-то удобное для совместной работы по SSH, вроде Team Shell (их сайт увы более не доступен, даже не успел опробовать), то буду признателен.
Когда я был школьником у меня не было компа, и я ходил к другу у которого был. У нас были парные компьютерные игры. Он играл, а я сидел и смотрел, как он играет. Теперь мы выросли. Занимаемся парным программированием. Он кодит, а я всё так же смотрю, как он кодит :)
Lol, это парное программирование на моей памяти еще пытаются использовать еще с начала 2000-х, но так оно и не пошло в массы. А для уровня выше мидла так и вообще оно вредно. А мидлу и ниже куда полезнее кодить в одиночку, так быстрее у него идет прогресс. Опытный и дружелюбный наставник сделает прогресс еще более эффективным.
Да, вроде как одно их первых упоминаний про парное программирование было в книге Кента Бека «Экстремальное программирование» в 1999 году. Хотя я не готов утверждать, что это было прям первое описание этого инструмента.
Что же касается твоего утверждения, что ПП вредит программистам «выше мидла», то я тут не могу с тобой согласиться. Свои доводы, в чем я вижу плюсы этого инструмента, где я это использую, я написал в предыдущей статье (вначале этой статьи есть ссылка). Это мой опыт, мои наблюдения и выводы.
Но я бы с радостью послушал бы и твои доводы, где и как это может вредить. Возможно, я пересмотрю свои взгляды.
По поводу, что это не пошло в массы. Тут я скорее соглашусь. Это не используют поголовно все. Но есть очень-очень много компаний где практикуют ПП в том или ином объеме.. И в России и за рубежом.
Что же касается твоего утверждения, что ПП вредит программистам «выше мидла», то я тут не могу с тобой согласиться. Свои доводы, в чем я вижу плюсы этого инструмента, где я это использую, я написал в предыдущей статье (вначале этой статьи есть ссылка). Это мой опыт, мои наблюдения и выводы.
Но я бы с радостью послушал бы и твои доводы, где и как это может вредить. Возможно, я пересмотрю свои взгляды.
По поводу, что это не пошло в массы. Тут я скорее соглашусь. Это не используют поголовно все. Но есть очень-очень много компаний где практикуют ПП в том или ином объеме.. И в России и за рубежом.
UFO just landed and posted this here
Кто-то будет сидеть рядом со мной за моим компом, юзать мою мышку и клаву, влезать, отвлекать, не давать самому отвлекаться…
Парное программирование не есть работа двух и более программистов за одной машиной.
Хотя я работаю удаленно, но все равно еще и зум постоянно запущенным держать, да еще какую-то штуку типа гугл доков, чтобы код набирать, контакт поддерживать… Вообще терпеть не могу, когда за мной кто-то наблюдает.
Постоянно подключенным нужно держать только на время парной работы. Никто же не обязывает всё время вместе работать. Можно разделить время совместного обсуждения/кодинга/поиска багов и т.п.
Как хоть что-то понять
А как потом проводить perf review и как решать кого промоутить?
Ну тут просто — одну зарплату делим на двоих (её и повышаем)
1. Люди не сидят в паре весь спринт. И не делают все задачи в парах. Увидеть их индивидуальные способности не составит труда, имхо.
2. Работа и перформанс команды в целом — не менее важно (а чаще и больше), чем работа отдельного человека
3. Если человек еще берет на себя работу по обучению коллег в паре и делится знаниями (хардовыми или бизнесовыми), то это, на мой взгляд, только плюс человеку при вопросе о промоуте.
2. Работа и перформанс команды в целом — не менее важно (а чаще и больше), чем работа отдельного человека
3. Если человек еще берет на себя работу по обучению коллег в паре и делится знаниями (хардовыми или бизнесовыми), то это, на мой взгляд, только плюс человеку при вопросе о промоуте.
Хороший замысел. Я бы посоветовал для парной работы определить общую цель. Например можете придумать создать вместе какого-то бота для социальной сети. Как говорят «в интернете есть вся инфа», а то, чего нету, то подскажут на форумах. И ведомые одной целью вы будете идти по одному неразрывному пути, помогая друг другу осваивать программирование
любимый стиль ;)
хинт: главное для штурмана — удобный диван!)
Обычное код ревью чем хуже?
Лучше асинхронностью и тем что никто не стоит над душой.
Лучше асинхронностью и тем что никто не стоит над душой.
Ну, в обычном ревью сложнее пойти дальше синтаксиса, паттернов и верхнеуровневой архитектуры, это как пытаться прочесть книгу за час. В ПП вы, скорее всего, будете в контексте происходящего.
Оно не лучше и не хуже. Это просто совсем другое.
В предыдущей статье я рассказывал, как я вижу, какие задачи помогает решить ПП. Там есть разные кейсы по составу пар и по целям, которые могут быть достигнуты в ПП.
Если очень коротко, то, во-перых, скорость — не главный показатель. Иногда мы осознано жертвуем скоростью для других «плюсов». Так как ПП это далеко не всегда про скорость.
Во вторых, иногда придумать «что и как» написать занимает больше времени, чем само написание кода. И в паре порой решить сложную задачу получается быстрее.
В предыдущей статье я рассказывал, как я вижу, какие задачи помогает решить ПП. Там есть разные кейсы по составу пар и по целям, которые могут быть достигнуты в ПП.
Если очень коротко, то, во-перых, скорость — не главный показатель. Иногда мы осознано жертвуем скоростью для других «плюсов». Так как ПП это далеко не всегда про скорость.
Во вторых, иногда придумать «что и как» написать занимает больше времени, чем само написание кода. И в паре порой решить сложную задачу получается быстрее.
Мне странно, что так много негатива к парному программированию. Наверное, если на галере закрывать однообразные тикеты по пачке в день, то это не эффективно. Если задача сложная, то начинается игра в пинг-понг от стендапа к стендапу (ну, по моему опыту). И в итоге решение меняется и переменяется проходя через кучу рук и ревью. А можно двум-трём людям сесть и посмотреть на задачу вместе и подумать глубоко.
У меня так существенная часть кодинга проходит. Пару часов думаем вместе. Потом можем развалиться на подзадачи (или даже альтернативные подходы попробовать) и собираемся назад. Так получается найти взвешенное решение за приемлемое время. Ну и есть облучательный бонус для новичков.
У меня так существенная часть кодинга проходит. Пару часов думаем вместе. Потом можем развалиться на подзадачи (или даже альтернативные подходы попробовать) и собираемся назад. Так получается найти взвешенное решение за приемлемое время. Ну и есть облучательный бонус для новичков.
Мне странно, что так много негатива к парному программированию
Вроде очевидно же — неудачный личный опыт, особенно если этот способ вводили из под палки.
Против "сидим в паре, навигируем по коду и обсуждаем" ничего не имею, но на моей памяти это "парным программированием" и не называют. Полноценным "парным программированием" же, как мне казалось, считается ситуация написания большей части кода сидя в паре.
Ну это некий спектр. Прям весь код писать в паре, наверное, замаешься. Но половину можно. Просто навигировать, мне думается, может быть слишко поверхностно.
Я согласен, что люди должны сойтись и уметь нужно и не каждую задачу так логично делать. Так что из под палки будет как обычно плохо.
Еще, конечно, я забыл сказать, что я в Азии. Тут немного другой культурный код.
UFO just landed and posted this here
Не готов говорить за всех. И какой-то статистики у меня нет.
Но по моим наблюдениям все как раз наоборот. Так как есть еще некий момент поддержки и мотивации друг друга.
Встречал случаи, когда человек в «одиночку» сидел со «своей задачей». И видно было, что у него чуть ли на апатия к ней… Но когда он сел в пару, сделали ее буквально за пару часов.
Тут, конечно, все индивидуально сильно.
Но на мой взгляд, что ПП наоборот часто помогает не выгореть.
Но по моим наблюдениям все как раз наоборот. Так как есть еще некий момент поддержки и мотивации друг друга.
Встречал случаи, когда человек в «одиночку» сидел со «своей задачей». И видно было, что у него чуть ли на апатия к ней… Но когда он сел в пару, сделали ее буквально за пару часов.
Тут, конечно, все индивидуально сильно.
Но на мой взгляд, что ПП наоборот часто помогает не выгореть.
Огромное спасибо за статью! Я для своих студентов иногда практикую парное программирование. Кое-что для себя почерпнул новое.
Спасибо за добрые слова. Могу предложить прочитать предыдущую мою статью о плюсах парного программирования. И мою статью про новичков. Возможно, тоже что-нибудь интересное для себя найдете. Ну или наоборот, напишете с чем и почему вы не согласны, что бы я посмотрел на эти вопросы и с другой стороны.
Могу написать по своему опыту (мелкие и крупные компании, в которых я работал/работаю).
Вообще, когда речь заходит о любых совместных, да еще и длительных, действиях, то вперед выдвигается совместимость людей, психология, социология, и т.д., а умение программировать уходит на задний план. Программисты часто бывают интроверты и им психологически тяжело выполнять совместную работу на регулярной основе.
Поэтому есть риск скатиться в ситуацию, когда кто-то один пишет одну часть, а второй другую (относительно независимую) или вообще думает о чем-то другом пока компьютер занят первым, хотя на бумаге они работают в паре — людям проще самим «поделить» задачу внутри и начать пересекаться очень слабо. Особенно опять же актуально для интровертов, которые не любят пускать посторонних в интимный процесс раздумий и попыток написания кода.
Что еще? По опыту ревью (да и аудит) кода надо делать независимо, а не параллельно в паре. В паре люди проникаются общей идеей и начинают не замечать ее недочеты, и чем дальше, тем больше. Переубедить может только независимый взгляд на код человека, который желательно вообще его не писал до этого. Так что для ревью это почти никак не экономит время, а синтаксические и стилистические ошибки проще ловить разными утилитами, а не глазами людей.
Про модный «онбординг» — грамотного специалиста надо учить архитектуре, основам и умению думать самостоятельно. В паре можно поработать недолго в самом начале. Иначе есть риск получить человека, который только в паре и будет способен что-то делать, а самостоятельно — не очень, потому что будет ждать совета от коллеги в паре.
Шаринг кода/процессов/знаний и т.д. все же лучше формализовывать в виде хотя бы статей на внутренней вики или чем-то подобном. Во-первых, это удобнее: можно сослаться на документ, а не объяснять что-то каждый раз. Во-вторых, в этом случае новые знания охватывают сразу всех, а не только двух в паре и обсуждать на вики можно именно их, не отвлекаясь на код. А если появилось что-то действительно важное — лучше периодически устраивать внутренние «конференции» и обсуждения проблем и новых практик в коде во всей команде.
Что касается сплочения коллектива — опять же спорно, что парные практики так уж сплачивают его. Люди все очень разные, если часть людей будет работать в паре, а часть категорически нет — значит ли это что сплачиваться будет только часть коллектива? По моему опыту хорошо сплачивает коллектив периодические встречи (строго добровольные!) вне рабочей тематики и регулярный мониторинг настроений и возможностей коллектива и подстройка планов под эти настроения. Люди ценят, когда о них заботятся, и еще более ценят, когда эта забота пусть и скромная, но зато регулярная.
Собственно, из-за вышеуказанного, я нигде особо не видел хорошо работающих парных практик. Периодически, те, кому удобно и легко и сами могут образовывать пары для решения задач совместно — это же не запрещается, но массово это похоже не работает.
Вообще, когда речь заходит о любых совместных, да еще и длительных, действиях, то вперед выдвигается совместимость людей, психология, социология, и т.д., а умение программировать уходит на задний план. Программисты часто бывают интроверты и им психологически тяжело выполнять совместную работу на регулярной основе.
Поэтому есть риск скатиться в ситуацию, когда кто-то один пишет одну часть, а второй другую (относительно независимую) или вообще думает о чем-то другом пока компьютер занят первым, хотя на бумаге они работают в паре — людям проще самим «поделить» задачу внутри и начать пересекаться очень слабо. Особенно опять же актуально для интровертов, которые не любят пускать посторонних в интимный процесс раздумий и попыток написания кода.
Что еще? По опыту ревью (да и аудит) кода надо делать независимо, а не параллельно в паре. В паре люди проникаются общей идеей и начинают не замечать ее недочеты, и чем дальше, тем больше. Переубедить может только независимый взгляд на код человека, который желательно вообще его не писал до этого. Так что для ревью это почти никак не экономит время, а синтаксические и стилистические ошибки проще ловить разными утилитами, а не глазами людей.
Про модный «онбординг» — грамотного специалиста надо учить архитектуре, основам и умению думать самостоятельно. В паре можно поработать недолго в самом начале. Иначе есть риск получить человека, который только в паре и будет способен что-то делать, а самостоятельно — не очень, потому что будет ждать совета от коллеги в паре.
Шаринг кода/процессов/знаний и т.д. все же лучше формализовывать в виде хотя бы статей на внутренней вики или чем-то подобном. Во-первых, это удобнее: можно сослаться на документ, а не объяснять что-то каждый раз. Во-вторых, в этом случае новые знания охватывают сразу всех, а не только двух в паре и обсуждать на вики можно именно их, не отвлекаясь на код. А если появилось что-то действительно важное — лучше периодически устраивать внутренние «конференции» и обсуждения проблем и новых практик в коде во всей команде.
Что касается сплочения коллектива — опять же спорно, что парные практики так уж сплачивают его. Люди все очень разные, если часть людей будет работать в паре, а часть категорически нет — значит ли это что сплачиваться будет только часть коллектива? По моему опыту хорошо сплачивает коллектив периодические встречи (строго добровольные!) вне рабочей тематики и регулярный мониторинг настроений и возможностей коллектива и подстройка планов под эти настроения. Люди ценят, когда о них заботятся, и еще более ценят, когда эта забота пусть и скромная, но зато регулярная.
Собственно, из-за вышеуказанного, я нигде особо не видел хорошо работающих парных практик. Периодически, те, кому удобно и легко и сами могут образовывать пары для решения задач совместно — это же не запрещается, но массово это похоже не работает.
Спасибо за комментарий. Я хотел бы напомнить, что все выше написанное — это мой опыт и мои наблюдения, которыми я хотел поделиться. То что действительно у нас работало и помогало.
Пару слов про твой комментарий:
Без условно ты прав. Именно поэтому я в статье и писал, что людей в пару надо подбирать, а не сажать случайных. Что нельзя навязывать ПП. И что вначале надо делать маленькие по времени сессии парного программирования.
Я не в коем случаи не говорю что надо отменить ревью. Но при написание кода в паре они могут замечать и отлавливать какие-то ошибки. Подсказывать более оптимальный подход или паттерн. Делиться «на лету» своим опытом.
Я согласен. Документация нужна. Но одно второго не отменяет. И давай будет честны. Во всех ли компаниях где ты работал, была идеальная и полная документация по всем приложениям и процессам?
Нет. Не значит. Я всего лишь сказал, что ПП часто обладает «дополнительным» эфектом по сплочению. Конечно при условии, что это не навязывают сверху, а люди сами хотят.
Совместные Тимбилдинги, походы в бар, поедания пиццы, и просто разговор по душам или помощь никто не отменял. Это всегда будет на первом месте для сплочения людей и командообразования
Пару слов про твой комментарий:
вперед выдвигается совместимость людей, психология, социология, и т.д., а умение программировать уходит на задний план. Программисты часто бывают интроверты и им психологически тяжело выполнять совместную работу на регулярной основе.
Без условно ты прав. Именно поэтому я в статье и писал, что людей в пару надо подбирать, а не сажать случайных. Что нельзя навязывать ПП. И что вначале надо делать маленькие по времени сессии парного программирования.
В паре люди проникаются общей идеей и начинают не замечать ее недочеты,
Я не в коем случаи не говорю что надо отменить ревью. Но при написание кода в паре они могут замечать и отлавливать какие-то ошибки. Подсказывать более оптимальный подход или паттерн. Делиться «на лету» своим опытом.
Шаринг кода/процессов/знаний и т.д. все же лучше формализовывать в виде хотя бы статей на внутренней вики или чем-то подобном.
Я согласен. Документация нужна. Но одно второго не отменяет. И давай будет честны. Во всех ли компаниях где ты работал, была идеальная и полная документация по всем приложениям и процессам?
Люди все очень разные, если часть людей будет работать в паре, а часть категорически нет — значит ли это что сплачиваться будет только часть коллектива?
Нет. Не значит. Я всего лишь сказал, что ПП часто обладает «дополнительным» эфектом по сплочению. Конечно при условии, что это не навязывают сверху, а люди сами хотят.
Совместные Тимбилдинги, походы в бар, поедания пиццы, и просто разговор по душам или помощь никто не отменял. Это всегда будет на первом месте для сплочения людей и командообразования
людей в пару надо подбирать, а не сажать случайных. Что нельзя навязывать ПП. И что вначале надо делать маленькие по времени сессии парного программирования.
Это конечно так, но кто и как будет подбирать людей в пары? Только метод проб и ошибок? Слишком много факторов — строить матрицу совместимости людей? И что делать в коллективе матерых интровертов, которых от ежедневных встреч-то тошнит? Нужна мотивация для людей, а не только для тимлида.
Документация нужна. Но одно второго не отменяет. И давай будет честны. Во всех ли компаниях где ты работал, была идеальная и полная документация
Если уж совсем честно, я нигде не видел ничего идеального. ПП тоже не идеально, и уж тем более независимо от его наличия нужна и документация и ревью и все остальное — поэтому это первично, а ПП — вторично. Может конечно есть какой-то эффект от парного ревью или парного написания документации, но я не уверен.
Я всего лишь сказал, что ПП часто обладает «дополнительным» эфектом по сплочению. Конечно при условии, что это не навязывают сверху, а люди сами хотят.
Если ПП практикует только часть (и тем более не самая большая) коллектива, то это вряд ли станет дополнительным фактором сплочения. Это примерно как сказать, что курение сплачивает коллектив, потому что в курилке народ что-то дополнительно обсуждает, даже если большая часть не курит и курить никто не заставляет. Однако ж курение никто так не рекламирует для увеличения эффективности программистов :)
Спасибо за интересную статью. У нас тоже используется Zoom, но у него не очень удобное управление чужим рабочим -скорость работы за чужим компьютером зависит от скорости канала у обоих участников, а если это еще и какой-нибудь VPN+RDP, то всё становится совсем плохо.
У меня первый опыт парного программирования был еще в студенческие годы (начало 90х).
Мы с другом устроились в «контору» где и компьютеров то было очень мало: днем там работали «крутые» и бухгалтера, а вечером обычно оставался один-два программиста (слова разработчик тогда еще не было), мы с другом и еще один такой же студент. Опыта программирования вообще у нас всех на тот момент было очень мало.
У нас был один комп на двоих и мы писали программу по очереди. Вначале мы не очень эффективно работали: мой друг выдавал огромное количество кода и потом править, а я предпочитал писать короткий код который обдумывал и только потом писал.
Но мы научились это использовать: пока мой друг писал код я придумывал алгоритмы и мы параллельно обсуждали что можно сделать лучше с точки зрения кода и скорости. Тогда в «конторе» был только один 386й и то у директора, который тоже программировал и «да» :) — это был в начале DOS и чуть позже Windows 2.0-3.11 и OS/2.
Это я к тому, что даже с разными темпераментами можно работать в паре, но главное чтобы у людей не было отторжения друг от друга и сажать можно вместе не только людей с разным уровнем, но и с разным «темпераментом разработки» — это тоже помогает показать людям разные подходы и они обязательно что-то позаимствуют друг от друга.
Может мой опыт и был исключением, но надеюсь, что кто-то сможет собрать пару такого же типа в своих командах.
У меня первый опыт парного программирования был еще в студенческие годы (начало 90х).
Мы с другом устроились в «контору» где и компьютеров то было очень мало: днем там работали «крутые» и бухгалтера, а вечером обычно оставался один-два программиста (слова разработчик тогда еще не было), мы с другом и еще один такой же студент. Опыта программирования вообще у нас всех на тот момент было очень мало.
У нас был один комп на двоих и мы писали программу по очереди. Вначале мы не очень эффективно работали: мой друг выдавал огромное количество кода и потом править, а я предпочитал писать короткий код который обдумывал и только потом писал.
Но мы научились это использовать: пока мой друг писал код я придумывал алгоритмы и мы параллельно обсуждали что можно сделать лучше с точки зрения кода и скорости. Тогда в «конторе» был только один 386й и то у директора, который тоже программировал и «да» :) — это был в начале DOS и чуть позже Windows 2.0-3.11 и OS/2.
Это я к тому, что даже с разными темпераментами можно работать в паре, но главное чтобы у людей не было отторжения друг от друга и сажать можно вместе не только людей с разным уровнем, но и с разным «темпераментом разработки» — это тоже помогает показать людям разные подходы и они обязательно что-то позаимствуют друг от друга.
Может мой опыт и был исключением, но надеюсь, что кто-то сможет собрать пару такого же типа в своих командах.
Мы применяли парную работу неформально еще в первой половине 80-х.
Обычно возникала потребность у младшего программера разобраться в том, что он наваял.
Тогда старший садился рядом, анализировал вслух код и тут же рефакторил его, по ходу дела объясняя младшему, почему делать надо именно так.
Реально получалось хорошо.
Обычно возникала потребность у младшего программера разобраться в том, что он наваял.
Тогда старший садился рядом, анализировал вслух код и тут же рефакторил его, по ходу дела объясняя младшему, почему делать надо именно так.
Реально получалось хорошо.
Sign up to leave a comment.
Как начать программировать в парах