Перевод статьи «7 years as a developer — lessons learned».
Вот время летит, правда?
Мой путь в программировании начался в 2012 году, со стажировки (моим первым языком программирования был С++). Честно говоря, я совершенно не имел понятия, что я делаю, и с тех пор это не слишком изменилось. Тем не менее, за прошедшее время я усвоил несколько уроков.
Какой язык имеет самое большое значение в программировании?
Английский. Или испанский. Или китайский. Или польский. В общем, любой язык, на котором вы общаетесь с коллегами.
Говорить с людьми намного важнее, чем с машинами
Программирование это командный спорт. Иногда можно встретить выдающийся продукт, созданный с нуля одним человеком, но в подавляющем большинстве случаев вам нужна команда.
Навыки общения могут спасти или полностью разрушить ваш проект. Но не думайте, что это касается только вас и вашей команды: подобные проблемы есть даже в NASA.
Soft skills профессиональные
навыки может оказаться важнее для успеха
проекта, чем чисто технические. Какой
смысл нанимать пятерку лучших в мире
экспертов по базам данных, если они
отказываются общаться друг с другом, и
в результате вы получаете пять разных
вариантов MySQL, Aurora и MongoDB?
Нужно хорошо понимать, что и зачем ты создаешь
Большинство людей чувствуют себя более счастливыми, если у них есть какая-то цель. Это касается и работы в том числе.
Если вы разработчик, ваша цель не перевести JIRA на JavaScript, Trello на C# и т. д.
Ваша цель – решать задачи с помощью кода.
Имея глубокое понимание системы, которую вы создаете/поддерживаете, вы можете принимать решения, выходящие за рамки чисто технических. Нужен ли вообще этот функционал? Какие задачи он решает? Можем ли мы разобраться с этой проблемой как-то иначе? И, для начала, хотим ли мы разбираться с этой проблемой?
Мышление такого рода порой относится к сфере бизнес-контекста, но если вы хотите хорошо делать свое дело, вам нужно не только понимать контекст, но и быть способным придавать ему форму, влиять на него. Вам не обязательно занимать высокую должность в вашей организации, чтобы влиять на продукт. Или, как минимум, – чтобы разбираться в нем.
Если ревью кода это стресс для вашей команды, то у вас что-то идет не так. Очень сильно не так.
О боже! Ревью кода.
Мы об этом не задумываемся, но выставление своей работы напоказ, чтобы ее проверяли несколько других людей, это довольно уникальная практика нашей профессии. Не удивительно, что весь этот процесс вызывает беспокойство.
Мне случалось видеть, как люди старались отправлять свой код на ревью, когда Х не было в офисе или когда Y был в командировке. Х был выдающимся программистом, но выдержать его ревью было непростой задачей. Если вы оставляете под пул-реквестом какого-то джуниора 50 придирчивых недоброжелательных комментариев, вы показываете не свое превосходство как разработчика. Вы просто выставляете себя не очень хорошим человеком.
Окей, но что же делать, если я вижу, что эта фича совершенно неправильная?
Встаньте. Подойдите к человеку, чтобы пообщаться лично. Поговорите с ним, узнайте, почему он реализовал код именно таким образом.
Большинство людей вовсе не стремятся писать плохой код. И если они это сделали, вероятно, у них были какие-то ограничения, о которых вы не знаете. Также они могут просто не быть хорошими программистами (пока что), а это ваша возможность проявить себя в качестве наставника.
Что-то непременно пойдет не так, и к этому нужно быть готовым
Согласно Википедии, закон Мерфи это шутливый философский принцип, который формулируется следующим образом:
«Все, что может пойти не так, пойдет не так».
Это безусловная истина. При проектировании системы всегда следует предполагать, что что-то может сломаться.
Если вы создаете форму для входа на сайт, ожидайте, что люди скопируют и вставят в поле для введения пароля целую книгу.
Если вы создаете WYSIWYG-окно, ожидайте, что кто-то непременно захочет его сломать, и скорее всего преуспеет в этом.
Если у вас есть база данных, на каком-то этапе она точно «упадет». Если вы не протестировали восстановление базы данных из бэкапа, это не бэкап.
Если вы делаете демо перед аудиторией, проверьте, что оно работает онлайн, офлайн, вверх ногами и под водой.
Не бойтесь говорить «я не знаю»
Я получил приставку «senior» к названию своей должности не в последнюю очередь благодаря тому, что наконец научился отвечать на какие-то вопросы:
«Я не знаю, никогда так не пробовал. Я посмотрю и свяжусь с вами».
Когда я был джуниором, меня ужасно пугало, что кто-то обнаружит, что я жалкий мошенник, только притворяющийся разработчиком. После пары лет работы я осознал, что если я чего-то не видел, то это потому, что до сих пор мне это было не нужно. Или у меня были другие интересные технологии для изучения. Непрерывное обучение это не просто слова, это реальность мира разработки.
Ну, или я просто невероятно талантливый мошенник, сумевший убедить всех вокруг, будто умею делать то, что делаю. Тут никогда не угадаешь.
Учитесь публично
Когда вы переходите от «я не знаю» к «ну, это было интересно», – поделитесь этим с кем-нибудь. Напишите пост в блоге, снимите видео, произнесите речь на каком-то мероприятии по обмену опытом или просто… расскажите кому-нибудь. Если вы думаете, что какая-то вещь очевидна для всех, то зря. Даже самые опытные люди могут чему-то научиться у начинающих и наоборот.
Учить кого-то это невероятный способ обеспечить себе настоящее понимание предмета.
«Когда кто-то учит другого, учатся оба», – кто-то чертовски умный*.
*Поиск в Google показал, что это цитата Роберта Хайнлайна.
А какие уроки извлекли для себя вы, проработав некоторое время на позиции разработчика?
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]