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

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

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

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

Как кто с этим живёт и справляется? Прошу в чат для обсуждения.

Что на самом деле работало бы в микросервисах, если бы менеджеры этим пользовались.

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

Таким образом менеджер реализует принцип коллективного владения кодом и пытается защититься от фактора автобуса. Фактор автобуса - это мера сосредоточения информации среди отдельных членов проекта; фактор означает количество участников проекта, после потери которых (в оригинале — «попадания» которых под автобус или грузовик, варианты: увольнения, заболевания, рождения у них ребёнка, наступления несчастного случая и других форс-мажорных обстоятельств) проект не сможет быть завершён оставшимися участниками.

И вот штука в том, что при этом теряется одна из действительно работающих фич микросервисов: команды прикрепляются к своим проектам. Знают их и любят.

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

Конечно, начальство не хочет иметь незаменимых людей.

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

#dimoneverything

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

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

Разработка софта сегодня кардинально отличается от разработки двадцатилетней давности по одной простой причине: интернет везде. И даже сам софт поменял концепцию, назовём современный софт «internet first». Казалось бы, ну теперь есть постоянный коннекшен и можно обновлять приложения сколько угодно часто. Ну ничего страшного и кардинального. Сократилась длина итераций разработки, быстрее получаем обратную связь, быстрее фиксим баги и делаем новые. Быстрее, выше, сильнее и ничего кардинально нового в разработке не произошло. Ведь так?

А вот и произошло. Софт перестал быть товаром и стал услугой (сервисом) в подавляющем большинстве случаев. Этот переход был плавным и постепенным и выделить момент, когда было так, а стало сяк нельзя.

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

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

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

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

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

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

Ребята, нас тут всех приглашают на «RM Вечорниці/RM Online Evening» в эту субботу, 25 июля в 21:00 по киевскому времени.

Программа:
21:00 - Приветствие и проверка связи
21:10 - Управление проектом в условиях отсутствия пм’а, Андрей Мосин (укр)
21:40 - Афтепати с темой: Помните как мы волновались о психическом состоянии на третьей неделе карантина? Или способы адаптации к новым условиям современности. (англ, укр, русс)

Объясним почему так поздно решили проводить ивент: чтобы участники и сам спикер с западного полушария смогли к нам присоединиться.

Регистрация здесь https://bit.ly/3jBBcMR

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

Один мой хороший знакомый и по совместительству второй сын моих родителей пишет игру. Пристально и с интересом слежу за процессом. Следите и вы:

@SyncopeTheGame

Когда в руках микроскоп, всё вокруг кажется гвоздями.

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

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

Да, очень часто решение лежит не в той плоскости, в которой вот конкретно вам всё видно и можно что-то изменить. Отсюда и микроскоп в руках, когда вокруг одни гвозди.

Особо страшно становится, когда появляются инструменты, которые одинаково плохо решают вообще все задачи, вроде Экселя. Более-менее освоив эксель (или гугловы спредшит), все проблемы начинают казаться просто набором табличек с формулами.

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

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

Первый — это когда «твоя работа в этом и заключается»:

— Я настроил вон там автоматический процесс, хотя всю жизнь там было всё вручную.
— Это и есть твоя работа.
— Я увеличил конверсию вон того, и у нас теперь больше чего-то там и там.
— За это тебе и платят зарплату.

Второй контраргумент — «это не твоё дело».

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

Третий — «этого не достаточно». Понятно без примеров.

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

———
Эксперимент: тема зарплат продолжится другими постами, если наберется суммарно 100 любых реакций под этим постом.

Ну ничего себе как я недооценил интересность темы! Ладно, давайте продолжим с тегом #экстразарплата.

Главная ошибка всех таких писем о расхваливании себя любимого — это расхваливание своих бывших заслуг. Логика работодателя вполне простая: сотрудник делает своё дело, в конце месяца получает за это деньги. И так каждый месяц. Договорённость о зарплате — это обещание заплатить столько-то денег, когда боец сделает столько-то вот такой вот работы. Это не делёж награбленного на приратском судне, где сильные и авторитетные пираты получат больше, это не признание опытности и любви к сотруднику. Это всего лишь договорённость об обмене труда на деньги.

Из вышесказанного естественным образом вытекает простое следствие.

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

Скажем, ваша зарплата $1000 и вы хотите 10% повышения. Работодатель знает, что найти вам замену можно за месяц и еще месяц уйдет, чтобы освоиться новому сотруднику. Отказав вам, вы начнёте искать работу и будете её искать где-то месяц. Получается, уволить вас будет стоить $2000, а повысить вам зарплату будет стоить $1200 в год. Значит руководству выгоднее повысить зарплату, чем лишиться вас.

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

Продолжаем про зарплаты и повышения.

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

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

У этого «честного» поминутно тарифицируемого подхода лишь одна проблема — критерием успешно проведённого дня будет считаться количество отработанных часов. Типа, «я сегодня молодец, отработал 8 часов».

В итоге честно для разработчика, честно для компании, удобно для повышений, но в итоге всё-равно фигня.

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

Привет, ребята.

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

Спасибо, всех обнял.

Тут знакомые зарелизили один полезный инструмент. Помогает группе людей определиться со временем при организации ивента.

Он не подходит для случаев, когда есть список четких опций. Но в ситуациях, когда надо просто собраться все равно когда и все равно во сколько, но главное — чтобы вместе, инструмент подходит идеально:
https://letmeknowwhen.space/

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

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

#dimoneverything

Закончить ремонт нельзя, ремонт можно только остановить.

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

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

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

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

В общем, я тут сделал штуку одну. Я это называю творческим поиском, а жена утверждает, что это кризис среднего возраста. Я написал фантастический рассказ с названием «Неотличима от магии».

Расскажите что думаете анонимным лайком или неанонимным текстом в чатике. Приятного чтения.

https://docs.google.com/document/d/1AGrvIggFFpCyzaUaW3vGO3umrO6e576Jsdt5Jk8vwqM/edit

Недавняя переписка в чате домоуправления (осбб) натолкнула меня на один вывод. Дело было так.

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

Смотрел я, значит, на это вот всё и подумал про аджайл. Типа, оно ж для искоренения таких вот проблем и существует же? И вот этот вот пример, как и сотня других примеров из ваших подобных чатиков — это как бы гиперболизация того, что могло бы произойти у нас, программистов, на работе.

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

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

Есть два очень хороших критерия определения самостоятельности разработчика.

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

Обратная сторона медали подхода — некомпетентность. Её очень часто вменяют менеджерам, которые не разбираются в том, чем управляют. Типа, «нужно вот тут добавил дропдаун с вот такими значениями», вместо объяснения зачем это вообще надо и какую проблему оно пытается решить, чтобы найти самое

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

Скорее всего каждый из нас склонен либо к декларативному либо к императивному способу изъясняться и это нужно исправлять. Посмотрите на свои последние сообщения и определите свой стиль изложения. Декларативщикам нужно стараться быть более императивными и наоборот.

К слову, этот пост есть демонстрацией объединения этих подходов.

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

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

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

Не зря говорят, что правильно заданный вопрос — это половина решения.

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

Главное правило написания таких вопросов — начать с конца и думать какие наводящие вопросы собеседник задаст и отвечать сразу и на них.