Когда сразу понял, чем меня зацепить.

UPDATE: Актуализировала навигацию в канале

Прошерстила все посты и собрала самое полезное.
Проверьте, вдруг что-то пропустили.

// больше писать не нужно

нужен фронт для верстки пары страниц в полике
если получится взять в работу задачу в ближайшее время - напишите мне @ekondratyyeva

Полиморфер: вклад в развитие студентов

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

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

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

По факту я использую тот же подход, что и в своем карьерном ведении. Буду рада тем, кому моя стратегия откликнется и кто захочет присоединиться к нам в команду преподавателем)

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

Замечаю у новичков одни и те же ошибки в работе на первом коммерческом проекте - ставьте 🍓, если интересно разобрать.

Что было в найме за апрель?

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

Рынок мертв и уверенные разработчики не могут найти работу, не то, что ребята без опыта.

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

То есть 4 человека в апреле успешно вышли на работу, несмотря на непростую ситуацию на рынке.

Подробнее про их офферы

В новом проекте освоится намного проще, когда вместо чтения всего подряд, следуешь инструкции

Вот мой подход:

1. Понять контекст
Что делает сервис? В каких бизнес процессах участвует? С кем интегрируется?

2. Посмотреть на данные
Какой ubiquitous language у сервиса? Как сущности связаны между собой?

3. Разобрать основные сценарии
Берём 3–5 самых часто используемых ручки и дебажим цепочку обработки

Простая цепочка действий, в разы ускоряющая онбординг в проект 🤷🏻‍♀️

🍌 если нужен разбор подробнее на конкретном примере
🌭 если такое мы уже знаем

тебе осталось 6 минут жизни на земле
твои действия?

Трушная разработка - какая она?

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

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

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

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

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

Казалось бы, логично: работодатель хочет человека, который уже делал похожие задачи.

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

Но у технической разработки выше порог входа.

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

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

Хочу сегодня поговорить про обесценивание своих же результатов

Все заключали эти договоренности со вселенной: я добьюсь цели X и тогда все изменится, все увидят, на что я на самом деле способен.

И в итоге по достижению цели ожидания не совпадают с действительностью.

Видели бы вы расстроенные лица моих близких, когда я получила первый оффер в айти или когда пробила зарплатный потолок 400к. Для меня эта реакция тогда была неожиданной.

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

Никто не оценил, сколько работы было мной проделано, чтобы Полиморфер появился на свет.

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

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

И это нормально. Это правило жизни: никто не заметит успехи, но все подметят ошибки.

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