Перевод статьи «50 Things I Wish I’d Known at My First Developer Job (Part 1)».
Я составил список того, что я хотел бы сообщить себе, если бы у меня была возможность вернуться в прошлое, а именно — за несколько недель до того, как я приступил к своей первой работе в качестве разработчика. Список получился довольно длинным, так что я разбил его на две части.
Возможно, вы согласитесь не со всеми фактами, и это нормально, список-то мой. Тем не менее, будет интересно узнать, что вы хотели бы сказать самому себе в прошлом. Поделитесь в комментариях!
1. Большинство людей рады вам помочь
В целом, никто не стремится к тому, чтобы вы провалились. Ваши коллеги и знакомые из сферы разработки обычно хотят помочь вам добиться успеха. Поэтому стоит доверять другим разработчикам и обращаться к ним за поддержкой по мере надобности.
Мне хорошо послужило одно простое правило: всегда исходите из предположения, что у окружающих вас людей самые лучшие намерения.
2. Тесты это ваши друзья
Написание тестов это не всегда просто праздник жизни. Однако мне бы очень пригодилось, если бы на своей первой работе я уделял больше внимания отработке этого навыка.
Во-первых, написание тестов это невероятное умственное упражнение на ограничение проблемы, которую вы пытаетесь решить. В процессе этой работы вам приходится продумывать каждый шаг выполнения задачи.
Во-вторых, написание тестов помогает удостовериться (как вам, так и вашим коллегам), что ваш код делает именно то, что, по вашему мнению, должен делать. Благодаря такому подходу я чувствовал бы себя гораздо увереннее во время нескольких первых пул-реквестов.
3. Никто не знает, что делает
На своей первой работе я сильно страдал от синдрома самозванца. Во многом это было связано с моей убежденностью в том, что все окружающие понимают технологию гораздо лучше меня. Я ошибался. В каждом проекте есть части, вызывающие трудности у всех.
4. Некоторые люди все же знают, что делают
Несмотря на то что некоторые части проекта сложны для всех, один-два разработчика в команде могут быть мастерами в других частях.
В то время я чувствовал бы себя намного комфортнее, если бы знал, что нужно просто определить этих людей и научиться спрашивать у них совета, когда сталкиваюсь с проблемами по их части.
5. Open Source не страшный
Когда я начал зарабатывать на жизнь написанием программ, Open Source очень сильно пугал меня. Если бы я заранее знал, что просто у страха глаза велики, я бы влился в это движение гораздо раньше (а это хорошо для карьеры).
6. Люди, которыми вы восхищаетесь, — такие же люди, как и все
Говорят, не нужно искать встреч со своими героями, потому что они вас разочаруют. Я бы сказал, что, напротив, нужно обязательно познакомиться с ними, чтобы осознать, что они такие же люди, как и все.
Последние 6-7 месяцев я провел достаточное количество времени, стараясь познакомиться с людьми, которыми я восхищаюсь.
Я обнаружил, что это такие же люди, как я, и что они сталкиваются с кучей таких же проблем, что и я.
Это побудило меня стараться подражать этим людям. Ведь если они сталкиваются с такими же проблемами, ничто не мешает мне делать то же самое, что и они, чтобы справиться с этими проблемами.
7. Знать всё не обязательно
Разработка программ это до смешного сложная и расползающаяся сфера деятельности. Никто в целом мире не знает ее всю от А до Я, так что и пытаться не стоит.
На своей первой работе я впадал в ступор от осознания того, сколько же я не знаю. Но вместо того чтобы фокусироваться на этом факте, мне стоило выбрать что-то одно и хорошенько это изучить, игнорируя все остальные вещи, на которые у меня просто не было времени.
8. Глубокие знания могут быть лучше широких
Иногда знать какой-то предмет на очень высоком уровне бывает невероятно полезно. Я это понял на примере Open Source проекта, поддержкой которого я занимался.
9. Широкие знания могут быть лучше глубоких
Миру нужны специалисты широкого профиля. В зависимости от ваших профессиональных целей наличие широких познаний может быть фантастическим ресурсом.
На моей текущей работе, во многом связанной с менеджментом, моя способность впитывать не относящуюся к делу информацию это настоящее сокровище.
Кроме того, широта познаний это хороший фундамент для изучения нового.
10. Простой код это хорошо
Слишком много новичков, включая меня, считают, что сложный код производит лучшее впечатление.
Но самый лучший код прост и легок для понимания. Если вам сложно понять какой-то код, это не ваша вина, здесь виноват автор кода.
11. На работе ваше дело — учиться
Вы не должны испытывать чувство вины за то, что учитесь на работе: учеба это существенная часть вашего рабочего процесса.
Даже сеньоры проводят довольно много рабочего времени, читая руководства и изучая новые навыки. Вы тоже должны заниматься этим в течение рабочего дня!
12. Понимание принципов лучше запоминания
Запоминание нужных действий хорошо работает. Я двумя руками «за» практику путем повторения. Однако, это не всегда лучший способ изучения концепций.
Если бы я свое время уделял больше внимания изучению того, что стоит за подходами, применяемыми в используемых мной технологиях, я смог бы гораздо эффективнее выбирать правильные стратегии решения проблем.
13. Нужно писать о том, что вы изучаете
Я не начинал писать о разработке программ до совсем недавнего времени. Результат у писательства потрясающий. Таким образом я куда более эффективно удерживаю в памяти информацию, а кроме того, мне в любое время доступны ссылки на мои статьи.
Нет никакого смысла в том чтобы держать свой учебный процесс в секрете. Делитесь своими замечаниями и мыслями в своем блоге или на какой-нибудь платформе для блогов.
В самом худшем случае у вас останется онлайн-источник, к которому вы сможете обратиться, чтобы припомнить какую-то техническую информацию.
А в лучшем случае вы сможете также помочь другим людям и получить признание.
14. Высказывайте свое мнение на ревью кода
Даже если окажется, что вы не правы, все равно следует высказывать свое мнение во время проверки кода или сессий парного программирования.
Во-первых, это помогает улучшить качество кода, выпускаемого вашей командой. Также это шанс выступить в роли наставника для коллег (даже более опытных).
Во-вторых, если вы все же ошибаетесь, вас поправят. Это тоже следует рассматривать как благоприятную возможность. Даже если окружающие будут грубы, вы сможете узнать что-то новое!
15. На сессиях парного программирования выступайте в роли водителя
Я уверен, что наименее опытный человек в паре должен сидеть за клавиатурой.
На моей первой работе было много ситуаций, когда это пошло бы мне на пользу. Выступая в роли водителя, джуниор получает два преимущества.
Во-первых, в такой ситуации сеньору приходится объяснять каждый шаг, т. е., делиться контекстом и опытом.
Во-вторых, когда клавиатура у джуниора, сеньор не сможет просто настучать несколько строк кода, ничего не поясняя. Нет ничего хуже, чем убегающий сеньор, который так и не удосужился объяснить, как была решена проблема. Не позволяйте более опытным коллегам пропускать аспект обучения: это тоже часть их работы.
16. Создавайте игрушки, которые можно ломать
Когда я начинал заниматься профессиональной разработкой, я старался создавать полезные вещи.
Но я, собственно, так ничего и не построил, потому что попросту был не готов создавать вещи, которыми смогли бы пользоваться другие люди.
Если бы я просто строил маленькие проекты, подходящие для хакинга (без опасения сломать что-то важное), я бы учился гораздо быстрее. Это позволило бы мне в дальнейшем быстрее приступить к созданию полезных вещей.
17. Делайте перерывы
Проявляйте заботу о своем мозге. Разработка программ связана с большим умственным напряжением. А когда вы работаете по 90 часов в неделю, это не способствует эффективности вашего мыслительного процесса.
18. Не забывайте о физической активности
Упражнения, как и перерывы, очень благоприятны для вашего умственного здоровья.
Я упустил этот момент на своей первой работе и поплатился за это. Проблемы со здоровьем, ужасный цикл сна, постоянная усталость — это лишь часть последствий того, что я не делал никаких упражнений.
Тут у меня много рекомендаций. Если хотите просто активно провести досуг, попробуйте диск-гольф. Если вы заинтересованы в том чтобы переключить мозг и вернуть себе способность фокусироваться, попробуйте бег. Я вот недавно занялся тайским боксом — прекрасный выбор для тех, кто стремится к практичной физической активности.
19. Не зацикливайтесь на рефакторинге
У меня ушло слишком много времени на попытки писать совершенный код. Но джуниор не должен писать совершенный код. Дайте вашим коллегам посмотреть ваш близкий к оптимальному код, и они помогут вам его улучшить.
20. Записывайте свои ошибки
Я довольно долго не вел записи о том, где я промахнулся. Но ведение подобных записей (с пометками о том, как избегать подобных проблем в будущем) бережет вас от повторения ошибок.
21. Записывайте свои победы
Следует также вести учет своим победам, но по другой причине.
Одна из лучших стратегий борьбы с синдромом самозванца — напоминать себе обо всем, что вам удалось сделать за свою карьеру.
Например, напоминайте себе о любом коде, который вы запустили в продакшене, любых улучшениях, которые вы внесли в процедуру работы или в документацию, любой автоматизации, которую вы создали. Все это имеет ценность и будет напоминать вам о том, что и вы сами — стоящий разработчик.
22. Найти наставников может быть просто
Когда я начинал работать, я считал, что наставничество это непременно формальные отношения.
Я искал разработчика-сеньора, с которым мог бы обсуждать свои мысли и сомнения раз в неделю или что-то типа того. Подобные отношения могут быть отличным ресурсом, но они не обязательны.
Позже я узнал, что наставничество может быть менее формальным. Например, все гости моих подкастов это, по сути, мои наставники.
Также у меня есть несколько друзей, которых я приглашаю на кофе раз в несколько месяцев, но совершенно не обязательно, чтобы отношения с наставником были такими регулярными. Найдите интересного человека в вашем сообществе и попросите уделить вам 30 минут времени — вы удивитесь, сколько можно узнать подобным образом.
23. Чтобы самому выступать в роли наставника, не нужно быть экспертом
Новички должны учить других.
Когда я сам начинал, я думал, что чтобы учить кого-нибудь, нужно сначала набраться опыта. Это не совсем правда.
Конечно, не стоит выступать с речью по React, если вы никогда ничего не строили на JavaScript, но вполне можно помогать окружающим, даже если вы не знаете всего.
Поищите возможность поделиться своими знаниями. Например, рассказать о прикольном плагине для редактирования текста, который вы нашли. Это поможет вам потихоньку привыкать к роли наставника на будущее.
24. Говорить «я не знаю» это хороший тон
Многие инженеры боятся признаться, что чего-то не знают. Я тоже таким был, но на каком-то этапе понял, что единственный способ чему-то научиться это признать свое невежество.
Говорите о своем незнании, не смущаясь, и вы увидите, что многие последуют вашему примеру. Кроме того, если вам повезет, те, кто знает больше, смогут вас чему-то научить!
25. Но не забывайте добавлять «пока еще»
Это продолжение предыдущего совета. Говоря, что чего-то не знаете, не забывайте добавлять «пока еще».
Это одно из самых мощных слов, на мой взгляд.
«Я этого пока не знаю».
«Я пока еще недостаточно хорош в этом».
«Я пока еще не могу участвовать в Open Source».
Такая установка существенно изменила мои отношения с профессией. Жаль, что я не знал о важности этого слова, когда впервые устроился работать.
Продолжение следует!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]