Если собрать 5 гениальных сеньоров в токсичной среде, они напишут идеальный код, который никогда не выйдет в прод.

ℹ️ Здоровая атмосфера в IT-команде - это не совсем про дружбу и печеньки в офисе.

ℹ️ Поэтому мы собрали светофор здоровой команды, который можно попробовать уже сейчас.

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

💬 В комментариях оставили инфографику в высоком разрешении!

📱 Исходный код — подписаться!

Когда нибудь разберемся как на это реагировать, а пока отвлечемся: «на ИИ надейся, а бэкапы делай».

ℹ️ Из каждого утюга кричат, что ИИ вот-вот перевернет индустрию, а кто не внедрил еще вчера - останется без работы.

ℹ️ Собрали короткий тест на доверие. Загибайте пальцы на каждое «да», чтобы проверить, где заканчивается ваш кредит доверия к алгоритмам.

Я готов поручить ИИ:

❓ Написать регулярное выражение, чтобы не гуглить синтаксис.

❓ Сгенерировать «рыбу» для сложного письма клиенту.

❓ Провести рефакторинг куска легаси-кода.

❓ Скопипастить готовый блок логики в проект без моего код-ревью.

❓ Автоматически мержить ветки, если тесты зеленые.

❓ Принять решение об увольнении разработчика на основе метрик из трекера.

💬 Сколько пальцев загнули? Пишем в комментариях! Ставим 👍, если больше одного.

📱 Исходный код — подписаться!

Иногда самое трудное в помощи - не помочь, а объяснить, что помощь действительно работает.

Так началась история проекта «Код в пользу».

Эту историю рассказывает Лиля Брайнис 🎙 - основательница и председательница совета благотворительного фонда «Шалаш».

Часть 1.

⛺️ «Шалаш» в Telegram

Другие детали в комментариях:
➡️ когда появился фонд;
➡️ чем занимается;
➡️ с кем работает;
➡️ какую миссию выполняет.

Все началось в конце 2017 года. Фонд только обретал свою форму, занятия уже шли, и результат, по словам Лили, был виден, но каждый раз оставался один и тот же трудный вопрос: как объяснить родителям, что изменения правда есть?

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

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

⬇️ Вторая часть будет ниже.

Лиля пришла к нам - с этого и началось знакомство фонда с «Кодом в пользу».

Часть 2.

✨ «Код в пользу»

Внутренний проект «Исходного кода», в котором команда помогает благотворительным фондам не словами, а работающими IT-решениями.

🎮 У проекта очень земной принцип: есть конкретная задача от фонда, ее формализуют и превращают в рабочий инструмент.

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

До этого, в Институте образования ВШЭ, Марина Александровна Пинская подсказала Лиле методику измерения мягких навыков у детей - Performance Based Assessment. В основе были рубрикаторы: взрослый наблюдает за поведением ребенка и проставляет баллы.

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

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

В итоге команде удалось собрать именно тот инструмент, который был нужен фонду.

👍 По словам Лили, инструментом пользуются до сих пор, его продолжают поддерживать, а сам он живет уже восемь лет - с 2018 года.

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

🗣️

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

⬇️ Продолжаем исследовать тему благотворительности - сделали анонимный опрос ниже. Будем рады, если поучаствуете!

Вывели 3 сигнала с frontend-разработчиком Ярославом 🎙, чтобы сразу понять: задача выйдет из под контроля.

Обычно задача звучит так:
➡️ «тут на час»;
➡️ «просто добавить кнопку»;
➡️ «потом по месту разберемся».

Дальше внезапно выясняется, что задача тянет за собой половину спринта.

Все обсудили и разбили тему на 3 понятных сигнала, после которых мы бы уже не верили в оценку «быстро».

🗣️ Непонятно, зачем это вообще делать.

Если по задаче нельзя ответить на 3 вопроса:
➡️ что изменится после выполнения;
➡️ кто этим воспользуется;
➡️ как измерят результат.

Скорее всего, это не приоритетная работа, а задача «чтобы была». Она съест время, но не даст понятного эффекта.

🗣️ «Простая правка» живет в легаси или цепляет зависимости.

Фраза «просто добавить поле, кнопку или флаг» почти никогда не означает только поле, кнопку или флаг.

Обычно рядом уже стоят валидация, API, старые сценарии, миграции и последствия для соседних частей системы.

Снаружи задача маленькая. Внутри - длинный хвост.

🗣️ Критерии готовности написаны как настроение.

Например:

➡️

«Чтобы было удобно»

➡️

«как в другом месте»

➡️

«покажи - там посмотрим»

➡️

«если что, потом доработаем»

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

💬 Не укладываемся в кол-во символов, поэтому продолжили в комментариях!

📱 Исходный код — подписаться!