Недавно от коллеги услышал замечательный отзыв: «Понравилось, но поделиться с друзьями желания не появилось». Шикарное определение контента средней сомнительности. Ну, вроде бы неплохой пост, и до конца дочитал, но вот поделиться тем, что тебе этот контент понравился стыдно. Значит пост не такой уж неплохой, выходит.

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

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

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

Ведущий нашей постоянной рубрики Дмитрий комментирует последнюю запись «Экстраполяции», мол не всегда «Понравилось, но порекомендовать не смогу» — это плохой пост.

««Понравилось, но порекомендовать не смогу» — это как после визита в БДСМ бордель», говорит Дмитрий. Просто не хочется, чтобы кто-то знал.

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

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

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

Свой вариант ответа я напишу следующим постом, а сейчас хочу попросить вас прислать мне (@aratak) свой личным сообщением. Я уверен, что ваши версии будут не менее захватывающими, чем моя.

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

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

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

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

Два варианта были, прям, шикарные:

Несмотря на иронию, очень понравился вариант «Knowing when to put off the keyboard and go to bed is one of the best skills you can get as an engineer».

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

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

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

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

​​Ребята, это фронтенд у нас сейчас такой или что-то конкретно с этим кодом не так? Голосуем, интересно ваше мнение.

Технический пост.

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

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

upd: две одинаковые иконки заметил, но отредактировать их уже нельзя. Ориентируйтесь по левой-правоой.

🧚🏾‍♀️ - люблю нажимать на кнопочки в опросах.
☠️ - не отношусь к айти вообще.
🤖 - работаю в аутсорсе/фрилансе.
👾 - работаю в продуктовом проекте.
👨‍💻(левая) - активно учавствую в опенсорсе.
👨‍💻(правая) - работаю над своим проектом в свободное от основной работы время.
👨🏻‍🔧 - работаю над своим проектом в качестве основной работы.

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

Самое страшное в таком вот проекте — это неопределенность. Работать с таким проектом, как общаться с множественными личностями Билли Миллигана — каждый раз большая загадка что ждет в следующей строчке повествования. Каждый следующий разработчик видит какой ужас происходит в исходном коде вот этого вот файла и старается новый код писать, как ему кажется, хорошо, чем только усугубляет ситуацию, ведь до него проект был написан в N стилях, а теперь он написан в N+1 стилях. И абсолютно неважно насколько неправы предыдущие разработчики и насколько прав текущий.

Вот вам несколько правил работы с такими вот унаследованными проектами:

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

2. Рефакторить код, на который нет тестов недопустимо. Объяснение очевидно.

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

4. Если хочется рефакторить во время исправления багов, то сначала выполняем пункт 3. Сначала тесты, потом рефактринг, потом фиксы. Или сначала тесты, потом фиксы, потом опять тесты, потом рефакторинг. Отдельными пулл реквестами и в строго такой последовательности.

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

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

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

8. Поделитесь этими намерениями с коллегами и убедитесь, что вы с ними на одной волне. Если они не хотят вам помогать в стандартизации, то пусть хотя бы не мешают и примут эти правила. Можно взять вот это сообщение и отправить в рабочий чат с предложением вроде «Как раз про наш проект рассказывают. Давайте так сделаем?». С большой радостью услышу возражения и отговорки коллег, если конечно же такие будут.

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

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

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

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

Короче, я называюсь Chief Architect, старший (!) архитектор. А сам лупашу рельсы с реактом, ноль подчинённых, планирую свои фичи, в общем-то даже редко привлекаюсь к серьёзным разговорам «как нам обустроить проект». Так по сути разработчик нужен, и настоящим архитекторам как-то унизительно работать выходит.

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

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

И архитекторство воспринимать нужно именно так. Разработчику платят, называют «Старший Архитектор» за то, чтобы когда задача занесёт его в Реакт, внутренности Постгресса, bulk sql insert, тензорфлоу, заверстать футер, написать гем, написать свой редис, организовать параллельные вычисления с разделяемым ресурсом, собеседовать человека, починить кусок php, решить проблему segmentation fault, задеплоить в амазонон с клауд формейшен и лоад балансером, настроить докер — то разработчик бы не сказал, что этого делать не умеет, а всё сделает как надо. Это немного мешает жить, потому что таким разработчикам непозволительно говорить «я этого не умею/не знаю». И у меня не спрашивают «Дмитрий, как у вас с этим», а сразу назначают задачу. Иногда приходится туго (обычно это с футерами), но положение обязывает.

Ребята, судя по опросу, четверть всех нас тут так или иначе делают свои проекты. Это невероятно круто и у вас наверняка есть что рассказать о своих проектах, продуктах и оупенсорсе.

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

