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

С автором этих слов мнения у нас разнятся, причём довольно сильно, но сейчас мне бы хотелось послушать ещё других мнений. Что вы думаете по этому поводу? Если хотите обсуждения, пишите в чатик, если хочется декларативного изложения или анонимности, то пишите мне в личку (@aratak) с тегом #узаконитьпроще, все сформулированные и не банальные мысли оформим постом.

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

— Всегда смывай за собой в туалете.
— Это не всегда так. Разработчик руки зашёл помыть может? Есть ли перебои с водоснабжением? А два подряд человека могут смыть один раз? Сломан ли бачок унитаза? Если не получилось сходить, нужно ли смывать? А если кнопка на бачке грязная? Дети в Африке голодают, быть может, экономить воду?

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

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

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

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

#dimoneverything

Ребята, еще одна #экстравакансия от моего хорошего знакомого. Если чувствуете в себе силы, обязательно попробуйте. Резюме шлите сразу Павлу (@jtootf), у него же можно спросить остальные детали.

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

Области деятельности - AI, data science, machine learning, computer vision. В данный момент - в области систем безопасности. Необходимые знания: хороший математический уровень (анализ, линейная алгебра, вычислительная геометрия, статистика), умение использовать оптимизировать и строить нейросетевые модели, свободное владение Python, способность читать научные работы и реализовывать предложенные там модели. инструментарий любой. Вилка зарплаты приблизительно $4k-$4.5k в месяц при полной загрузке.

Ребята, 7 сентября в Киеве будет конференция «IT Weekend» и нас с вами туда зовут и даже скидку небольшую предлагают подписчикам «Экстраполяции» по кодовому слову 4itextrapolation. Я вот планирую посетить эту конфу, ведь обещают говорить о продуктовой разработке. В общем, приходите!

https://itweekend.events/event/it-weekend-ukraine-2019-ukrainian-it-awards-2019/

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

Принципиально существует два вида обмена информацией в команде с условными названиями «push» и «pull».

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

Способ с кодовым названием «push» напротив сосредотачивается на том, что весь процесс тщательно записывается и ответы на все вопросы уже как бы есть и ничего узнавать ни у кого не нужно. Достаточно просто знать где искать. Этот подход более требователен как к исполнителям, так и к менеджерам, ведь любой чих и пук должен быть запротоколирован и каталогизирован. Был выбор между двумя библиотеками? Нужно описать все сомнения, факторы, повлиявшие на решение и само решение в специальное место, чтобы если вдруг у кого-то появится желание использовать противоположную библиотеку, он мог узнать о предыдущем решении и проникнуться всеми сомнениями прошлого исполнителя. Прилетело резюме от кандидата, с которым мы уже имели дело в прошлом? Об этом нужно незамедлительно узнать и выяснить все детали прошлого расставания или отказа. Недостатком такого подхода будет стабильно увеличенное время разработки. А серьезной проблемой будет простая человеческая лень и забывчивость. А самое сложное в этом подходе будет придумывание структуры хранения всего этого

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

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

#полныйаджайл

#полныйаджайл от подписчика Михаила (@mgolubtsov), который не согласен с предыдущим постом.

———

В ИТ-индустрии при слове «аджайл» многие ошибочно первым делом думают о процессе, и о всяких скрамах, канбанах, митингах и командных ритуалах.

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

Допустим, у нас типичный случай – программист Иван реализовал фичу, её выкатили в продакшн, там возникла некоторая проблема и её нужно решить. Но Иван не может уделить этому 100% своего времени, потому что ему необходимо срочно подготовить отчёт на другом проекте. Поэтому к решению подключается Сергей, но документации почти нет, в код вникнуть сразу не получается, проблема не может быть решена вовремя.

Хороший скрам-мастер или тимлид сразу скажет, что тут же проблема с процессом! Документации нет, потому что нет правила писать документацию и нужно такое правило ввести и ещё в чеклист код-ревью это добавим и такой ситуации больше не будет.

А очень хороший тимлид или скрам-мастер обратит внимание, что у нас же проблема с коммуникацией. Почему Иван работал один и не смог передать знания о системе? На это может быть множество причин, причем некоторые из них чисто человеческие. Может быть нам нужно как-то изменить наш процесс, чтобы развивать культуру коммуникации, например, для более важных задач применять парное программирование. А может быть и не нужно, может быть дело в том, что Сергей сычует в другой комнате и отвечает по имейлу, и достаточно его просто пересадить поближе к Ивану. Готового рецепта нет, нужно разбираться и пробовать разное. Ключевой момент это в чем мы видим корень проблемы в процессе или в людях, в их коммуникации.

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

А может быть ребятам нужно просто поговорить и почаще вместе работать, тогда и проблемы не будет. Один из принципов манифеста об этом говорит: «Непосредственное (face-to-face) общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды».
В одной моей команде были трудности в общении. У нас были формальные ретроспективы с модератором, стикерами и четким таймингом, но напряжение накапливалось, пока однажды наш лид не предложил провести ретро в баре в неформальной обстановке. Это была наша лучшая ретроспектива, с наиболее осмысленными и классными дискуссиями! Просто людям не хватало атмосферы открытого общения в простом человеческом ключе.

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

Появилось новое слово в лексиконе: «bulk-approve».

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

#dimoneverything

​​Эйнштейн помогает с пулл реквестом.

