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

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

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

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

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

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

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

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

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

Конечно, не стоит вообще даже начинать думать об этом термине, встречаясь в подворотне с джентельменами в спортивках.

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

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

Сегодня я опять о версталах. Фронтэндер с парой лет опыта (что уже довольно много по современным сеньорным оценкам) пришел в профессию уже когда react.js и angular.js существовали. Для него, молодого, это что-то такое естественное и незыблемое, что было, есть и наверное будет всегда. Кроме того, засилье разнообразных способов подготовить статические файлы для вашего сайта продолжается и не собирается останавливаться. Вспомните только количество современных вебпаков! И да, современный верстальщик ко всему прочему еще и верстать уметь должен.

Кстати, пользуясь случаем верстальщической темы, взаимно порекомендую телеграм-канал, который сам с удовольствием читаю: @front_end_dev. Там можно увидеть новости мира верстки и браузерного программирования до того, как они появится в менее поворотливых медиа-ресурсах.

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

Выходные — зло. Затянувшиеся выходные — затянувшееся зло.