Мы решили поэкспериментировать и выпустить пилотный выпуск подкаста c названием «Лямбда Подкаст» и в нём мы, редакцией «Экстраполяции», успели поговорить о двух темах.

1. На чём писать микросервисы.
2. Сколько стоит работать на своей первой работе.

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

Приятного прослушивания.

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

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

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

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

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

Иными словами: не можешь сопротивляться — возглавь.

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

#dimoneverything

«Всегда оставляй код в состоянии лучше, чем он был до тебя»

#dimoneverything

Есть офигенный лайфхак как переключаться с рабочих задач на домашние и наоборот.

Короче, нужно не переключаться. Перестаёшь программировать и идёшь к семье и друзьям, а сам в это время думаешь где в коде лучше модуль вынести, как лучше либу пропатчить и какой бы триггер написать, чтобы от лишнего джойна избавиться. За едой думаешь, перед сном думаешь и в душе под горячей струёй воды тоже думаешь. А утром, когда надо работать садиться, ты уже как бы в теме и в контекст въезжать не надо.

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

Лучший ajax в моей жизни назывался .js.haml. Это было офигенно. Потом я отвернулся, потом я как-то гастролировал с FRP, а потом произошло вот это: https://github.com/reduxjs/redux/commit/9276ff0af6400633d6731b15fed6e70c3561887e

#dimoneverything

Короче, у меня тут ситуация, ещё круче той, что Дмитрий описывал, помните?

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

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

В общем, я в шоке, этому сейлзов молодых учат?

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

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

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

Сова и глобус.

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

Конечно, если брать офисные процессы и пытаться по ним жить на удалёнке, то безусловно работа в офисе окажется лучше.

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

https://telegra.ph/Zlodei-05-15

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

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

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

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

Некоторые такие подсказчики не ставят амбициозных целей и пытаются бить наверняка, подсказывая имена даже новых переменных по первой букве, всякие устоявшиеся конструкции, вроде has_many :projects, если рядом есть класс Project и всякие for i++ конструкции. Это здорово помогает и экономит время.

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

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

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

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

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

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

4. Некий базовый набор знаний все-таки получить можно, но он настолько фундаментален, что легко учится самостоятельно. Гит, основы юникса, алгоритмизация, немного математики. Плюс ещё некие основы для конкретной профессии. В веб-программировании, например, нужно понимать html, css, http и все такое прочее.

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

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

#перечитываяэкстраполяцию #экстраакадемия

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

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

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

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

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

Пока существуют люди, которые не могут однозначно сформулировать задачу, существуют и программисты. Так-то.

С 0x100 праздником, коллеги!

Совершенно очевидно, что за работу программиста нужно платить. Уже менее очевидно, но все ещё достаточно понятно сколько конкретно нужно платить тому или иному программисту. И совершенно неочевидно и совсем запутанно с тем, что же ещё влияет на желание работать и продуктивность разработчика.

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

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

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

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

#перечитываяэкстраполяцию

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

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

Вывод: хочешь освоить что-то новое, сделай так, чтобы от этого зависело твоё выживание.

У меня весьма странный способ познавать и изучать новую информацию.

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

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

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

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

У кого ещё какие способы? Делитесь в чатике.