Почему я выбираю парное программирование в удаленной команде

Привет. Я — Игорь, фулстек-разработчик с 11-ти летним опытом в IT, и я очень давно практикую парное программирование. Я уверен, что этот вид активности положительно влияет как на бизнес, так и на работу инженеров. Тем не менее, все еще встречаю скептиков, которые не верят в эффективность такой практики, не понимают как ее применять и уверены, что ее нельзя использовать в удаленной команде.

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

Что такое парное программирование

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

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

Преимущества парного программирования

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

Создание более качественного решения

Работая в паре, мы создаем решения лучшего качества:

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

Быстрый онбординг и обучение новых сотрудников

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

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

Коллективное владение кодом

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

И если кто-то покидает проект, не возникает так называемого «Bus factor», когда определенным контекстом владеет только один человек в команде.

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

Хороший инструмент для найма

При отборе кандидатов мы обычно проводим «full-day interview». В течение этого дня кандидат работает в паре с одним из наших инженеров над реальными задачами, комментирует и объясняет свою работу.

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

Полезный инструмент для удержания сотрудников

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

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

Более эффективная работа

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

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

Быстрый обмен знаниями и обучение

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

Недостатки парного программирования

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

Требует больше ресурсов на решение одной задачи

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

В одном исследование посчитали, что в паре разработчики тратят примерно на 15% больше времени, чем если бы задачу выполнял кто-то один. В то же время, Лори Уильямс и Роберта Кесслер, в их книге «Pair Programming Illuminated», утверждают, что пары создают более качественный код примерно вдвое быстрее, чем в одиночку.

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

Больший стресс и быстрая утомляемость

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

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

Порог вхождения

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

Как провести сессию в удаленной команде

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

  • Выберите инструменты. Перед сессией узнайте, какую среду разработки и другие инструменты использует ваш коллега в своей повседневной работе. Выберите то, что удобно использовать вам обоим. Перед сеансом настройте все программы и инструменты.
  • Найдите удобное для сессии время. Парное программирование — очень энергозатратная практика, поэтому важно выбрать правильное время для сессии. Если вы находитесь в одном часовом поясе, обсудите со своим коллегой, когда вы наиболее продуктивны в течение дня. Если коллега находится в другом часовом поясе, найдите совпадающее часы и выберите временной интервал, свободный от звонков.
  • Распланируйте работу заранее. Перед сеансом созвонитесь с коллегой и обсудите задачу. Убедитесь, что вы понимаете цель задачи одинаково. Разбейте работу на несколько этапов и расставьте приоритеты. Таким образом, вы создадите план действий и будете знать, с чего начать сеанс.
  • Разговаривайте во время сессии. Да, парное программирование может быть для вас в новинку. Однако вашему партнеру необходимо понимать ход ваших мыслей. Долгое молчание во время парного программирования признак того, что что-то идет не так.
  • Слушайте друг друга. Говорить недостаточно. Вам нужен диалог, поэтому прислушивайтесь к идеям и комментариям вашего партнера. Если вы не согласны со своим коллегой, сделайте паузу, чтобы обсудить это и принять решение сообща.
  • Будьте открытым. Поначалу сессии парного программирования могут показаться необычными и некомфортными. Но нужно помнить зачем вы это делаете и какая у вас цель. Вам нужно завоевать доверие друг друга, чтобы работать в синергии.
  • Будьте терпеливы. Ваш коллега может работать медленнее или быстрее вас. Если вам хочется перебить и/или поправить человека, используйте правило 5 секунд — подождите 5 секунд, если не передумали, можете комментировать.
  • Не стесняйтесь задавать много вопросов. Ваша задача понять идеи друг друга. Спросите, почему ваш коллега предложил тот или иной подход, чтобы вы могли применить его в дальнейшем при смене ролей.
  • Делайте перерывы. Писать код в паре сложно, поэтому делайте регулярные перерывы, чтобы отдохнуть. Я бы рекомендовал 50-минутное написание кода, 5-минутное обсуждение, а затем 5-10-минутный перерыв. Отдохните какое-то время или прервите сеанс, если вы понимаете, что не можете продуктивно работать дальше.
  • Не сдавайтесь, если парное программирование — новый опыт для вас. Работать в парах труднее, чем в одиночку, и естественно, что вы чувствуете себя вне зоны комфорта. Единственное правило здесь — не сдаваться, оставаться позитивным и открытым.
  • Не отвлекайтесь. Конечно, вы не можете гарантировать, что во время сеанса ваши мысли не потекут в другом направлении. В то же время вы можете свести к минимуму отвлекающие факторы, убедиться, что в вашем расписании нет предстоящих встреч, включить «режим не беспокоить» в мессенджерах на время сеанса и положить телефон куда-нибудь подальше.
  • Не занимайтесь рефакторингом или другими задачами во время перерывов. Перерывы нужны, чтобы помочь вам снять напряжение, отвлечься, и набраться энергии перед следующим раундом.
  • Не работайте в паре, если в этом нет необходимости. Есть много задач, которые лучше делать самостоятельно. Обычно это мелкие, рутинные, простые задачи.
  • Не работайте весь день в парах. По своему опыту могу сказать, что для инженеров, которые только начали заниматься парным программированием, 3-4 часового занятия в день более чем достаточно.

