Частые коммиты порождают хаотичную историю. Впрочем как и редкие. Они должны быть обдуманными и хорошо выверенными, а как часто их делают -- это каждый для себя выбирает сам. А в мерж конфликтах не вижу ничего страшного. Да и вообще, главное не код, а его понимание: если есть мерж конфликт на изменении, которое ты понимаешь, не проблема это изменение адаптировать к новой реальности.
25 лет назад был изобретен Cynefin Framework. Первое, что мы делаем -- договариваемся с заказчиком, менеджером, коллегами, в каком домене сложности находится задача, а потом не нарушаем правил, царящих в домене. Если все согласны, что задача рутинная -- обговариваются сроки. Если есть над чем подумать -- разбивают на подзадачи, делают сроки плавающими. Если объективно недостаточно информации, чтобы вообще понять, решаема ли задача -- заказывают лишь исследование, но не продукт. И т.д.
В моем случае присутствует проблема курицы и яйца: для того, чтобы человека начали слушать, ему нужно себя проявить, а критерии эффективности -- количество, а не качество кода. Приведу пример другой метафоры, поясняющей ту же мысль. Когда стадо баранов несется к пропасти, а кто-то пытается их остановить, в первый момент кажется, что этот "кто-то" бежит медленнее всех. При этом до поры до времени припасть не видит никто.
Тут ведь как... Человек зарегистрировался на Хабре 1 февраля 2014 года. Более десяти лет не оставлял ни одного комментария. Ждал, копил говно, бережно складывал его к себе под кроватку, чтобы однажды вылить его на вентилятор. Разродился целой статьей! С одной совершенно логичной целью: чтобы у меня порвало пукан.
Не знаю, с какой стати ваше эпистолярное творение должно меня привести к осознанию того, что "меня может поиметь мир"... О том, что мудаков вокруг полно, я и до вас знал.
И прорыв, и смирение -- это два варианта поведения в хаосе. Мы как мыши в том эксперименте, только одних херачат током, других нет (скорее "пока нет"). Настоящий же инженер в родной среде обитания напоминает кота на диване (см. книгу "Как пасти котов"): спокоен, независим, иногда "тревожится" себе в удовольствие на поймать мышку.
Рекомендую книгу Jonathan Boccara "The Legacy Code Programmer's Toolbox: Practical Skills for Software Professionals Working with Legacy Code". Там есть такая сентенция, что от легаси кода можно получать удовольствие. Но описан единственный способ это сделать: начать устранять легаси :)
Есть технологии, которые позволяют избежать легасилизации, но большинство проектов на них забивает. Там, где нужно чуть-чуть больше мотивации (например, чтобы дать методу недвусмысленное имя, или большой коммит разбить на несколько поменьше и каждый по отдельности описать в commit message) мы могли бы удержаться в Complicated с небольшой "тревожностью". Но, как правило, мы выбираем простой путь "и так сойдет".
Легаси -- это постоянно растущий технический долг. А с долгами (у нормального человека) растет тревожность, но лишь до определенного предела: потом становится все по фиг.
Эту теорию стоит рассмотреть через призму Cynefin Framework. Грубо говоря, домен Simple -- это когда мы находимся в зоне комфорта, делаем нечто привычное, что умеем делать хорошо, не задумываясь о том, какой метод выбрать. Тревожность нулевая. Complicated требует аналитического подхода, мы вырываемся из рутины и возрастают и интерес, и тревожность. При этом тревожность вырастает незначительно, потому что бОльшая часть процессов остаются под нашим контролем. В домене Complex мы не можем применить аналитику, т.к. у нас недостает информации. Мы применяем исследовательский подход. Тут тревожность возрастает сильно. Мы как человек с завязанными глазами в незнакомой комнате: движемся осторожно, чтобы не удариться, запоминаем полученную информацию. Негативную информацию воспринимаем острее и запоминаем на более долгое время: например, то, как нас шандарахнуло током, мы помним долго, и избегаем повторения такого опыта. Домен Chaos -- это тревожность на максималках. Этот домен возникает в любого вида соревновании, в любой неожиданной ситуации и т.д.
Так вот инженерия -- это дисциплина, которая ДОЛЖНА вращаться вокруг домена Complicated. Нам должны быть понятны причинно-следственные связи той области, где мы работаем, должны быть минимизированы неожиданности. И мы спокойно, с большим интересом и разумной степенью тревожности должны заниматься созиданием... На практике, когда это касается software engineering (что в моем понимании является извращением термина) нас принудительно втягивают в неподобающий домен сложности. Нет внятных требований -- добро пожаловать в хаос. Грянут увольнения -- начинается соревнование "последний герой". Тоже хаос. Легаси код -- мы как слепые котята тыкаемся в стены, боясь тронуть то, чего не понимаем. Пока боимся -- в хаосе, когда начинаем трогать и оттуда идет запах -- попадаем в Complex. А начальството спрашивает как с рутины... Например, хочет, чтобы мы в офисы вернулись, как будто мы кассиры в быстрофуде. Таймтрекеры ставит, и т.д. И в целом да, ходят выгоревшие невыспавшиеся программисты и создают иллюзию производительности. Потому что тревожные.
С трудом дочитал до "нет сопроводительного письма". А еще кандидат, наверное, не сказал "Ку".
Сопроводительные письма я пишу только в исключительных случаях: когда компания элитная, когда опыт чуть нерелевантный, и т.д. В любом случае такое письмо я создаю под конкретную компанию, и это большая работа эпистолярного жанра. Каким же дуболомом нужно быть, чтобы требовать его всегда и рекомендовать прикладывать шаблонную отписку...
На "50+" читать закончил. Минус в карму и пожелание профессиональных неудач.
Почему-то в данном контексте теряется отношение к свитчерам с нашей стороны как пользователей: когда падает качество продуктов, которыми мы вынуждены (или привыкли) пользоваться -- а такое происходит повсеместно -- отношение к людям, "меняющим сферу деятельности", становится не столь снисходительным. Хоть и не только они виноваты в падении качества.
Вы мне напомнили анекдот про чабана и геолога. Геолог спрашивает чабана:- Отец, скажи, а сколько твои овцы дают за сезон шерсти?- Белые или черные? - спрашивает чабан.- Ну, черные.- Черные - 2 килограмма.- А белые?- И белые - 2 килограмма.- А скажи, отец, сколько им нужно корма в день?- Черным или белым? - уточняет чабан.- Ну, черным.- Черным - 1 килограмм.- А белым? - не унимается геолог.- И белым - 1 килограмм.Геолог в бешенстве:- Ты что, меня задрачиваешь? Почему все время спрашиваешь черные илибелые, ведь результат один и тот же?!!!!- Ну-у, так черные ж мои... Отвечает чабан.(геолог понимающе)- а-а-а, А белые?- И белые мои...
Задумайтесь о том, в чем юмор анекдота. Почему информация о том, что "черные ж мои" заставила геолога понимающе кивнуть, а также почему становится смешно от того, что "и белые мои".
Не в обиду, но вам стоит подтянуть теорию. Как минимум, у многих величин и формул есть четкие названия, и когда человек ими оперирует, можно хотя бы сказать, прав он или нет. У вас же приходится догадываться, что именно вы имеете в виду, и обоснование получается "скользким". Например, последнее утверждение (если взять его буквально), начинает звучать как "если вероятность дождя 0.5, то вероятность дождя 1/9", что явно неверно. При этом скорее всего вы имели в виду что-то другое.
Почему "увы"? Реальная жизнь -- это не квадратное уравнение. И намного хуже -- выдавать численный "ответ" без попытки анализа. Кроме того, эта задача очень подходит к статье о парадоксах. Собственно для меня парадоксом является то, с какой пеной у рта люди начинают доказывать правильность своего численного ответа. Что интересно, обычно различных ответов дают около десятка, но что еще интереснее, эти группы адептов различных численных ответов мало спорят друг с другом, но готовы все вместе разодрать любого, кто им намекает на нестыковки в их аргументации.
Из Википедии: Несмотря на то, что Сиэтл находится в пределах дождевой тени Олимпийских гор, у него создалась репутация города, где часто идут дожди. Эта репутация основана на количестве осадков, выпадающих осенью, зимой и ранней весной. В среднем, более 0,3 мм осадков выпадает 150 дней в году. 201 день в году наблюдается облачность и ещё 93 дня — частичная облачность.
Как минимум, предположение о 50% априорной вероятности дождя нужно озвучить при решении. Но вообще говоря, оно неверное.
На самом деле, как мне кажется, в задаче есть две изюминки. Первая -- это сообразить, что без априорной вероятности дождя тут нечего делать, и либо явно об этом сообщить, либо ввести параметр. Давать сходу числовой ответ без параметра -- это пойматься в первую ловушку. Вторая изюминка состоит в том, что не имея априорной вероятности многие пытаются вывернуть наизнанку каузальность. То есть прямая каузальность -- это когда друг смотрит на улицу, узнает о наличии дождя, потом решает, есть ли у него настроение шутить, и как следствие двух факторов выше выдает ответ да/нет. При прямой каузальности без априорной вероятности не обойтись. Но в попытке ее выбросить многие прибегают к обратной каузальности -- это когда друг просыпается в подвале, о погоде ничего не знает, и выдает ответ "да" наобум, потом решает, нужно ли ему шутить, только затем он выходит на улицу и узнает о наличии дождя. Поскольку он не может нарушить свой принцип шутить один раз из трех, он берет с собой бубен и начинает моделировать погоду, чтобы она была в соответствии с условиями задачи. Описать обратную каузальность с тремя респондентами я уже не берусь. Так вот в случае обратной каузальности априорная вероятность не важна, т.к. погода зависит только от настроения шутников и их идеальной способности вызывать или останавливать дождь.
Частые коммиты порождают хаотичную историю. Впрочем как и редкие. Они должны быть обдуманными и хорошо выверенными, а как часто их делают -- это каждый для себя выбирает сам. А в мерж конфликтах не вижу ничего страшного. Да и вообще, главное не код, а его понимание: если есть мерж конфликт на изменении, которое ты понимаешь, не проблема это изменение адаптировать к новой реальности.
25 лет назад был изобретен Cynefin Framework. Первое, что мы делаем -- договариваемся с заказчиком, менеджером, коллегами, в каком домене сложности находится задача, а потом не нарушаем правил, царящих в домене. Если все согласны, что задача рутинная -- обговариваются сроки. Если есть над чем подумать -- разбивают на подзадачи, делают сроки плавающими. Если объективно недостаточно информации, чтобы вообще понять, решаема ли задача -- заказывают лишь исследование, но не продукт. И т.д.
Проверьте, в вашем лэптопе точно 640KB памяти, как, сказывают, предрекал Билл Гейтс?
В моем случае присутствует проблема курицы и яйца: для того, чтобы человека начали слушать, ему нужно себя проявить, а критерии эффективности -- количество, а не качество кода. Приведу пример другой метафоры, поясняющей ту же мысль. Когда стадо баранов несется к пропасти, а кто-то пытается их остановить, в первый момент кажется, что этот "кто-то" бежит медленнее всех. При этом до поры до времени припасть не видит никто.
Тут ведь как... Человек зарегистрировался на Хабре 1 февраля 2014 года. Более десяти лет не оставлял ни одного комментария. Ждал, копил говно, бережно складывал его к себе под кроватку, чтобы однажды вылить его на вентилятор. Разродился целой статьей! С одной совершенно логичной целью: чтобы у меня порвало пукан.
Не знаю, с какой стати ваше эпистолярное творение должно меня привести к осознанию того, что "меня может поиметь мир"... О том, что мудаков вокруг полно, я и до вас знал.
И прорыв, и смирение -- это два варианта поведения в хаосе. Мы как мыши в том эксперименте, только одних херачат током, других нет (скорее "пока нет"). Настоящий же инженер в родной среде обитания напоминает кота на диване (см. книгу "Как пасти котов"): спокоен, независим, иногда "тревожится" себе в удовольствие на поймать мышку.
Рекомендую книгу Jonathan Boccara "The Legacy Code Programmer's Toolbox: Practical Skills for Software Professionals Working with Legacy Code". Там есть такая сентенция, что от легаси кода можно получать удовольствие. Но описан единственный способ это сделать: начать устранять легаси :)
Есть технологии, которые позволяют избежать легасилизации, но большинство проектов на них забивает. Там, где нужно чуть-чуть больше мотивации (например, чтобы дать методу недвусмысленное имя, или большой коммит разбить на несколько поменьше и каждый по отдельности описать в commit message) мы могли бы удержаться в Complicated с небольшой "тревожностью". Но, как правило, мы выбираем простой путь "и так сойдет".
Легаси -- это постоянно растущий технический долг. А с долгами (у нормального человека) растет тревожность, но лишь до определенного предела: потом становится все по фиг.
Эту теорию стоит рассмотреть через призму Cynefin Framework. Грубо говоря, домен Simple -- это когда мы находимся в зоне комфорта, делаем нечто привычное, что умеем делать хорошо, не задумываясь о том, какой метод выбрать. Тревожность нулевая. Complicated требует аналитического подхода, мы вырываемся из рутины и возрастают и интерес, и тревожность. При этом тревожность вырастает незначительно, потому что бОльшая часть процессов остаются под нашим контролем. В домене Complex мы не можем применить аналитику, т.к. у нас недостает информации. Мы применяем исследовательский подход. Тут тревожность возрастает сильно. Мы как человек с завязанными глазами в незнакомой комнате: движемся осторожно, чтобы не удариться, запоминаем полученную информацию. Негативную информацию воспринимаем острее и запоминаем на более долгое время: например, то, как нас шандарахнуло током, мы помним долго, и избегаем повторения такого опыта. Домен Chaos -- это тревожность на максималках. Этот домен возникает в любого вида соревновании, в любой неожиданной ситуации и т.д.
Так вот инженерия -- это дисциплина, которая ДОЛЖНА вращаться вокруг домена Complicated. Нам должны быть понятны причинно-следственные связи той области, где мы работаем, должны быть минимизированы неожиданности. И мы спокойно, с большим интересом и разумной степенью тревожности должны заниматься созиданием... На практике, когда это касается software engineering (что в моем понимании является извращением термина) нас принудительно втягивают в неподобающий домен сложности. Нет внятных требований -- добро пожаловать в хаос. Грянут увольнения -- начинается соревнование "последний герой". Тоже хаос. Легаси код -- мы как слепые котята тыкаемся в стены, боясь тронуть то, чего не понимаем. Пока боимся -- в хаосе, когда начинаем трогать и оттуда идет запах -- попадаем в Complex. А начальството спрашивает как с рутины... Например, хочет, чтобы мы в офисы вернулись, как будто мы кассиры в быстрофуде. Таймтрекеры ставит, и т.д. И в целом да, ходят выгоревшие невыспавшиеся программисты и создают иллюзию производительности. Потому что тревожные.
Знаете, техасский стрелок тоже вначале стреляет в стену, а потом вокруг точки попадания мишень рисует.
Ну что было целью, того и достигли. Или вы ожидали, что мы все дружно над этим посмеемся?
Все-таки дочитал до конца. Жирный троллинг. Ложечка нашлась, но осадочек остался. Минус в карме остается.
Кто умеет -- работает. Кто не умеет работать -- учит. Кто не умеет учить, тот руководит. А кто не умеет руководить -- тот в отделе кадров.
Так что, думаю, что разряд окончателен.
С трудом дочитал до "нет сопроводительного письма". А еще кандидат, наверное, не сказал "Ку".
Сопроводительные письма я пишу только в исключительных случаях: когда компания элитная, когда опыт чуть нерелевантный, и т.д. В любом случае такое письмо я создаю под конкретную компанию, и это большая работа эпистолярного жанра. Каким же дуболомом нужно быть, чтобы требовать его всегда и рекомендовать прикладывать шаблонную отписку...
На "50+" читать закончил. Минус в карму и пожелание профессиональных неудач.
Почему-то в данном контексте теряется отношение к свитчерам с нашей стороны как пользователей: когда падает качество продуктов, которыми мы вынуждены (или привыкли) пользоваться -- а такое происходит повсеместно -- отношение к людям, "меняющим сферу деятельности", становится не столь снисходительным. Хоть и не только они виноваты в падении качества.
Вы мне напомнили анекдот про чабана и геолога.
Геолог спрашивает чабана:- Отец, скажи, а сколько твои овцы дают за сезон шерсти?- Белые или черные? - спрашивает чабан.- Ну, черные.- Черные - 2 килограмма.- А белые?- И белые - 2 килограмма.- А скажи, отец, сколько им нужно корма в день?- Черным или белым? - уточняет чабан.- Ну, черным.- Черным - 1 килограмм.- А белым? - не унимается геолог.- И белым - 1 килограмм.Геолог в бешенстве:- Ты что, меня задрачиваешь? Почему все время спрашиваешь черные илибелые, ведь результат один и тот же?!!!!- Ну-у, так черные ж мои... Отвечает чабан.(геолог понимающе)- а-а-а, А белые?- И белые мои...
Задумайтесь о том, в чем юмор анекдота. Почему информация о том, что "черные ж мои" заставила геолога понимающе кивнуть, а также почему становится смешно от того, что "и белые мои".
Не в обиду, но вам стоит подтянуть теорию. Как минимум, у многих величин и формул есть четкие названия, и когда человек ими оперирует, можно хотя бы сказать, прав он или нет. У вас же приходится догадываться, что именно вы имеете в виду, и обоснование получается "скользким". Например, последнее утверждение (если взять его буквально), начинает звучать как "если вероятность дождя 0.5, то вероятность дождя 1/9", что явно неверно. При этом скорее всего вы имели в виду что-то другое.
Почему "увы"? Реальная жизнь -- это не квадратное уравнение. И намного хуже -- выдавать численный "ответ" без попытки анализа. Кроме того, эта задача очень подходит к статье о парадоксах. Собственно для меня парадоксом является то, с какой пеной у рта люди начинают доказывать правильность своего численного ответа. Что интересно, обычно различных ответов дают около десятка, но что еще интереснее, эти группы адептов различных численных ответов мало спорят друг с другом, но готовы все вместе разодрать любого, кто им намекает на нестыковки в их аргументации.
Из Википедии:
Несмотря на то, что Сиэтл находится в пределах дождевой тени Олимпийских гор, у него создалась репутация города, где часто идут дожди. Эта репутация основана на количестве осадков, выпадающих осенью, зимой и ранней весной. В среднем, более 0,3 мм осадков выпадает 150 дней в году. 201 день в году наблюдается облачность и ещё 93 дня — частичная облачность.
Как минимум, предположение о 50% априорной вероятности дождя нужно озвучить при решении. Но вообще говоря, оно неверное.
На самом деле, как мне кажется, в задаче есть две изюминки. Первая -- это сообразить, что без априорной вероятности дождя тут нечего делать, и либо явно об этом сообщить, либо ввести параметр. Давать сходу числовой ответ без параметра -- это пойматься в первую ловушку. Вторая изюминка состоит в том, что не имея априорной вероятности многие пытаются вывернуть наизнанку каузальность. То есть прямая каузальность -- это когда друг смотрит на улицу, узнает о наличии дождя, потом решает, есть ли у него настроение шутить, и как следствие двух факторов выше выдает ответ да/нет. При прямой каузальности без априорной вероятности не обойтись. Но в попытке ее выбросить многие прибегают к обратной каузальности -- это когда друг просыпается в подвале, о погоде ничего не знает, и выдает ответ "да" наобум, потом решает, нужно ли ему шутить, только затем он выходит на улицу и узнает о наличии дождя. Поскольку он не может нарушить свой принцип шутить один раз из трех, он берет с собой бубен и начинает моделировать погоду, чтобы она была в соответствии с условиями задачи. Описать обратную каузальность с тремя респондентами я уже не берусь. Так вот в случае обратной каузальности априорная вероятность не важна, т.к. погода зависит только от настроения шутников и их идеальной способности вызывать или останавливать дождь.