Три не самых очевидных совета начинающим разработчикам
Вы без труда найдёте множество материалов с советами стажёрам, начинающим разработчикам, аналитикам и другим IT-специалистам. Большинство из этих советов давно известны. Мы, в свою очередь, решили обратить внимание на неочевидные с первого взгляда факторы успеха в IT — и собрали нестандартные советы от руководителей из разных отделов.
Кандидатам на стажировку: не дайте себе пропасть
Игнат Колесниченко, руководитель одной из групп разработки MapReduce-системы Яндекса:
Я иногда общаюсь с людьми, которые стажировались за пределами Яндекса, в других компаниях. От них я слышу странные истории: что фирма наняла себе стажёра, а потом стажёр оказался брошен и не знал, чем ему заниматься в течение месяца (а это треть стажировки). Для меня это удивительно. Понятно, что мне легко говорить: у меня пять подчинённых, и общаться с шестым для меня — небольшая нагрузка. Но странно, когда у человека 50 подчинённых, стажёр в личном подчинении, и у этого стажёра нет отдельного куратора.
Так что если вы устраиваетесь на стажировку, уточните у будущих руководителей, кто будет вашим куратором. Если куратор — сам руководитель, аккуратно спросите, сколько людей будет в вашей команде и как часто вы и он будете общаться. Вам необходим куратор, с которым можно обсудить все текущие вопросы хотя бы раз в два-три дня, не считая общения с другими коллегами. Сам я стараюсь через день подходить к стажёру и узнавать, как дела.
На стажировке вас ждёт много специфики, в которой не разобраться в одиночку, а ещё вам правда нужно занять себя — только так вы получите достаточно пользы. Если вы остались без задач — обсудите новые с куратором.
iOS- и macOS-разработчикам: посетите самую главную конференцию
Ася Свириденко, руководитель группы разработки Яндекс.Почты для iOS:
Постарайтесь побывать на Worldwide Developers Conference. В первую очередь, съездить на WWDC полезно, потому что ты можешь прийти в лабораторию и поговорить с инженерами, особенно если у тебя есть вопрос, на который никак не удаётся найти ответ. В последний раз я ездила на WWDC, когда работала в команде библиотеки речевых технологий SpeechKit — и большую часть конференции провела в лаборатории по аудио. Познакомилась с очень интересным человеком, который уже 24 года в Apple, проектировал первую версию фреймворка Foundation, разрабатывал аудиофреймворки и хорошо чувствовал мою боль.
Вторая причина заключается в сообществе. Оно очень много значит. Ты пять суток слушаешь доклады и разговариваешь — даже по ночам в барах — только про разработку. Я вернулась с множеством идей для своих небольших проектов, и этого запала мне хватило ещё примерно месяца на три. Мы все порой начинаем немного теряться в своей работе, она может немного надоедать, а поездка снова заряжает.
Стажёрам: исследуйте, а потом спрашивайте коллег
Дмитрий Черкасов, руководитель группы разработки антифрода:
Стажёры с совсем небольшим опытом, осваивая новые инструменты или подходы, вечно задаются вопросом: какие темы копать самому, а о каких спрашивать коллег или куратора. Проблемы с этим балансом возникают почти у каждого, я всё время с таким сталкиваюсь.
Самый простой и частый пример: внутри компании доступен API отправки каких-нибудь метрик и тебе нужно встроить их отправку в свой код.
Первый крайний случай — когда человек подолгу уточняет буквально всё и у всех. Второй, ещё менее приятный — когда стажёр сидит и молчит до тех пор, пока ты сам у него не спросишь, как дела. Не подойдёшь — не узнаешь, исследует он проблему или ничего не делает. Да, куратору важно не закопаться в собственных задачах и найти ресурс на младшего участника команды. Но вот совет самому стажёру, эмпирическое правило: покопайся какое-то время, а если оно превысило некую константу — иди и спрашивай. Копаться, напрягать собственные мозги, читать чужой код в репозитории полезно, особенно если у тебя мало опыта, — но нужно жёстко себе самому установить временной порог. Чем больше опыта ты приобретёшь, тем ниже для тебя будет эта константа.