Исходный Код

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

Часть 2.

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

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

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

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

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

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

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

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

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

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

🗣️

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

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

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

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

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

Часть 1.

⛺️ «Шалаш» в Telegram

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чаты, уведомления и постоянные переключения незаметно съедают не только время, но и качество мысли.

ℹ️ В сложной работе это быстро превращается в ошибки, усталость и ощущение, что день прошел в реакции, а не в результате.

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

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

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

После первой части мы поняли, что тема попала не просто в отклик, а в реальную рабочую боль.

ℹ️ Когда команда теряет время, это не всегда про плохое планирование, слабый процесс или нехватку ресурсов. Очень часто узкое место мельче - в том, как люди формулируют задачи, комментарии, запросы и статусы.

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

🔥 Поэтому мы сделали вторую часть с еще 5 частыми кейсами, где коммуникация ломает работу не громко, а регулярно.

В карточках оставили тот же принцип:
➡️ как не нужно говорить;
➡️ к чему это приводит;
➡️ чем заменить.

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

Обычные тесты не показали проблему. Нагрузочный тест показал сразу: под ростом параллельных запросов сервис начал сыпать 403.

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

Разобрали этот кейс без героизма:
➡️ что именно пошло не так;
➡️ как быстро проверили гипотезу;
➡️ какой чек-лист теперь проходим перед каждым НТ.

ℹ️ Если у вас фича трогает сервер, кэш, внешние сервисы или обработку данных, этот разбор стоит прочитать до релиза.

🔗 Читать статью на Хабре!

Семь раз отмерь, а если отрезал криво - приходи с планом Б.

Продолжаем про коммуникацию.

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

Тезис: 

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

Теперь на примере реакции.

❌ Паника:

Мы не успеваем с релизом, база тормозит, клиент будет в ярости!

✔️ Управляемый риск:

При нагрузочном тестировании легла база. Сейчас откатываемся и локализуем тяжелый запрос. Релиз сдвигается минимум на сутки. Вернусь с точной оценкой фикса к 12:00.

💬 Что делать дальше? Рассказали в комментариях.

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