Хабрахабр

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

Время летит, правда?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А вы какие уроки извлекли как разработчик?

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть