Сложности в разработке: мнения яндексоидов

Женя Карташев, ML-инженер в службе компьютерного зрения

Сложно концентрироваться

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

• Помодоро. Классический инструмент тайм-менеджмента. Много кто им пользуется, я в том числе. Ставлю на телефоне таймер на 30 минут и погружаюсь в задачу, потом пятиминутный перерыв. Обычно я делаю четыре таких слота, после них — один большой перерыв на 15–30 минут.

• ABC-анализ. В его основе лежит принцип Парето: 20% усилий приводят к 80% результата. И наоборот: 20% результата могут потребовать 80% усилий. Например, если у меня много дел на сегодня, я делю их на три группы: A — 20% самых важных задач, B — 30% задач со средним приоритетом, С — наименее важные. Начинаю работу с группы А и максимально фокусируюсь именно на них.

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

Просто писать код недостаточно

Я самоучка: шесть лет назад в интернете не было такого разнообразия курсов для новичков, как сейчас. Раньше даже выбирать не нужно было: если находишь хоть что-то, это уже удача, нужно хвататься и изучать! После курсов я умел писать код, но программы работают не только на нём. Это целая экосистема, в которой нужно уметь разбираться: например, разворачивать окружение так, чтобы твой код работал в изолированной системе. Если пишешь код для приложения, нужно уметь разворачивать контейнер, версионировать процесс разработки, настраивать процессы.

Одно дело — просто писать код: сейчас с этим могут справиться и GPT-технологии. Другое — находить не только те ошибки, о которых говорит компилятор: например, в строке 53 ты перепутал название переменной. Сложные ошибки — это когда у тебя течёт память и непонятно где и почему. Или сам компилятор не понимает, что происходит.

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

Чем выше уровень, тем больше пересечение областей

В разработке есть много подводных камней. Изначально я был специалистом по компьютерному зрению, а сейчас работаю в команде RnD (Research and Development). Мы занимаемся не только разработкой, но и исследованиями: работаем на стыке области компьютерного зрения (CV) и обработки естественного языка (NLP).

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

Раньше я писал только на Python, но на практике мне понадобилось знание C++. Пришлось быстро учиться. Индустрия развивается, и чем больше знает специалист, тем он круче.

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

Арсений Бородулин, стажёр-разработчик в бригаде A/B-тестов рекламных технологий

Страшно ошибиться

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

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

Не видишь результатов

Результат твоей работы не всегда видно. Поначалу тебе дают задачи небольшого объёма. Представьте: вы пишете код, а он, например, не сильно меняет сервис. Это может демотивировать, вызывать чувство бесполезности. Слышал от коллег, что поэтому бэкендеры становятся фронтендерами. Да, можно сменить нишу — или запастись терпением и расти!

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

Саша Паволоцкий, руководитель Яндекс Лицея

Архитектура кода

Разработка бывает разной, и сложности у всех специалистов свои. Я с 1998 года учу детей программированию (постоянно — с 2002) и сам был разработчиком. По моему опыту, самое сложное в разработке — продумать архитектуру проекта таким образом, чтобы иметь возможность переделать её в будущем, если понадобится. Потому что если неразумно спроектировать модель приложения или системы, то при добавлении какой-то новой функциональности возникнут проблемы.

Оптимизация кода

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

Если задача кажется сложной и непонятной, лучше сначала сделать прототип. Пусть он будет странным, кривым и тяжёлым, но с его помощью можно хотя бы начать. Убедившись, что прототип работает, его уже стоит улучшать. Бывает, что доработать прототип не получается. Тогда важно понять, подходит ли он для конкретной задачи. Может, и не нужно тратить время на улучшения сейчас?

Ирек Гиниатов, Android-разработчик приложения Яндекса

В разработке есть много моментов, которые могут выбить из колеи. Я Android-разработчик в команде супераппа, занимаюсь Яндекс Браузером и приложением «Яндекс — с Алисой», поэтому буду говорить преимущественно о мобильной разработке под платформу Android.

Адаптация для разных устройств

Представьте, что вам нужно угодить миллионам пользователей: кто-то сидит на новом флагмане с крутыми фишками, а у кого-то уже устаревший аппарат. Но всем хочется, чтобы приложение выглядело красиво. А ещё у Android есть несколько версий — и нужно, чтобы всё работало идеально и на стареньком телефоне с Android 7, и на новом современном девайсе.

Как справиться? Важно держать под рукой несколько моделей телефонов, чтобы проверять, как приложение на них выглядит, — это первое. Второе — не перегружать интерфейс, ведь красота в простоте.

Работа в команде

Бывает, что разработчику приходится не только решать технические проблемы, но и договариваться со смежными специалистами: дизайнерами, тестировщиками, менеджерами. У каждого свой взгляд на проблему и требования. Например, дизайнеры могут принести вам макеты, которые красиво смотрятся в Figma, но реализовать это на устройстве будет сложной задачей с морем нюансов. Если дизайн слишком сложен для реализации, важно уметь доходчиво объяснить коллегам, почему это невозможно, и предложить компромиссные варианты.

Задачи большого объёма

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

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