Ребята, #хайринг. Воспользуюсь служебным положением и расскажу, что нам в команду (cimon.io) нужен дизайнер.

Чтобы хороший был, добрый и с бородой. Или без. И не обязательно «был», можно чтобы и «была». Но дизайнер. Ещё главное, чтобы добрый. Хотя, если будет злой, то тоже хорошо. Но только если дизайнер.

Работать нужно будет над одним из нескольких проектов, вроде riter.co или vault8.io. Работы вагон и маленькая тележка, прийдется много думать и принимать самостоятельные решения.

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

Дизайнеры, присылайте ссылку на работы свои личным сообщением в телеграме (@aratak). Отдельное спасибо за форвард сообщения друзьям-дизайнерам и в подконтрольные каналы и группы.

В каждом уважающем себя трекере задач всегда есть место для маркёра важности задачи. Ну, там «minor» или «important» или вообще «critical». Такие маркировки задач лишены смысла почти полностью и следующими несколькими постами давайте разберём почему.

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

Если проблема действительно критически важна, то разработчик, расслаблено набирая class MySuperSer..., должен немедленно это бросить и, как пожарник, броситься срочно тушить пожар. Там уже не до трекеров, оформлений багов, стикеров и оценок. Бумаги заполняются после пожара, а не до него.

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

Если постоянно кричать «Волки!», то люди перестанут обращать на это внимание.

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

С автором канала «Айти без галстуков», Дмитрием, мы знакомы лично и я уверенно могу сказать, что ему есть что рассказывать интересного ещё очень долгое время.

https://yangx.top/notieinIT

Для любителей нативной рекламы отдельно замечу, что получить подобного рода пост за деньги или за другую какую-либо награду на этом канале невозможно. Есть только один способ попасть в рекомендации канала «Экстраполяции» — иметь крутой авторский канал.

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

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

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

Сойдет за рубрику #полныйаджайл?

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

https://www.youtube.com/watch?v=deb8o1UCGsI

К слову, в тизере один из засветившихся в кадре — это я. Справа или слева?

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

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

Знаете кто лучше всего знает как делать ваш продукт? Вы. Пользователи могут хотеть вполне здравые вещи в их случае, но совершенно бессмысленные для развития продукта. Тут, наверное, уместнее всего вспомнить Генри Форда и его «более быструю лошадь», но в современном мире она звучит так: «Если бы я делал все то, что хотят пользователи, то мы бы получили более красивенький эксель».

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

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

Во-первых такие итерационные изменения могут привести совсем не к тому результату, к которому хотелось бы. В «Эктраполяции» уже была заметка по этому поводу.

Во-вторых пользователи не любят изменения. Они любят новые фичи только тогда, когда их старые любимые фичи остаются такими, к которым они привыкли.

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

Наконец-то, пройдя семь кругов монтажа и правок, пилотный выпуск шоу «Lambda Night Show» состоялся.

Будущее этого шоу неопределённое и многое зависит от вас. Формат шоу тоже наверняка претерпит изменения, согласно ваши отзывам.

Итак, что я вас прошу сделать:

1. Подпишитесь на канал. Много видео там не выходит, а увеличивающиеся количество подписчиков — это первый стимул снимать ещё выпуски.
2. Поделитесь этим шоу (или форвард этого поста в телеграме сделайте) с друзьями. Больше просмотров, больше лайков — больше стимула снимать шоу дальше.
3. Расскажите что вам понравилось и что не понравилось. Можно личным сообщением или прям там, на ютубе в комментариях. Мы внимательно читаем все и хотим сделать шоу лучше. Без вас это никак не получится.

Собственно, сам выпуск. Приятного просмотра!

https://youtu.be/zMIyqJkN9aY

Ребята. Мы тут сделали сокс-прокси, для всех нуждающихся. Пользуйтесь и раздавайте друзьям. Бесплатный.

@cimon_proxy_bot

Единственная «проблема тысячелетия», которую можно понять без специальной подготовки, это проблема «N и NP». Когда-то уже была заметка по этому поводу в «экстраполяции». Штука, безусловно, интересная, но к повседневному программированию относится весьма слабо. Кроме, пожалуй, того случая, когда получается квадратичная сложность решения.

Полный перебор — это фактически чистосердечное признание собственной беспомощности. Мол, «ребята, все человечество бьется над тем, как мне перебрать вот эти вот массивчики хоть немного быстрее, чем полный перебор». И вот вам лайвхак: чтобы объяснить, что невозможно сделать так, чтобы вот та вот страничка на сайтике не тормозила, говорите, что это проблема класса NP. Все-равно это никто не сможет опровергнуть.

​​По мотивам предыдущего поста есть замечательная матрица компетентности. Матрица компетентности составляющего матрицы, естесственно.

Это свершилось. Долгожданный второй выпуск «Лямбда Найт Шоу» уже на всех ютубах планеты! Поддержите лайком и репостом, друзья!

Буду признателен за любую критику и замечания. Можно прям в комментариях к видео.

Приятного просмотра.

https://www.youtube.com/watch?v=wHB4q8vtuYg

Работа фрилансера часто сопряжена с массой рисков. В основном, конечно, это риски финансовые или связанные с выполнением обязательств и, как следствие, все-равно финансовыми.
По факту, такие разрабочики пытаются найти компромисс между повышением стоимости своих услуг и открытым недоверием к своим клиентам. Ну, эти всякие «оплата 50% до начала работ», «давайте подпишем контракт, где четко распишем все наезды и предъявы» и «давайте работать через посредников, которые что-то там гарантируют». К слову, такое поведение свойственно не только отдельным фрилансерам, но и аутсорс-командам, потому как сейлз отдел ведёт себя приблизительно так же, как и отдельный фрилансер.

Совершенно понятно почему они себя так ведут и я вовсе не хочу сказать, что эти что-то ужасное.

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

Отвечу на вопрос, который задали личным сообщением.

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

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

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

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

Наконец-то смонтировали третий выпуск «Lambda Night Show». Как по мне, он получился лучше предыдущих, но это вы мне расскажите как он получился.

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

https://youtu.be/Mc06z9SsTmo

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

Болезнь непонятна, симптомы очевидны. И отсюда и появляются правила, которые лечат эти самые симптомы.

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

- Разбились на маленькие команды и понятия нет что происходит в других командах? Давайте устроим еженедельное собрание тимлидов с обязательным выступлением рт каждого.

- Программист зря зарывается на несколько недель над фичей? Давайте устроим каждодневные письменные отчеты.

- Менеджерам нужны какие-то данные для отчета стейкхолдерам? Утренние митапы решат эту проблему.

Ну, и так далее.

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

— Вы используете скрам?
— Нет, у меня в команде только адекватные люди, которые поступают максимально разумно.
— Зря не используете, мне помогло.

Решил поддаться тренду и завёл MTProxy с автопиаром канала. Уверен, что все, кто хотел воспользовался ботом, который бесплатный сокс-прокси раздаёт (@cimon_proxy_bot), но вы здоровски поможете каналу, если порекомендуете наш MTProxy своим друзьям и коллегам. Использовав этот прокси, ваши друзья увидят канал «Экстраполяции» в своём списке каналов и, возможно, подпишутся на него. Спасибо!

https://yangx.top/proxy?server=mtproxy.cimon.pub&port=443&secret=64b764d215a377c1676d3ea45b65fc2d

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

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

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

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

----

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

#коммуникация

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

https://youtu.be/Riw0XCIh364

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

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

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

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

4. Сообщения короче пяти секунд не имеют оправдания на существование.

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