Задачи, о которых просят пользователи.

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

Есть две крайности, ударяться в которые будет очень плохо.

Первая крайность бездумно потакает всем похотям пользователей и максимум что делает — группирует входящие запросы по подобию. А если в команде есть бизнес-аналитик, то ещё очень быстро появляется желание оценивать полезность реквестов и отсеивать их. Мол, «удовлетворим 20% вот этих желаний, получим 80% выгоды, а на остальные подзабьём» или ещё как-то так. Принципиально аналитики картины не меняют, хотя да, эффективность повышают.

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

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

90% кодревью на практике неотличимы от code-style тестов, которое вроде бы должен делать CI. В смысле, замечания, которые люди пишут в пулл-реквесты, такие же, как должен был бы написать сильно продвинутый CI. Мол, а тесты где? А тесты твои не тестят нифига — ты попробуй, код свой удали, и посмотри, проходят? Да, проходят. Вот и выкинь свои моки. Отступы поправь. Английский выучи, индус, прежде, чем многострочные комменты писать — тут the надо. Метод приватным сделай. В раутах весь ресурс не открывай. И индекс на поле поставь.

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

#dimoneverything

Ещё одна #экстравакансия, на этот раз ищу я и ищу фронтендера с большой буквы Ф в продуктовую разработку.

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

Работа будет удаленная, само собой, но увидеться и поработать вместе недельку-другую можно будет в Киеве. Пишите мне в личку (@aratak) и отправляйте это сообщение знакомым джаваскриптизёрам. Спасибо.

Ребята, я читал и плакал. Дмитрий, в рамках тега #dimoneverything решил попробовать слегка по-другому мысли свои передать и у него это получилось просто превосходно.

https://telegra.ph/Full-stek-matros-08-29

Ребята, инфопартнерство. В Одессе в конце сентября будет хакатон. Всем, кто как-то связан с визуализацией информации, хакатон этот будет интересней, чем тем, кто не связан. Это я так, типа, дизайнеров обозвал. В общем, обратите внимание, мне кажется, что это может быть интересным.

https://hackodessa.photolab.me/

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

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

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

Во, и название придумалось, «Метод второй производной». Как вам?

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

В общем, 28 сентября будет конференция «Эликсир Клаб» и в этот раз ребята хотят сделать не митап, как обычно, а целую конференцию на целый день. И в гости позвали именитых спикеров. Короче, я там буду, ищите меня в зале.

http://bit.ly/2lM3jPP

P.S. Скидка в 10 процентов по коду extrapolation.

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

Короче, мы, когда уже круты, на самом деле оцениваем задачу абсолютно правильно. Вот вообще. Мы довольно точно предсказываем, сколько времени у нас займёт решить эту задачу, исходя из того, что 100% этого времени мы будем в своей наилучшей форме. Нас ничего не будет отвлекать в процессе, мы не будем уставшими, думать, что пора забирать ребёнка, что хочется в кино и жизнь задрала. И что мы будем аж вообще молодцы. И это всегда неправда.

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

#dimoneverything

Центр вселенной и пуп мира.

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

Более приближенный к интернету пример: составить психологическую картину личности со всеми его мыслями, тайными желаниями, сексуальными потребностями и насущными проблемами можно лишь по ретвитам и репостам. Далеко не все способны красиво и четко сформулировать свою мысль или желание, а вот прочитать чужую и согласиться с ней - пожалуйста. Итого мы имеем одну четко и ясно сформулированную мысль и группу пользователей, которые с ней согласны. И не просто согласны, а согласны до такой степени, что будь они чуточку образованнее и собранней, это была бы их мысль. Социальные сети с возможностью репоста стали чем-то вроде хаотично разбросанных мыслей в виде ленты сообщений от твоих "друзей". Мысли генерировать в состоянии лишь единицы, тысячи же лишь могут пропустить мысль через сито своего восприятия и получить на выходе соответствие или отвергнуть ее, как непонятую, не соответствующую своим мыслям. Кстати, именно поэтому сервисы, требующие от пользователя выдавать необходимую единицу смысла менее популярны сервисов, где основным средством самовыражения есть возможность лаконично изъяснить свои мысли за счет чужого умения красиво эти самые мысли формулировать. Наугад взятый фолловер из твиттера, на 50 процентов состоит из ретвитов, на 25 процентов из публикаций сервисов а-ля "мне понравилось видео на ютубе" или "я на автостанции 'Южный' стал майором", еще на двадцать - из ответов на другие такие де твиты. И именно львиная доля этих сообщений и есть тот набор мыслей, который мог бы быть авторским при других обстоятельствах. Действительно ли представленный индивидуум настолько умен и интересен, как он заявляет о себе с помощью набора чужих мыслей? Вспоминается история в которой начинающий дизайнер в резюме прикреплял работы известных дизайн-студий, мотивируя это тем, что он тоже так может.

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

Осознание своего собственного 'я' и, как следствие, своего собственного мнения делает убежденность в объективности своего мнения непоколебимым. Любой диалог и процесс обмена информацией между двумя индивидуумами сводится к формированию и в последствии убеждения собеседника в объективности своего субъективного мнения. Объективности не существует. Точно так, как не существует Вселенского Разума или жизни вне биологической или какой-нибудь другой оболочки. Существуют только множество проекций реальности через эгоцентричное осознание индивидуумов.

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

Сервисы и микросервисы.

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

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

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