Pull to refresh

Семь лет работы разработчиком: какие уроки я извлёк

Reading time 3 min
Views 21K
Original author: Tomasz Łakomy
Время летит, правда?

Моя карьера началась в 2012 году, с первой стажировки по C++. Честно говоря, я понятия не имел, что делаю (на самом деле, ничего не изменилось). Однако я извлёк несколько уроков.

Отказ от ответственности: в этом сообщении не будет никакого кода.

Вопрос: Какой самый важный язык в программировании?


Это английский. Или испанский, китайский, польский. Любой, какой вы используете для общения с коллегами.

Разговаривать с людьми гораздо важнее, чем с машинами


Программирование — командный вид спорта. Редко встречается блестящий продукт, созданный с нуля одним человеком (CodeSandbox — отличный пример, хотя Айвз в последнее время нанял пару сотрудников), но в подавляющем большинстве случаев нужна команда.

Навыки общения способны спасти или похоронить проект. Не волнуйтесь, проблема не только у вас, даже НАСА страдает из-за этого.

Профессиональные и коммуникативные навыки могут быть важнее для успеха проекта, чем чисто технические. Кого волнует, что вы наняли пятерых лучших в мире экспертов по базам данных, если они отказываются разговаривать друг с другом, а в итоге вы получаете пять различных экземпляров MySQL, Aurora и MongoDB.

Нужно глубоко понять, что вы разрабатываете и почему


Большинство людей становится счастливее, когда у них появляется цель. Это относится и к работе.

Ваша цель как разработчика — не переводить JIRA на JavaScript, Trello на C# и т. д. Ваша цель — решать проблемы.

Если у вас глубокое понимание системы, которую вы строите/поддерживаете, то вы можете принимать решения за пределами чисто технологий. Задавайте вопросы: эта функция вообще необходима? Какую проблему она решает? Можем ли мы решить эту проблему по-другому? Мы хотим решить эту проблему в первую очередь?

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

Если код-ревью вызывает стресс, то оно ужасно, ужасно неправильно организовано


О, боже. Проверка кода.

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

Я лично видел людей, отправляющих код-ревью специально в тот момент, когда X не было в офисе или Y был в командировке. X блестящий программист, но трудно выдержать его код-ревью. Полсотни придирчивых комментариев под пул-реквестом джуниора вовсе не доказывает ваше превосходство в качестве разработчика. Это доказывает только вашу недобрую натуру.

Хорошо, но что мне делать, когда эта функция полностью сломана?

Встать. Связаться с этим человеком, поговорить лично. Поговорите с ним, узнайте, почему он реализовал код таким образом.

Большинство людей не хотят писать плохой код. И если они это делают, вероятно, имеют дело с ограничениями, о которых вы не знаете. Они также могут быть не очень хороши в программировании (пока), и здесь вы можете проявить себя как наставник.

Что-нибудь ОБЯЗАТЕЛЬНО пойдёт не так, будьте готовы


Согласно Википедии:

Закон Мерфи — это пословица или эпиграмма, которая обычно гласит: «Всё, что может пойти не так, пойдёт не так».

Это одна из тех вещей, которые слишком верны. При проектировании системы всегда предполагайте какой-нибудь сбой.

Если создаёте форму входа в систему — предположите, что люди скопируют и вставят в поле пароля текст целой книги.

Если создаёте окно WYSIWYG, предположите, что кто-то попытается его сломать, и, вероятно, сможет сделать это.

Если у вас база данных, в какой-то момент она будет отключена. Если вы не протестировали восстановление базы данных из резервной копии, это не резервная копия.

Если вы готовите демонстрацию перед аудиторией — убедитесь, что демо работает онлайн, офлайн, вверх ногами и под водой.

Не бойтесь сказать «Я не знаю»


Самая приятная привилегия титула «сеньор» на бейдже — наконец-то, возможность ответить:

Не знаю, никогда не пробовал. Я посмотрю и перезвоню вам.

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

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

Учитесь на публике


Как только вы переходите от «Я не знаю» к «Хорошо, это было интересно» — поделитесь с кем-то. Напишите в блог, запишите видео, поговорите на мероприятии по обмену знаниями или просто… скажите кому-нибудь. Если думаете, что-то всем очевидно, это не так. Даже лучшим профессионалам есть чему поучиться у новичков, и наоборот.

Преподавание — невероятно эффективный способ убедиться, что вы действительно понимаете предмет, о котором идёт речь.

Как сказал кто-то чертовски умный:

Когда учит один, учатся двое.

А вы какие уроки извлекли как разработчик?
Tags:
Hubs:
+27
Comments 14
Comments Comments 14

Articles