Время летит, правда?
Моя карьера началась в 2012 году, с первой стажировки по C++. Честно говоря, я понятия не имел, что делаю (на самом деле, ничего не изменилось). Однако я извлёк несколько уроков.
Отказ от ответственности: в этом сообщении не будет никакого кода.
Вопрос: Какой самый важный язык в программировании?
Это английский. Или испанский, китайский, польский. Любой, какой вы используете для общения с коллегами.
Разговаривать с людьми гораздо важнее, чем с машинами
Программирование — командный вид спорта. Редко встречается блестящий продукт, созданный с нуля одним человеком (CodeSandbox — отличный пример, хотя Айвз в последнее время нанял пару сотрудников), но в подавляющем большинстве случаев нужна команда.
Навыки общения способны спасти или похоронить проект. Не волнуйтесь, проблема не только у вас, даже НАСА страдает из-за этого.
Профессиональные и коммуникативные навыки могут быть важнее для успеха проекта, чем чисто технические. Кого волнует, что вы наняли пятерых лучших в мире экспертов по базам данных, если они отказываются разговаривать друг с другом, а в итоге вы получаете пять различных экземпляров MySQL, Aurora и MongoDB.
Нужно глубоко понять, что вы разрабатываете и почему
Большинство людей становится счастливее, когда у них появляется цель. Это относится и к работе.
Ваша цель как разработчика — не переводить JIRA на JavaScript, Trello на C# и т. д. Ваша цель — решать проблемы.
Если у вас глубокое понимание системы, которую вы строите/поддерживаете, то вы можете принимать решения за пределами чисто технологий. Задавайте вопросы: эта функция вообще необходима? Какую проблему она решает? Можем ли мы решить эту проблему по-другому? Мы хотим решить эту проблему в первую очередь?
Такое иногда называют бизнес-контекстом, но если вы хотите хорошо выполнять свою работу, то нужно не только понимать контекст, но иметь возможность формировать и влиять на него. Чтобы влиять на продукт, необязательно занимать руководящую должность в организации. По крайней мере, это необязательно для понимания продукта.
Если код-ревью вызывает стресс, то оно ужасно, ужасно неправильно организовано
О, боже. Проверка кода.
Мы действительно не задумываемся, но акт публикации работы с её изучением несколькими другими людьми в чём-то уникален для нашей профессии. Неудивительно, что это вызывает стресс.
Я лично видел людей, отправляющих код-ревью специально в тот момент, когда X не было в офисе или Y был в командировке. X блестящий программист, но трудно выдержать его код-ревью. Полсотни придирчивых комментариев под пул-реквестом джуниора вовсе не доказывает ваше превосходство в качестве разработчика. Это доказывает только вашу недобрую натуру.
Хорошо, но что мне делать, когда эта функция полностью сломана?
Встать. Связаться с этим человеком, поговорить лично. Поговорите с ним, узнайте, почему он реализовал код таким образом.
Большинство людей не хотят писать плохой код. И если они это делают, вероятно, имеют дело с ограничениями, о которых вы не знаете. Они также могут быть не очень хороши в программировании (пока), и здесь вы можете проявить себя как наставник.
Что-нибудь ОБЯЗАТЕЛЬНО пойдёт не так, будьте готовы
Согласно Википедии:
Закон Мерфи — это пословица или эпиграмма, которая обычно гласит: «Всё, что может пойти не так, пойдёт не так».
Это одна из тех вещей, которые слишком верны. При проектировании системы всегда предполагайте какой-нибудь сбой.
Если создаёте форму входа в систему — предположите, что люди скопируют и вставят в поле пароля текст целой книги.
Если создаёте окно WYSIWYG, предположите, что кто-то попытается его сломать, и, вероятно, сможет сделать это.
Если у вас база данных, в какой-то момент она будет отключена. Если вы не протестировали восстановление базы данных из резервной копии, это не резервная копия.
Если вы готовите демонстрацию перед аудиторией — убедитесь, что демо работает онлайн, офлайн, вверх ногами и под водой.
Не бойтесь сказать «Я не знаю»
Самая приятная привилегия титула «сеньор» на бейдже — наконец-то, возможность ответить:
Не знаю, никогда не пробовал. Я посмотрю и перезвоню вам.
Будучи джуниором, я до ужаса боялся: вдруг кто-то догадается, что я самозванец. После пары лет в качестве разработчика — если я чего-то не видел, может, это до сих пор не всплывало. Или просто появлялась ещё одна классная технология, которую нужно изучить. Пожизненное обучение — это не модная фраза, это реальность в IT.
Или я просто невероятный мошенник, сумевший всех обмануть, что я действительно могу делать свою работу. Никогда не знаешь.
Учитесь на публике
Как только вы переходите от «Я не знаю» к «Хорошо, это было интересно» — поделитесь с кем-то. Напишите в блог, запишите видео, поговорите на мероприятии по обмену знаниями или просто… скажите кому-нибудь. Если думаете, что-то всем очевидно, это не так. Даже лучшим профессионалам есть чему поучиться у новичков, и наоборот.
Преподавание — невероятно эффективный способ убедиться, что вы действительно понимаете предмет, о котором идёт речь.
Как сказал кто-то чертовски умный:
Когда учит один, учатся двое.
А вы какие уроки извлекли как разработчик?
Автор: m1rko
