Подражая Морейнису

Мечта - это вовсе не мысли о чем-то прекрасно. Мечта - это то в направлении чего уже движется ваша жизнь.

@maslennikovdm рассказывает про гугловые практики разработки!

Типы ситуаций для вызова внешних экспертов:

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

Эвакуатор
IT отдел все время “косячит”. Срывают сроки релизов. Не могут пофиксить баги или фиксят, но новых появляется больше. Сервис все время падает, не доступен или слишком медленный. Учредителю объясняют это тем, что “так везде” или какими-то неправдоподобными причинами. Он хочет понять правда ли это, так как сам в этом не разбирается.

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

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

Когда вас вызывать?
public poll

Эвакуатор – 12
👍👍👍👍👍👍👍 33%

Потушить пожар – 8
👍👍👍👍👍 22%

У меня нет времени. Не трогайте меня! – 7
👍👍👍👍 19%

Регулярный техосмотр – 5
👍👍👍 14%

Всегда!!! – 3
👍👍 8%

Предстартовая подготовка – 1
👍 3%

👥 36 people voted so far.

Волынкин Николай @Nick_Volynkin поднимает в своём канале @docops одну из фундаментальных проблем в современной разработки, актуальную для компаний любого размера, начиная от стартапов и заканчивая многослойными большими корпорациями: как замапить код и его изменения на требования бизнеса.

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

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

Рекламирую работу @YaviKosh Виктории Кошелевой, трудившуюся над моей скромной персоной упорно и кропотливо, строя настоящего мультяшного персонажа в стикерах для телеги!

Стикер пак: https://news.1rj.ru/str/addstickers/ctorecords

Вопросы про найм людей:

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

Опять Морейнис жжёт! Знакомая проблема?

"У нас в бэклоге есть много задач, которые мы реализуем, но очень медленно. Что делать? Искать инвестиции на увеличение количества разработчиков? Как-то разделять задачи по приоритетам – но как?".

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

2. Как ни странно – 2. Увеличение количества разработчиков на реализацию одной фичи, скорее всего, увеличит время разработки этой фичи. Эффект, подмеченный еще Бруксом в "Мифическом человеко-месяце".

3. Единственный совет, который можно дать в такой ситуации – разделить все задачи на три категории.
– Первая категория – реализация фич, которые уверенно дадут вам улучшение конверсии. Эта уверенность базируется на их очевидности. Следствие из очевидности – увеличение конверсии будет ожидаемым, но не критичным.
– Вторая категория – фичи из серии "Хрен его знает, но это может быть круто". Мы не знаем, сработает это или нет. Но, если сработает – конверсия вырастет в разы.
– Третья категория – фичи из серии "Полезно, красиво, удобно, нужно".

4. Так вот, в первую очередь надо реализовывать задачи из второй категории. Потому что этап стартапа – это этап проверки рискованных гипотез. Только в них заложен шанс на взрывной рост.

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

6. А вот задачи из третьей категории вообще не надо реализовывать. Никогда.

GraphQL
public poll

Что это? – 22
👍👍👍👍👍👍👍 54%

Не панацея, как оказалось :( – 8
👍👍👍 20%

Хочу попробовать! – 6
👍👍 15%

Рулит!!! – 5
👍👍 12%

👥 41 people voted so far.

fb.com/rulezguy Денис Степанов пишет про unixtime:

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

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

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

Говнокод

Все знают, как правильно работать, но ни кто правильно не работает. Ваш Кэп.

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

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

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

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

Пока не прожуете весь говнокод, нельзя расслабляться. Чередуйте порции говнокода и с заказами бизнеса. Держите ритм.

Говнокод - это опасно.

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

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

https://www.youtube.com/watch?v=xgaff9DDUAA
Существующая кодовая база 99% проектов - выжженная земля покрытая трёхметровым слоем говна.

Но есть надежда...

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

Иногда нужно быстро запилить эксперимент, проверить идею, а если взлетит, нужно рефакторить.

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

Основные проблемы как раз на этапе, когда взлетело! Нужно набирать народ, а люди реально демотивируются говнокодом. На всё готовенькое хотят :)

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

Поскольку общепринятого определения "качества кода" все едино нет, можно ввести определение - если дает масштабироваться (по той метрике, по которой нужно масштабироваться), то значит хороший годный код.

Причём очень важно не превратится рефакторинг кода в мастурбацию (когда не кончают), - это также может загубить проект.


Авторы: Илья Чесноков, Макс Крентовский, Алекс Тутубалин и другие

fb.com/planerist Саша Зверев рассказывает про мировоззренческую книжку про найм:
https://www.amazon.com/Hire-Your-Head-Performance-Based-Hiring/dp/0470128356

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

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

Главный вопрос, как это измерить на интервью. Не писать в вакансих "высшее образование" или "опыт 5 лет разработки на Java", отсекая таким образом клёвых кандидатов. Если кандидат может что-то делать, что вам интересно, то очевидно он уже умеет нужную вам квалификацию. Таким образом важно измерять то, что кандидат сделал в прошлом.

Мои хорошие друзья разыскивают трушного бекенд-разработчика #php на фултайм удалёнку

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

Определение трушности php разработчика:
* Ментальное программирование - к Твоему коду не требуется документация
* Ты сможешь объяснить на собственном опыте, что такое SOLID
* DDD
* Опыт написание функциональных, юнит и аксептенс тестов
* Опыт работы в разных парадигмах программирования (как минимум функциональное и процедурное)
* Опыт разработки на как минимум ещё одном языке программирования

Как проверить свою трушность?
Прислать мне в личку @r2d2_e2e4 или почту dsimonov@gmail.com резюме и попросить тестовое задание

Используемый стек:
* #Php7 <--- основной язык, склеивающий ниже-описанные компоненты
* #Redis, #Mysql, #Postgresql <--- используются интерфейсами и всем функционалом, который с ним связан
* #Tarantool <---- это используется для очень-очень быстрых принятий решений при интеграции с внешними сервисами
* #Clickhouse <---- сюда складываются исторические данные
* #GraphQL <---- используется, как транспорт данных между компонентами, постепенно замещая REST API.

Что взамен?
* команда профессионалов, которая в фоновом режиме апгрейдит даже просто тех, кто их видел один раз
* высокие нагрузки, бигдата
* признанный на рынке самый лучший продукт (реально все хвалят!)
* супер-лояльная аудитория, которая буквально на руках носит всю команду

FAQ:
- Как ко всему этому прикоснуться и стать супер-мега-ультра-профессионалом?
- Прислать ко мне в личку @r2d2_e2e4 или в dsimonov@gmail.com своё резюме и спросить тестовое задание)

- Какие условия?
- Фултайм удалёнка из любого города России, Украины, Беларуси и всех остальных стран и материков), но работать по московскому времени!

- Какая оплата?
- Месячный фикс (рыночный) или почасовка - по договоренности

На остальные вопросы я легко отвечу в личке @r2d2_e2e4 или почте dsimonov@gmail.com

Знакомые интересуются, что отвечать сотруднику с огромной зп, который забил на работу и спрашивает "зачем мне работать?"