Инструменты для удаленных командах

Railsware — это удаленная команда с инженерами, живущими в 10+ разных странах. Тем не менее мы регулярно практикуем парное программирование и в значительной степени полагаемся на эту практику при приеме на работу, онбординге новых сотрудников, обучении и обмене знаниями.

Для сеансов парного программирования мы с ребятами опробовали разные инструменты и остановили свой выбор на:

  • Visual Studio Code с плагином Live Share. Эта комбинация инструментов для совместной работы, которая позволяет давать доступ к разным частям кода, но не ко всему репозиторию. Мы используем их во время «full-day interview» с кандидатами.
  • RubyMine с плагином Code With Me. Это стандартный выбор для сеанса удаленного парного программирования при условии, что обе стороны привыкли работать в RubyMine

Для демонстрации экрана мы в основном используем:

  • Slack call — это удобный инструмент, который позволяет выделять текст на демонстрируемом экране.
  • Zoom хорошо подойдет, если интернет соединение не очень надежное.

В качестве editor/IDE agnostic решения могу порекомендовать приложение Tuple.

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

Подведение итогов

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

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

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Пан Full stack наверно и аджайл любит.

Парне програмування — це якась практика рубістів?

Дайош gangbang sessions програмування паравозіком із буккаке-реквестом в кінці робочого дня!

Это не зависит от языка программирования.

То аналогічні дніпровським рубістам схильності є не лише в рубістів?

«Каждой твари по паре» :)))))))))))))

Pair programming це цікавий інструмент, але використовувати його щодня і для кожної задачі — фігня повна.

Коли ти створюєш щось, то щохвилини приймаєш якісь рішення, як змінну назвати, який метод використати, який контейнер, алгоритм, патерн і т.д. А коли ти в парі, то тобі всі ці рішення треба щохвилини треба пояснювати, тримати свого колегу в курсі інакше це перетворюється на те, що один пише код, а інший сидить з попкорном перед телевізором.
І фігня б з тим поясненням, але в колеги може бути інакша думка і тобі треба постійно дискутувати доводячи своє рішення.
З моєї практики, навіть година такої роботи виматує на весь день і вже після однієї такої високопродуктивної години я не можу нормально працювати решту дня.
А іноді ще й доводиться таким займатися з іноземним колегою, що змушує це все робити англійською, що ще більш втомлює.

Тому я можу порадити ПП в трьох випадках:
1. Онбординг, один показує і пояснює, інший слухає, та іноді задає запитання.
2. Треба зробити роботу в модулі у якому колега розбирається суттєво краще вас. Аналогічно, один показує інший мовчки слухає та іноді питає.
3. Код рев’ю. Хтось імплементнув складну чи просто неочевидну логіку, яку звичайним читанням коду не зрозумієш, принаймні відразу. В такому випадку є сенс зробити колл на всю команду чи декількох людей, показати і розповісти що де як чому і навіщо.

Для решти випадків цей підхід буде шкідливим, хіба тільки якщо ви не хочете аби робочий день ваших співробітників тривав 2-3 години, а решта саморефлексія, котики в інтернеті та релакс.

Треба зробити роботу в модулі у якому колега розбирається суттєво краще вас. Аналогічно, один показує інший мовчки слухає та іноді питає.

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

экзекуцию

подходящее определение для сабжа.

Про онбординг согласен
И что выматывает согласен.
Обсудить идею или проблему ок.
Сам код писать не ок.
Однирууи пишут.
Получается менторсво всякое

Часто бывает что один пишет код (локальное решение), а второй уже думает о более глобальных вещах, чтобы не уйти в сторону.
Но так что вдвоем приходим к лучшей абстракции, лучшей архитектуре тоже бывает.

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

А почему не Гэнг Бэнг программирование )))

Типа накидал код побыстренькому и передал следующему?

Працюємо так третій рік. Чудова штука. Дозволяє не надто переживати за свій програмістський іммідж, гординю, бо помилки роблять усі. Дозволяє не боятися їх робити, вчитися самому і вчити інших. Плюс продукувати якісніший код, звертати увагу на дрібні моменти, які легко проскакують мимо, коли працюєш наодинці.
Команда глибше знає проект вцілому, а не окремі частини. З віддаленою роботою люди реально коммунікують, жартують, банально знають один одного.
Можемо працювати в парі весь день, можемо зовсім окремо. Залежить від таски і настроїв в команді.
Мені здається, нарікати на такий вид роботи можуть ті, хто ніколи так не працював, або ті, в кого его трохи завелике 😁 Над цим варто працювати, це корисно 😉
Коли звик, робити помилки не стидаєшся і концентруєшся майже так само як наодинці.

