Привет. Меня зовут Варя Домрачева, я выпускающий редактор блога Контура на Хабре. Я хочу лучше понимать, как мне работать, о чем публиковать статьи, что интересно разработчикам. Поэтому мы с одной моей коллегой решили раз в месяц собирать разработчиков в баре в нашем офисе и слушать, как они говорят на важные для нас темы. Назвали это DevBeer.
На нулевой пробный DevBeer пришло порядка 40 человек (мы были ограничены вместимостью бара). Спикерами стали руководители отдела технического качества, руководитель команды функциональных руководителей, функциональный руководитель C#-разработчиков и еще несколько ведущих менеджеров, инженеров и дизайнеров компании.
Тема встречи – обучение разработчиков мидл+ и выше. И вот что мне удалось подслушать.
Способы учиться
У всех разные способы восприятия информации. Одному комфортнее закопаться в скучные пейперы, другому смотреть уроки на Ulearn.
Вспомнили базовую книгу с кабанчиком на обложке, выразили благодарность индийцам за хорошие видеоуроки по гиту. Обсудили, что в целом видеоконтент выбирают больше те, кто помоложе, и те, кто поджуновее. Мидлы и выше не находят пользы в просмотре видео — быстрее и полезнее что-то прочитать.
Многие для обучения стали использовать нейросети. Это удобно: можно спросить конкретный вопрос и моментально получить на него ответ. Использование нейросети в работе может стать мощным трамплином в начале изучения какой-либо темы. Но нужно относится критически и перепроверять информацию, которую выдает ИИ. В кулуарах дополнили, что хоть нейросети и полезны, чтобы задать вопрос, но вот код пока мало кто рискует с ними писать. Можно разве что тренироваться на пет проектах.
Держать в голове цель
Большая разница — расти как специалист на рынке труда и расти как специалист внутри компании. Нужно понимать, прокачиваешься ли ты в вакууме или адаптируешься под контекст конкретной компании, углубляешься в детали.
Нет запроса на какое-то массовое обучение всех и всему, но есть запрос учиться под конкретные задачи. И речь даже не про харды или софты, а про понимание смысла происходящего вокруг. Это гораздо ценнее, чем изучить какой-либо инструмент просто так, без понимания того, зачем он нужен для работы твоей команды прямо сейчас.
А вот чему учиться — зависит от того, что хочет сам человек. Все мидлы+ хотят разного.
Харды мидл+ и сеньоров почти равны
По знаниям в программировании мидл+ и сеньоры очень близки. Одну и ту же задачу они решат за одно и то же время. Но сеньор обложит меньшим количеством тестов (шутка).
Сеньоры решают не задачи, а проблемы. Они берут ответственность и умеют справляться с неопределенностью. А еще — они умеют разговаривать. Вспомнили случай, когда инженеры не затащили задачу просто потому, что поругались в процессе. То есть хардовых скиллов было достаточно, а умения говорить с друг другом и находить компромиссы или даже решения вин-вин — нет.
Конечно, всем хочется просто «сидеть с компом за столом», и это нормально. Но наступает момент, когда придется идти и говорить с другими людьми. Как этому учиться? Готового ответа нет. Можно попробовать преподавать.
С кем и где общаться?
Важно общаться с внешним миром и развивать насмотренность. Например, оценивать на результат работы, продукты других компаний. И если нравится результат, то уже найти, кто это сделал и как. Или можно продолжать общаться с бывшими коллегами, которые ушли работать в другие компании, перенимать их опыт и держать контекст о том, что делают у нас. Еще хороший способ найти новых людей с новыми идеями — сходить на стажировку в другую команду.
Как насчет профильных конференций? Непонятно. По началу, конечно, конференции сильно расширяют твой кругозор, но когда ты уже давно в профессии, гораздо эффективнее поговорить с кем-то в личке. Самые полезные конференции — это камерные мероприятия на 30 человек, где реальная жесть и где честно рассказывают о факапах, а не хвастаются успехами.
Как бы то ни было — важно не бояться общаться. Порой выйти на коммуникацию как будто чувствуется как поражение, что ты самостоятельно не справился с задачей и тебе понадобилась помощь, потому что ты неудачник. Стоит смириться с этим чувством, и написать в маттермост, спросить совет. Всегда найдутся более опытные разработчики или такие же опытные, как и ты, но которые уже решали эту проблему, или хотя бы слышали о том, какие способы ее решить есть. Если эго все-таки не позволяет попросить помощи, пишите в ветку обсуждения «Я уже делаю вот так, у вас есть 15 минут мне помешать!» и помощь придет сама (шутка).
Ни одна нейросеть и ни одна статья не заменит живого человека, который поддержит и поможет. Поэтому суперважно найти и задружиться с хорошими менторами, продолжать держаться за таких людей и искать новых.
Учиться на практике
В обучении работает правило 10/20/70, где 10 — это потребление информации, 20 — общение с другими людьми, а 70 — практико-применимость в решении реальных задач. И не всегда важен масштаб этих задач или, например, размер команды, которой ты управляешь. Важна динамика развития и сложность конкретной ситуации.
Вообще способность решать проблемы — это супернавык, который приобретается методом «прыгнуть в ад и пробовать его потушить». Этот навык очень сильно ценится, но в отличие от тех же основ программирования, увы, быстро исчезает без практики. Поэтому нужно находить способы тренироваться: брать понемногу из того, что есть, постепенно наращивать скиллы.
Для более комфортного «погружения в ад» нужны наставники, которые учат ответственности и порой даже дают человеку облажаться. В процессе обучения наставник вполне может не подсказывать решение проблемы, а намеренно ставить «падавана» в сложные ситуации неопределенности и учить его принимать реальность.
Но тут главный вопрос: какова цена ошибки может быть?
Кругозор
В конечном счете становится всё равно, с каким именно инструментом работать. Реляционные базы данных, нереляционные, MS SQL или PostgreSQL. Если пришло понимание, как всё устроено, это не имеет значение. Всегда можно прочитать доку и разобраться. Главное — это иметь кругозор и знать, какие есть способы решения задач.
Не так важны знания инженера в конкретном стеке. Важны гибкость и навыки проанализировать проблему и найти инструмент, который эту проблему решит. Даже если это уже другой язык программирования — да, бывает и такое.
