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

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

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

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

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

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

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

К стикерам в чатах применимы точно те же правила, так как это все те же картинки.

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

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

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

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

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

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

Как правильно заниматься самолечением такого синдрома:
1. Перестать возмущаться
2. Сформулировать насущную проблему.
3. Задавать вопросы «А почему именно так?»

Не болейте!

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

Самый бедный и несчастный вид разработчиков — это версталы. Как их, бедненьких, только не называли. «Верстальщик», «клиентский разработчик», «браузерный программист», «фронтовик», «разработчик HTML», «джаваскрипт-разработчик» (это самое обидное, на мой взгляд). Гугл вообще переводит это как «разработчик переднего конца».

Сегодня в соцсетях прочитал вообще феерическую формулировку: «Нашему клиенту на аутстафф требуется Фронт Эндщик». Фронт, мать его, Эндщик!

— Ват из йоур нейм, мистер?
— Май нейм из Эндщик. Фронт Эндщик.

Эта формулировка заиграет совсем другими красками, если любого разработчика назвать «эндщик». Попробуйте сами произнести это вслух: «биг дата эндщик», «си эндщик», «питонэндщик».

Хорошего дня, эндщики!

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

А что касается нас, айтишников, то такое встречается сплошь и рядом и, что самое ужасное, считается естесстевнным. Речь о «джаваскрипт-разработчиках» или «питон-разработчиках». Еще более серьезная степень инструментного ориентирования выражается в виде фрейморков или библиотек. «Вордпрес-разработчик», «rails-разработчик» или даже «react.js-разработчик». Гнать таких в шею. Программисты в первую очередь — решатели проблем, и что они используют для решения этих самых проблем, это дело десятое. И формулировать профессию нужно в виде проблемы, а не инструмента, который используется для этого.

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

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

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

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

Ребята, нас уже больше пятиста человек! Ради такого события и эмоджи можно поставить. Вот оно: 🎉 (или эмоджи — это «он»?).

Я очень рад, что заметки в этом канале читают и невероятно приятно, что нас становится все больше и больше. Хотелось бы услышать пару слов и от вас тоже. Мне будет очень приятно, если вы напишете пару строк мне лично. Расскажите что вам нравится в этом канале, а что вам не нравится в канале и что стоило бы улучшить. Спасибо вам. Пишите: @aratak.

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

И ещё повод гордится кодом может найтись совсем не там, где приложение его предполагает.

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

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

Есть офигительно красивое и умное слово, которое объясняет достаточно простую и очевидную штуку. Если нечто может быть вызвано несколько раз подряд, и это ничего не сломает и результат всегда будет один и тот же, то это нечто обладает свойством «идемпотентность». Это свойство применимо как правило к куску кода, будь то метод класса, процедура, скрипт или отправка http-запроса. Если метод класса меняет объект каждый раз, как вызывается, то он не идемпотентен. Допустим, метод увеличения числа на единицу не идемпотентен: a.increment(). А вот метод, который разрешает пользователю вход в систему, как правило, идемпотентен: user.approve().

Идемпотентность критична, когда это применимо к какому-либо независимому состоянию, например база данных или сервер. Скрипт echo 'hello' > 1.txt — идемпотентен, скрипт echo 'hello' >> 1.txt — нет. Еще одним хорошим примером важности этого свойства служат GET и POST запросы. Все, что идемпотентно может быть сделано через GET. Неидемпотентные операции делать лучше POST-подобными запросами.
В результате можно вывести правило, что ваш код должен быть идемпотентен чуть менее, чем полностью за редким исключением.

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

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

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

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

Кстати, у эмоджи есть специальный символ хаоса, применимого к коду: «💩»

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

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

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

Еще сейчас сильно извратили понятие "MVP", что в расшифровке означает «минимально жизнеспособный продукт» (согласитесь, русская аббревиатура «МЖП» звучит как-то колоритнее английского аналога). Купленный домен и страничка на вордпрессе — это не МЖП, это всего лишь картинка продукта. Прям как у Джека Воробья с его картой сокровищ.

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

Да, да. Вы правы. Капитана Джека Воробья.