Добавлю лише, що той хто не кодить, у нас рідко просто спостерігає. Ти активно паралельно щось інвестигейтиш, дебажиш, перевіряєш в іншій частині коду, допомагаєш, не просто угукаєш 😊

Поддерживаю. Затянувшееся молчание — это первый признак плохой работы в паре.

Тут один американський «супер» стартап догадався до ідеї в Україні наймати людей, щоб всі сиділи цілий день з включеними камерами та були в потоці)) Не хочете у себе таку модель прийняти? Це буде ще вищий рівень?)

P.S. А якщо серйозно, є код ревю і код все рівно мінімум дві людини перегляне, а якщо є проблеми, тоді можна зідзвонитись, нащо просто так один одного насилувати))

Парне програмування це ЧЖ, ЧЖЧ, ЖЧЖ, чи ЧЖЧЖ?

ЖЧЖ

тройничок.

ЧЖЧЖ

групповуха.

а да точно вспомнил групповуха это где все на одного где все на всех это уже оргия

терминология ))

Был ещё человек-оркестр Victor Chzhchzhdezhchnko, но он уже пополнил ряды anonymous.

парное программирование звучит, как два человека получают деньги, за то что может сделать один человек.

Три человека — третий погонщик скрам мастер

первый программист
второй программист
погонщик
скрум мастер

Погонщик нужен в любом случае, потому что бумажки нужно заполнять. Программирование и так рутинная дрянь, а тут ещё и бумажную работу бахнуть, и можно ехать в дурку.

Яке щастя, що ІТ велике і різних варіантів робочих процесів вистачає на всіх)

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

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

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

я интроверт и для меня идея парного программирования была очень привлекательна, только никто никогда не давал добро

Работал со многими интровертами. Получалось очень даже продуктивно.

У меня несколько раз получалось так: ищем причину бага, я шарю экран с кодом и логами, коллега тоже смотрит и высказывает свои предположения, я ищу — ничего не нашли (вдвоем)

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

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

Why?

Деньги любят тишину. Работа мозгами тоже.

Правда, за годы проведенные на проектах в «оупен-спейсах», я научился абстрагироваться от окружающего и втыкать в нужное без отвлечения на шумиху вокруг.
Но когда во время втыкания, кому-то нужно ещё и объяснять/с кем-то коммуницировать — это-таки уже другой левел (мне пока недоступый).

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

Одно дело — низкоинформативный фоновый шум, а другое дело — поток информации который обязательно нужно обработать.

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

в смысле

«ок инструмент не подходит но ни чего страшного давайте попробуем его для других задач и вообще придумаем такую задачу чтобы он подходил»

а на ок

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

1) A „watch the master” phenomenon may arise when an experienced and a novice programmer pair up. The novice member may become the observer with the experienced member completing most coding.
2) When two experienced users pair up, a „developer’s ego” phenomenon may arise, with each member trying to push his/her own ideas.
3) One of the pair may stop being actively engaged.

Ще греки в 1000 р до н.е.- 100 р. до н.е. шукали відповідь.
Грецька класика senior+junior, але в сучасному світі можливі 3! комбінацій.

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

1) обычно новичка ставят в пару к опытному инженеру в целях обучения. Хорошо бы чтобы кто-то из пары умел работать в паре и знал про этот феномен. Хорошо бы чтобы это был опытный инженер.

2) Эго-маньяки — это проблема. Это проблема не только для работы в паре, но и для работы всей команды.

3) Может. Это нормально. Нужно сделать перерыв, возможно, что-то поменять

а можно не страдать и работать самому.

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

смотреть+слушать+думать

ещё ж говорить надо

смотреть+слушать+думать+коммуницировать

Why?

некоторые когда думают над задачей бывает ещё и глаза закрывают — перекрывают зрительный канал.

глаза закрывают — перекрывают зрительный канал

це потужний прийом для абстрагування

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

А вы попробуйте еще попытаться кодить во время скучно митинга — у вас не получится! Можно читать ДОУ, можно троллировать, но вот кодить — не получится!
Мне кажется что в мозгу просто нехватает ядер на такую параллельность

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

ключевой момент
«в те же»

Это т.н. «эффект резинового утёнка», вы в курсе что это.
И к парному программированию отношения не имеет, кмк.

попри плюси, НАЙБІЛЬШИЙ мінус парного пограмування (для індивіда) в тому, що нема стану потоку.

