Когда вас вызывать?
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

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

Erlang vs Go
public poll

Go – 36
👍👍👍👍👍👍👍 84%

Erlang – 7
👍 16%

👥 43 people voted so far.

Какие ожидания от этого канала в первую очередь?
anonymous poll

Информация, тренды, палево тем – 54
👍👍👍👍👍👍👍 81%

Поговорить, обсудить – 7
👍 10%

Завести полезные связи – 5
👍 7%

Найти заказчиков – 1
▫️ 1%

👥 67 people voted so far.