Здравствуйте, Codealot, Вы писали:
C>Мне это и не нужно. Ты утверждаешь, что так во всех компаниях — тебе и доказывать. C>Логику не учил?
Чем кумушек считать трудиться,
Не лучше ль на себя, кума, оборотиться?
B>>В больших компаниях релизами занимаются релиз инженеры C>Я точно знаю, что это не так.
Здравствуйте, sergey2b, Вы писали:
S>обычно так делают перед уволенниями S>что бы не было незаменимых людей
Не факт — возможно тупо копируют неэффективные европейские подходы. В моей конторе — БМВ, это обычное дело. Почти все инженеры должны кодить минимум на 3х языках — плюсы, джава и пайтон, работая с эмбеддед, десктоп, облаками и иногда с вебом и еще с некоторыми девопс фичами и самостоятельно тестируя. Жутко неэффективно — раз этак в 50 производительность на человека ниже, чем в РФ. Но если денег полно — не проблема. Зато работает немецкий принцип: любой человек — винтик в системе и его можно заменить. Причем, увольнять в Германии сама контора не может — без каких-то страшных грехов со стороны работника, которые еще надо доказать. Так что тут это точно не про возможность уволить. Но с работником и вправду проблемно что-то планировать — как правильно заметил Булгаков, начнешь что-то планировать, распоряжаться, входить во вкус — а у него кхе… кхе… саркома легкого.
Здравствуйте, vfedosov, Вы писали:
V>Почти все инженеры должны кодить минимум на 3х языках — плюсы, джава и пайтон, работая с эмбеддед, десктоп, облаками и иногда с вебом и еще с некоторыми девопс фичами и самостоятельно тестируя.
То то смотришь на блоки в машине через ESys и думаешь какой психопат такой мрак придумал?
Здравствуйте, vfedosov, Вы писали:
V>Но с работником и вправду проблемно что-то планировать — как правильно заметил Булгаков, начнешь что-то планировать, распоряжаться, входить во вкус — а у него кхе… кхе… саркома легкого.
Зато, когда результат — стабильное УГ и делается очень медленно, все отлично предсказуемо. Потому что хуже уже некуда, а если вдруг случайно получится лучше, то можно словить премию
Здравствуйте, Codealot, Вы писали:
C>У нас тут новое веяние в области расширения и углубления идеи "все должны знать всё обо всём" — кто в данную неделю "на дежурстве", тот должен уметь обновлять NuGet пакеты в одной нашей софтине и делать релиз. С учетом того, что там легко могут быть breaking changes. Включая тех людей, кто до этого C# никогда в глаза не видел. C>И хотя я и раньше догадывался, почему на рынке софтостроения в целом и в больших компаниях в особенности происходит такой бардак, реальность кроет любые догадки как бык овцу.
Смотрю, какие ты темы актуализируешь. А не можешь текст своего контракта с этой компанией
выложить в открытый доступ в обезличенном виде? Или хотя-бы частично? Не повредив себе есс-но.
Хотя, обычно такие конторы включат в текст условие неразглашения ни одной запятой из контракта.
Наверняка там ведь масса ответов на твои вопросы найдется. Ну, т.е. вероятно там ты уже подписал
отказ от всех своих прав, надежд и ожиданий.
Программирование толпой (иногда неофициально называемое моббингом или ансамблевым программированием ) — это подход к разработке программного обеспечения, при котором вся команда работает над одним и тем же, в одно и то же время, в одном месте и на одном компьютере. Это похоже на парное программирование , когда два человека сидят за одним компьютером и одновременно работают над одним и тем же кодом. При групповом программировании сотрудничество распространяется на всех членов команды, при этом для написания кода и ввода его в кодовую базу по-прежнему используется один компьютер.
Основная концепция программирования толпы проста: вся команда одновременно работает над одной задачей. То есть: одна команда — одна (активная) клавиатура — один экран (конечно проектор).
— Маркус Хаммарберг, Моб-программирование — вся команда, полный газ
Он основан на принципах бережливого производства, экстремального программирования и бережливой разработки программного обеспечения . Раннее использование фразы «программирование толпы» было сделано в Перспективах Экстремального Программирования.
В дополнение к кодированию программного обеспечения, группа программистов толпы может работать вместе для решения других типичных задач разработки программного обеспечения. Некоторые примеры включают: определение пользовательских историй или требований, проектирование, тестирование , развертывание программного обеспечения и работу с экспертами в предметной области. Почти вся работа выполняется на рабочих собраниях или семинарах, где все люди, участвующие в создании программного обеспечения, считаются членами команды, включая заказчика и бизнес-экспертов. Мобильное программирование также работает для распределенных команд в одном и том же виртуальном пространстве с использованием технологии совместного использования экрана.
Зуилл, Вуди (2014). «Программирование мобов: подход всей команды» . Отчеты об опыте проведения конференций Agile2014 : 11.
Хаммарберг, Маркус. «Моб-программирование — полная команда, полный газ» . Код Лучше . Код Лучше . Проверено 9 сентября 2014 г.
Моисей Хохман; Эндрю Слокум (2002). «Глава 28. Программирование мобов и переход на XP». Экстремальные перспективы программирования . Эддисон-Уэсли.
Нигри, Жюльен. «Программирование Le Mob: Презентация» . Соат (на французском языке). Соат . Проверено 9 сентября 2014 г.
Харрер, Саймон; Христос, Йохен; Хубер, Мартин. «Удаленное программирование толпы» . Проверено 29 апреля 2019 г.
перед одним большим экраном как в кинотеатре, или небольшим настольным, если нет денег, за одним компьютером. То есть парное программирование это 2 человека за одним компьютером, а программирование толпой это 2 и более человека за одним компьютером.
Программирование толпой нужно внедрять постепенно, так же как соло программисты тоже внедряются в проект не сразу. Дело не в том, что программирование толпой плохая техника, но часть людей как и при найме соло программистов отвалится.
Кто-то же может сказать, что есть минусы от толпы, ведь компьютер один и параллельная работа не предусмотрена, а значит и ускорения от параллелизма не будет. Но иначе лично я не знаю как осуществить практику "все должны знать всё обо всём".
Самый простой способ это просто присутствовать всем работающим над проектом вне зависимости от профессии, когда принимались те или иные решения. А когда наберётся масса людей знающих обо всём, то часть из них можно будет постепенно заменить.
Есть и соло подход так восхваляемый некоторыми людьми. Незаменимые специалисты, когда после их ухода иногда проще писать проекты заново. Везде есть плюсы и минусы. Некоторые даже думают, что тот же менеджер может менеджерить всё, что угодно.
Здравствуйте, no_ise, Вы писали:
_>Смотрю, какие ты темы актуализируешь. А не можешь текст своего контракта с этой компанией _>выложить в открытый доступ в обезличенном виде? Или хотя-бы частично? Не повредив себе есс-но.
Нет.
_>Наверняка там ведь масса ответов на твои вопросы найдется. Ну, т.е. вероятно там ты уже подписал _>отказ от всех своих прав, надежд и ожиданий.
Условия вполне стандартные — должен делать что сказали делать.
А вообще бывают контракты, в которых есть детали как конкретно делается работа?
Программируя вместе за одним компьютером, Джефф Дин и Санджай Гемават изменили курс компании — и весь Интернет. На иллюстрации: лучшие программисты Google иногда кажутся двумя полушариями одного мозга. Рисунок Дэвида Планкерта
Взять тот же RSDN, громче всех кричат индивидуалисты, когда критикуют совместную работу. Но есть ли среди них создатели успешных проектов уровня Google Mail.
А практически я тоже сейчас сижу за компьютером один. Это значит я могу потратив время проверить идею в индивидуальном исполнении, но не программирование толпой.
Или берём любую случайную статью про успешный успех.
частичные данные по исследованию 8380 проектов из указанного выше отчета:
1. около 83% проектов закончились провалом или спорно;
2. только 15,5 % проектов уложились или не превысили бюджет более, чем на 20%;
3. в 25,2% проектов бюджет был превышен более, чем в 2 раза;
4. только 13,9 % проектов уложились или не превысили сроки более, чем на 20%;
5. в 47,8% проектов сроки были превышены более чем в два раза;
6. только в 7,3% проектов был реализован весь запланированный функционал;
7. в 49% проектов функционал был реализован в пределах 25-74%.
И причём соло программистов уровня синьор или пусть даже мидл это не волнует. Провалились проекты, ну и пошло оно, деньги заплачены, давай до свидание работодатель. Как не волнует их и то, что джуниоров не берут на работу.
А вот если бы соло программист провалил 100% своих вложений, то он бы может и задумался, что иногда нужно делать ремонт бригадой, то есть толпой. И задумался бы над тем, что количество однотипной рабочей силы на объекте это не так уж и плохо.
Но поскольку тратятся деньги работодателей, а говнокод всегда можно выдать за конфету, если никто его с лупой проверять не будет, то можно и говнокодить.
Например, что эффективнее, совместить создание кода и его обзор толпой, или создать код в соло, а потом провести обзор кода той же толпой. Или вообще не обозревать код, понадеяться, что там всё круто, ведь его сделали в соло, а значит дело верняк.
Собственно здесь ещё думаю такое дело, что инженеры могут сидеть в своём конструкторском бюро толпой и даже разрабатывать совместно, но не программисты. Ведь всем известно, что программирование это мистическая профессия требующая запереться в тёмном углу и наколдовать программу.
Я в общем к тому, что соло разработка не то, чтобы очень хорошо работает. Учитывая количество провалов скорее плохо, чем хорошо. Просто соло программистам сумевшим устроиться на работу плевать на провалы или говнокод.
Начальство сверху понимает, что есть проблема, но не знает как её решить. Сейчас многие крупные компании пытаются найти программиста супер звизду, то есть синьора. Но за супер звиздой на самом деле может скрываться толпа китайцев, даже если они и не сидят за одним компьютером.
В прошлом году в ходе аудита безопасности неназываемой компании, являющейся одним из ключевых инфраструктурных предприятий США, было выявлено, что один из топовых разработчиков нашел успешный способ не работать, «гулять» целый день по Интернету и оставаться одним из лучших работников буквально таки по сценарию новостного выпуска юмористической газеты фальшивых новостей Onion: он передал свою собственную работу на аутсорсинг китайскому подрядчику, а сам проводил рабочее время на сайтах социальных сетей, «Ибее» и смотрел видео с кошками на «Реддите».
Так что фактически всё сводится к источнику финансирования и желания проводить опыты. Если программистам перестанут платить, а я замечу, что платят не всем, и скорее даже меньшинству, то им ничего не останется кроме как остаться безработными или сменить профессию.
Уточню свою мысль из предыдущего комментария, если внедряешь парное программирование, программирование толпой, то ярых соло программистов нужно заменять на тех, кто согласен работать совместно. Потому что да, будут комментарии в стиле что за бред и так далее.
Здравствуйте, velkin, Вы писали:
V>Программируя вместе за одним компьютером, Джефф Дин и Санджай Гемават изменили курс компании — и весь Интернет. На иллюстрации: лучшие программисты Google иногда кажутся двумя полушариями одного мозга. Рисунок Дэвида Планкерта
Сразу повеяло голливудскими фильмами про хакеров. То есть, фуфлом.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, no_ise, Вы писали:
_>>Смотрю, какие ты темы актуализируешь. А не можешь текст своего контракта с этой компанией _>>выложить в открытый доступ в обезличенном виде? Или хотя-бы частично? Не повредив себе есс-но.
C>Нет.
_>>Наверняка там ведь масса ответов на твои вопросы найдется. Ну, т.е. вероятно там ты уже подписал _>>отказ от всех своих прав, надежд и ожиданий.
C>Условия вполне стандартные — должен делать что сказали делать. C>А вообще бывают контракты, в которых есть детали как конкретно делается работа?
Бывают даже и сейчас, для людей которым это нужно и при условии что на этом стороны
пожали друг другу руки.
Добавлю, как я это вижу со своей колокольни.
Где-то до 2008 года даже с обычным employee выше джуниора при устройстве обсуждали условия.
Речь про небольшие компании, наши и зарубежные. Про крупняк не скажу.
Никто из employee конечно не вытягивал чего он изволит, но при желании условия как-то
торговались к балансу. Детали и порядок взаимодействия тоже можно было фиксировать, если
мне нужно и работодателю ок.
Далее такие традиции еще некоторое время наблюдались для контрактников.
С одной стороны, это кмк слегка напрягало некоторые компании так снисходить, но с другой
стороны честно лишало employee аргумента 'да вы тут оказывается все чудаки на букву %'.
К тому-же, наверно в этом база для дальнейшей предсказуемости закладывалась, типа меньше
потом проблем с токсичностью.
Но затем все это схлопнулось со словами 'у нас очередь других кандидатов' и 'у нас все
по такому контракту работают и никто не жаловался' и 'ну я подумаю, но этож нам никто не согласует'.
Из недавнего, видны три характерных вида:
a) типовой делай что скажут,
b) или типовой хороший, но под ним спрятана уловка, которая сводит к делай что скажут. Можно что-то
подправить по-мелочи, но все равно все одно.
c) или хорошо, давай договоримся по всем условиям, но честно предупреждаем что с самого
начала будем действовать в теоретико-игровом ключе по всем составленным пунктам против тебя.
Так что контракты с деталями бывают, как минимум в пространстве-времени.
Я вот только не могу понять, почему вектор развития направлен в обратную сторону.
Здравствуйте, Codealot, Вы писали:
V>>Программируя вместе за одним компьютером, Джефф Дин и Санджай Гемават изменили курс компании — и весь Интернет. На иллюстрации: лучшие программисты Google иногда кажутся двумя полушариями одного мозга. Рисунок Дэвида Планкерта C>Сразу повеяло голливудскими фильмами про хакеров. То есть, фуфлом.
Вообще говоря есть некое "научное" обоснование совместной работы.
Суть парадокса Соломона заключается в асимметрии принятия решений. Когда к нам обращаются за советом, то мы всегда готовы помочь: обдумываем проблему, проявляем чудеса рациональности, даём разумные и дельные рекомендации. Когда же мы сами попадаем в аналогичную ситуацию, то вся наша смекалка и рациональность куда-то пропадают: мы теряемся, мечемся от одного варианта к другому, принимаем совершенно недальновидные решения.
Люди демонстрируют более рациональный взгляд на проблему, если она не касается их самих. Классический «сапожник без сапог».
Эти особенности человеческого поведения были подтверждены экспериментами, проведёнными Игорем Гроссманом, доктором философии из университета Ватерлоу, и Итаном Кроссом, профессором психологии Мичиганского университета.
Они же придумали название парадокса. Библейский царь Соломон известен как мудрый правитель, который успешно и эффективно решал проблемы других людей — принимал «соломоновы решения». В то же время его описывают как человека, который был совершенно неспособен управлять своей жизнью.
Это, конечно, помимо суммирования множества знаний.
Аватар Фрейда
В 2019 году группа испанских психологов экспериментально подтвердила (PDF) эффективность метода абстрагирования от проблемы и перевоплощения в советчика. Не обошлось без современных технологий. Учёные создали виртуальные аватары всех участников эксперимента. Для этого они применили технологию 3D-сканирования. Заодно они создали трёхмерную модель Зигмунда Фрейда.
В ходе эксперимента психологи разделили участников на две группы. В первой группе участники просто рассказывали о своей проблеме виртуальному Фрейду, который беседовал с ними, задавал вопросы и высказывал замечания. Его реплики были заранее записаны экспериментаторами. В общем, всё это выглядело как виртуальная приёмная психоаналитика.
Для второй группы всё было организовано интереснее: участники по очереди «вселялись» то в аватар Фрейда, то в свой собственный аватар. Фактически получалось, что они вели беседу сами с собой. Для усиления эффекта экспериментаторы поместили в виртуальную сцену зеркало: участники всегда видели отражение своё отражение — в роли Фрейда или в роли самого себя.
Наверное, вы уже догадались, что вторая группа показала гораздо более эффективные результаты в решении проблем. Её участники:
1. лучше разбирались в своей проблеме;
2. принимали более продуктивные решения;
3. испытывали меньше стресса;
4. лучше понимали прошедшие и будущие события.
Ну, политика уже приносит первые плоды. Объяснил человеку базовые шаги, что и как делать. Не понимает. Оказалось, что вместо Visual Studio пытается делать в Visual Studio Code, потому что название похоже.