Отличная практика, скучаю по ней. Кстати может ревью и не нужен для кода написанного в паре, по сути ревью проходит всё время во время написания кода.

Виталик, возвращайся :)

В одном исследование посчитали, что в паре разработчики тратят примерно на 15% больше времени, чем если бы задачу выполнял кто-то один.

Это справедливо, лишь для примитивного кода — который синьоры пишут, отключив мозг.

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

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

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

так что да, отличная практика — встал пораньше, поработал до обеда и допобачення евробачення, спаривайтесь без меня

Понятно, зачем парное программирование нужно «галерам» — синьоры обучают себе конкурентов, вместо того чтобы заниматься любимым делом (писать код).

Но зачем этот киндергартен самим синьорам?

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

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

Как правило, над серьёзными задачами сотрудничают эксперт предметной области (имеющий малое отношение к коденью и изъясняющийся словарём предметной области) + эксперт коденья, который должен это реализовать (или наделать из этого тасков, для реализации командой).

Общение этих экспертов — вещь необходиная. Но это не парное программирование.

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

двух экспертов «коденья»

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

хотя бы из двух достаточно больших частей,

Если мы говорим про действительно большие части — то качественная реализация требует качественного понимания доменной области, которая у второго партнера скорее всего отсутсвует (мы же говорим о больших частях?). Сам-то по себе кейс вполне валидный, но в случае той же интеграции абсолютно неэффективный, так как эта работа которая легко распараллеливается.
Совместная активность для описания контрактов, которые будут использоваться при интеграции закрывает 90% вопросов, смысл потом имплементировать совместно последовательно за x2 времени от меня ускользает

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

Вопрос очень простой: «нафига синьорам вместо коденья — работать нянькой и обучать конкурентов»?

Если современное поколение айтишников тебе в принципе может составить конкуренцию, то проблема вероятно в тебе.

Если чел глуп, с таким парное программирование обучение проводить — тем более зряшная трата времени.

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

Обучать других это третий этап твоего обучения

Эка тебе галероводы мозги промыли. Скоро написанием для них оупен-соурса забесплатно займёшься — как четвёртым этапом своего обучения. :)

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

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

Это ведь не проблемы профессионалов. У профессионалов уже есть всё, что им нужно.

Если универы хотят привлечь профессионалов к преподаванию — хорошо бы создать условия. А пока что, в универах (даже западных) вместо условий — 1) оплата ниже уровня заработка коденьем 2) невозможность ставить объективные оценки.
Какому профессионалу такое преподавание будет интересно?

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

Зачем мне как лектору студенты, отбывающие номер? Чтение лекций таким — это напрасная трата времени.

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

Я был бы не против обучать сотрудников в своём стартапе (невзирая на то, что они могут уйти, вместe с полученными знаниями). Но обучать работая «на дядю», вместо того чтобы педалить код? Если бы мне так хотелось обучать, пошёл бы в преподаватели.

П.С. Опять-таки, если уж преподавать софто-разработческие дисциплины — это имеет смысл делать исключительно на английском языке. Но что-то сомневаюсь, что в той же Украине универы в таком могут быть заинтересованы.

Для обучения есть университеты, там куча факультативов + собственные мозги + все в онлайн
Этого более чем достаточно. Если недостаточно — нянька не поможет

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

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

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

с опытными людьми уровня мидл и выше.

В системе отсчета «синьор украины» или «синьор эльфии»?

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

В стране создавшей мем про 17-летнего архитектора и 23-летнего сеньора? Really?

...ну або з проходняковими чуваками та вайтішниками, які не гидують витрачати час на yet another аутсорсера, чий СЕО особисто вважає тестові чи не єдиним можливим методом відбору кандидатів.

Я це до чого. Щоб високопарний буллщіт про

решение самых сложных проблем
я имею дело с опытными людьми уровня мидл и выше

тощо, ліпше лягав на вуха оточуючих, місце роботи, як на мене, краще було б приховати. Звісно, якщо це не чергова стаття по рознарядці, накшталт попередніх сумнівних креативів, завдячуючи яким, галєру хоч хтось впізнає ))

как вы отличаете мидлов от не мидлов?

Кто из джунов громче крикнул то что он мидл, тот и мидл, сеньйором также становятся.

На самом деле градация синьор-джуниор очень упрощенная и нам не подходит. Ей пользуются многие, поэтому я ее упомянул.
Как вы уже прочли выше, мы проводим «full day interview». Это всегда работа в паре. По результатам работы мы оцениваем ряд технических и не технических навыков. В конечном итоге получаем оценки. Это объективная (в рамках компании) формализованная оценка.
Исходя из субъективных ощущений те люди, которые проходят имеют уровень начиная от мидл.

Підписатись на коментарі