Познакомился с таким замечательным термином, как «период полураспада знаний». По ссылке там, конечно говорят о разных отраслях, но нас интересует программирование и IT. Замерять мы, конечно же, ничего не будем, но предположить можно очень просто. Сколько месяцев нужно не менять ничего в проекте, чтобы код в нем устарел? Конечно же учитываем и новые версии библиотек, языка программирования, инфраструктуры и прочего. В качестве мысленного эксперимента представьте абстрактную библиотеку на гитхабе. Сколько времени проект должен быть нетронутым, чтобы его не стоило бы трогать?

Мое субъективное мнение, что период полураспада знаний в программировании составляет 3-4 месяца. Если в гитхаб-репозитории я вижу «last updated 3 month ago», то вряд ли просто так буду её использовать.

https://mi3ch.livejournal.com/2716537.html

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

— Группа отзывов «Правило верное, но период точно не 3 месяца». Ребята, правило работает, а срок полураспада — это моё личное наблюдение. Если у вас другие представления об процессе старения знаний в вашей области программирования, то я с этим поделать ничего не могу. В конце концов, чтобы хоть что-то утверждать, наверное, нужно провести какие-то исследования, скажем, репозиториев на гитхабе. О таких исследованиях мне не известно. Конечне же, период специфичен для ниши. Библиотеки в эрланг экосистеме как правило не трогают очень долгое время и увы там это де-факто на данный момент норма. Норма не к которой стремиться, а которая есть. Примерно похожая история и у хаскеля. А вот эликсир, джаваскрипт или раст меняется очень быстро и там такого постоянства терпеть никак нельзя.

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

— И последняя группа «К черту правило, время последнего обновления библиотеки не должно являться решающим фактором в пользу отказа от использования». Да, не должно и нет, это не является. Но главное, что отдельно взятая библиотека не находится в сферическом вакууме, а зависит от многих других штук, находящихся извне. Язык программирования не стоит на месте, система пакетов тоже меняется, как и поводы пользоваться этой библиотекой. Еще наверняка будут меняться библиотеки, которые находятся в зависимости от текущей и их тоже нужно актуализировать. Так или иначе за этим всем нужно следить, а «last updated 4 month ago» говорит о том, что есть вероятность наткнуться на говно мамонта в процессе подключения этой библиотеки в проект.

Вместо выводов скажу, что профессия у нас с вами тоже не стоит на месте и строгие правила, вроде «e=mc^2» у нас не найти. Задачей каждого является формирование непротиворечивого и самодостаточного набора правил, которого желательно придерживаться. И войдет ли в ваш набор ценностей закон «полураспада знаний» или не войдет — решать вам, но знать о существовании такого правила крайне желательно.

Ребята, лайфхак от «Экстраполяции» под рубрикой #экстрахак

Самый бесполезный и ужасный способ знакомиться на всяких конференциях и митапах — меняться визитками. Даже если на визитках есть ваш портрет и адреса социальных сетей. Визитки можно рассматривать, как способ культурно уйти от знакомства. Типа, «присылай запрос в соцсетях, а там я уже подумаю дружить с тобой или не дружить».

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

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

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

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

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

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

Помните идиому с наточкой топора и вырубкой леса? Ну, в которой абстрактному разработчику некогда наточить топор, потому что лес рубить надо. Тут есть и обратная сторона этой проблемы — преждевременная наточка топора. Топор нужно точить, когда будет точно понятно, что затраты на заточку топора будут окупаться скоростью вырубки леса. А для этого нужно:

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

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

3. Знать когда в следующий раз нужно будет точить топор. Вылизывать код до идеального состояния не нужно никогда, а каждый раз, занимаясь рефакторингом, нужно заботиться лишь о прогрессе следующей задачи. Цель — укоротить время разработки этой однотипной задачи в следующий раз, скажем, в два раза.

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

#экстрапиар от подписчиков, ребята. И начнём мы с очень крутого проекта.

https://github.com/pathephone/pathephone-desktop

Это p2p музыкальный проигрыватель. Использует IPFS для создания распределенного пространства данных. Удивительно очевидный и вообще неуникальный проект. Но вместе с этим это гениальное применение распределённых технологий.

Автор говорит, что этот проект является одновременно и хобби-проектом и демкой для собеседований.

Мне кажется, проект как минимум заслуживает звездочку. А кроме использования по назначению, проект можно улучшать, общаясь в issue-секции и отправляя пулл реквесты.

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

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


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

Мысли вроде бы хорошие, но вряд ли появятся на канале.

Игры в рубрике #экстрапиар.

Мултиплеерная игра на Phaser.js: https://github.com/DmytroVasin/bomber
Автор говорит, что ничего сложного в ней нет, но было интересно потыкать в браузерные игры. А еще он обещал добавить ботов, чтобы можно было бы оценить игру и самому. Но уверен, что ближайшие пару часов после заметки будет возможность поиграть и без ботов.

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

https://dev.to/riter/sql-tests-in-your-smart-framework-48ob