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

но это уже больше обучение

Ну, да

А там именно они меняются местами

Один педалит, проговаривая свои действия, другой фиксит, идя за ним следом, проговаривая свои действия

Боюсь, что это морально сложно

мой коллега не выдерживает, когда я к нему подхожу и указываю на ошибки

Потом меняются, типа

но я придираюсь к подходу

специально конечно же

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

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

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

требуется в 2 раза больше человекочасов на одну и ту же работу

ну вообще не в 2 раза, если надо что-то задизайнить то можно засейвить много времени

но это не парное программирование же

Ну хоткеи это такое, конечно, мб ему не удобно

А еще разные используют разные фичи и дополнения иде

(я его специально достаю)

Тут уже дело каждого

А, понял, хд

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

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

даешь ссылки на видосы в студию

Ну, не знаю, т.е. определенно кто-то должен лучше понимать задачу, так?

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

такое может быть актуально при проектировании

даешь ссылки на видосы в студию

https://youtu.be/h8wRC7Qkcb8

когда проест с нуля поднимается и создается оболочка

Т.е. должны знать на уровне или как?

типа разработка интерфейсов и т.д.

Вот, как у меня, хд

Т.е. должны знать на уровне или как?

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

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

Уф, тогда сложно сложно найти единомышленика с одинаковым уровнем

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

Да нет, лучше наоборот. Тогда рили можно лучшее решение выбрать.

ну тогда можно собраться и обсудить

Да я тут смотрел с конфы доклад о парном опыте программирования у варгейминга

Подумал:"прикольная идея, можно было бы попробовать"

для принятия концептуальных решений не нужно весь день писать код

Вообще можно утонуть в обсуждении хуйни неважной.

Почему не важная?

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

Ребят, всем привет

привет

Привет привет

Почему не важная?

А ты определи где важная, а где нет.

Да, определил, а что?

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

Но так же можно подойти к задаче с разных сторон

Главное амбиции в сторону

Я к тому что по опыту обычно всякие мелочи неважные обсуждают.

И постоянно приходится останавливать.

А какая мелочь важная?

Дьявол в мелочах

Или дьявол кроется в деталях

Но так же можно подойти к задаче с разных сторон

в большинстве случаев увы, но нет

С /vg/ ОРУ

Ага, это как я рассказывал историю, меня крёстный запалил что я играю в синглс где есть секс, только вот он не смог подтвердить свои подозрения так как не смог склеить там тёлку

А какая мелочь важная?

В том и проблема. Обычно никакая.

Т.е. взял проект, ать-два и в продакшн

угу

Нет, не спорить про то как называть классы валидаторов по 2 часа.

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

Понял Арсения мнение

и то даже здесь просто поручаешь каждому отвечать за свою часть в проекте и всё

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

Есть код конвеншн и есть придерживаются. Дальше все вопросы во время код ревью.

ERROR: S client not available

Его придерживаются, конечно же.

Почему не обсуждать это заранее?

Что именно ты предлагаешь обсуждать заранее?

Но вот по поводу пп какой-то спорный вопрос

Мелочи/детали проекта

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

Да я не то чтобы предлагаю, просто рассуждаю вслух

У меня живой пример проекта есть где человек решил всё обсудить заранее и сделать схему СУБД финальную. 

Как думаешь через сколько времени после того как он это сделал потребовались изменения в схеме?

Ну, это глупо, тут очевидно

Я имею ввиду изначальную модель

Python Инвайт: telegram.me/ru_python Решаем ёлочку: adventofcode.com Наш лидерборд 71287-b2f24264 https://telegram.me/ru_python

Кто тут искал конфу

С пайтоном

Что ты имеешь в виду под изначальной моделью?

Её детали, использование технологий, проектирование

define детали

Кто тут искал конфу

Я, спасибо

Хотя бы разбитая на части первая версия проекта

Нет?

Ну это не детали, это архитектура наоборот.

Охайо Tema Rizhenkov! Прочитайте правила конференции в описании.

Ну, вот, у меня такое же мнение, как на пикче

Вау, не поверишь

у меня тоже

к чему бы это?

В общем, ты меня извини, если я задаю глупые вопросы и глупо рассуждаю

Нашёл за что извиняться.

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

Лучше задавать глупые вопросы, чем не задавать. Отвечаю.

а еще лучше делать костыли, наступать на грабли