Денис Мотин, 18 лет, город — Алматы, Strong Middle Android разработчик
Этим летом мне исполнилось 18 лет. Но в коммерческой разработке я уже три года, а DataArt для меня — третье место работы. Программированию я в основном учился самостоятельно, а фундаментальное образование пока отложил на будущее. Зато кое-какой опыт я уже приобрел, успев поработать и в стартапе, и в аутсорсинговой компании. Пока впечатления остаются свежими, решил рассказать, какие особенности я увидел в коммерческой разработке.
Мои наблюдения могут быть полезны тем, кто еще учится или недавно начал работать в проектах. А возможно, и тем, кто занимается разработкой так давно, что перестал о ней задумываться.
1. Идеальный код — не самое главное
Это может показаться удивительным, но написание кода в коммерческом проекте — второстепенная задача. Главное — решить проблему бизнеса или его конечных пользователей. Факт, который бывает нелегко принять, особенно людям, по-настоящему увлеченным программированием. В этом кроются, например, проблемы некоторых успешных олимпиадников. Придя в коммерческую разработку, они иногда продолжают искать уникальный ультраэффективный алгоритм там, где уже есть проверенное решение.
В 15-16 лет я работал в своем первом стартапе, где других разработчиков просто не было. Конечно, там удержаться от таких попыток было трудно, особенно если я понимал, что все равно уложусь в срок. Но сейчас я изменил позицию: если уж писать что-то свое, то только уникальное, которое готовым решением не заменишь.
2. Вы с продуктом влияете друг на друга
В книге Google Software Engineering объясняется разница между разработкой и инженерией. На самом деле это просто и не связано с демонстративным отказом от готовых и проверенных решений. Если ты пишешь продукт, который будет работать и через десять лет, ты software engineer. Если твой продукт через год нужно будет переписывать — ты software developer.
Остается выбрать, кем из них ты хочешь быть. И помнить о людях, которые будут пользоваться приложением и работать с кодом после тебя. Ну и беречь творческие силы для нерешенных проблем.
3. К командной работе придется привыкать
Много лет я работал один. В 12 лет начал с визуального программирования. Потом были C# и Java, затем HTML, CSS и Java Script, после Android. Я подрабатывал на фрилансе, занимаясь сайтами. Потом в одиночку занимался разработкой на Android в стартапе.
Уже в аутсорсинге я попробовал работу в паре и сразу оценил, насколько совместная разработка, даже вдвоем, отличается. Ты больше не можешь изменить свой код, когда захочется. Потому что не можешь быть уверен, что вмешательство не сломает того, от чего зависит твой коллега.
4. К чужому коду нужно относиться бережно
Многие программисты в принципе не любят смотреть чужой код, он кажется им хуже собственного, просто потому, что он отличается. У меня обычно такая же первая реакция: «Нужно переделать!». Но я стараюсь бороться с этим желанием. Вот привнести в код собственный опыт — совсем другое дело. Круто, когда на ревью предлагают решение, до которого ты мог никогда не додуматься. Главное — научиться формулировать комментарии.
Я бы рекомендовал вместо утверждений использовать исключительно вопросы вроде: «Почему ты выбрал именно это решение, а не воспользовался альтернативным?». Потому что на письме, когда вы не можете сгладить эффекта интонацией, любое утвердительное предложение может выглядеть повелительно и агрессивно.
5. Главный софт скилл — ответственность
Я окунулся в профессиональную среду довольно резко и в совсем юном возрасте. Поэтому для меня стало откровением, что, пообещав сделать работу к сроку, нельзя просто сказать: «Я забыл, у меня не получилось». Нужно было привыкнуть, что за невыполненным обещанием возникают последствия. Не в смысле, что тебя увольняют, наказывают или ругают. А в смысле, что у клиента падает приложение или ваша команда не может вовремя выйти на демо.
6. Софт скиллы — не равны жизненному опыту
Как и любые другие навыки, они формируются из теории, анализа и применения на практике. Просто соотношение этих компонентов здесь обычно будет другим, чем в случае с техническими скиллами. Но и это во многом определяется нежеланием людей изучать теорию, которой о софт скиллах совсем немало. Просто ее мало кто ищет: почти все предпочитают действовать сразу через анализ.
Например, есть книга Роберта Мартина «Идеальный программист», которую, как и другие книги этого автора, правда стоит прочитать всем IT-специалистам. Она как раз в большей степени посвящена взаимодействию с людьми, чем с техникой, и в свое время сильно мне помогла. Можно почитать книги о корпоративной культуре, например, я рекомендую «Никаких правил» от Netflix. Там здорово объясняется, что такое обязательства и почему лучше быть откровенным.
7. Неудача — не означает, что ты самозванец
Наверное, самый важный навык, который я приобрел в коммерческой разработке — не принимать поражения на свой счет. Это особенно необходимо программистам с повышенным чувством вины, чем я сам страдаю. На моей первой работе, в стартапе, помогало, что на мне, как на единственном разработчике, были не только все провалы, но и все заслуги. Приходилось напоминать себе, что не ошибается только тот, кто ничего не делает, а без меня не было бы ни неудач, ни самого проекта.DataArt — международная компания, разработчик программного обеспечения, который никогда не забывает, что работает с людьми и для людей.
