Оказывается, что быть разработчиком программного обеспечения - это не только балансировка двоичных деревьев и реверсирование массивов.
Первую работу я получил на втором курсе университета. Я был ужасно не готов к карьере разработчика. Все, что я знал на тот момент, - это основные структуры данных и то, как копировать и вставлять код из руководств, которые я читал в Интернете. Я был шокирован тем, что кто-то заплатил мне за написание кода.
Помимо моего неопытности в программировании, я понятия не имел, что на самом деле означает жизнь штатного разработчика. Я знал, что буду писать код и создавать продукты, но понятия не имел, что еще означает карьера в сфере технологий. Хотел бы я, чтобы кто-нибудь дал мне справочник - «Разработка программного обеспечения 101».
Наверное, есть книга, но мне было бы лень ее читать. Если бы мне пришлось написать сокращенную версию этой книги для себя в прошлом, она охватила бы следующие темы.
О чем говорить в режиме 1 на 1
Примерно через две недели после начала моей первой работы я получил календарное приглашение на встречу один на один с моим менеджером. Я понятия не имел, что такое 1 на 1.
На нашей первой встрече мой менеджер объяснил, что это будет повторяющееся событие. В это время я мог озвучивать любые опасения по поводу моей работы, и мы строили планы относительно моего карьерного роста. «Хорошо, имеет смысл», - сказал я.
В следующих нескольких матчах один на один мне не о чем было говорить. Мой менеджер задал несколько вопросов, но я ответил на большинство из них так: «Сейчас ничего не думаю, но я дам вам знать, если что-нибудь придумаю».
Несколько раз подряд я ни о чем не думал, в основном потому, что всегда пытался придумать, о чем поговорить на месте.
Через пару месяцев я понял, что мне нужно лучше подготовиться к встрече один на один. Итак, я создал документ, в котором писал все, что касалось моей работы.
- Проблемы с плохим опытом разработчика
- Я узнал что-то новое
- Области кодовой базы, которые я хотел бы знать лучше
- Ограничения процессов нашей команды
- Заслуживающие внимания взаимодействия, которые у меня были с коллегами
Я делал заметки обо всем вышеперечисленном и многом другом.
Это означало, что мне всегда было о чем поговорить во время встреч один на один. Я расставлял приоритеты в том, что было больше всего в моей голове. Со временем мы также вместе работали над планом развития карьеры. Мы использовали это для периодической проверки, чтобы убедиться, что работа, которую я выполняю, соответствует моим целям.
Один на один может быть странным, когда вы только начинаете работать. Мне жаль, что я не имел лучшего представления о том, что они из себя представляли и чего ожидали от меня и моего менеджера, когда я только начал работать.
Не будь таким, как я. Наблюдайте, делайте заметки, думайте о своих целях, и у вас будет много материала, о котором можно поговорить во время первых встреч один на один.
За пять лет моей карьеры мне больше не о чем говорить. В наши дни я уделяю большое внимание тому, о чем говорю. Иначе у нас не хватит времени.
Важность общения
Если вы посмотрите на рубрики собеседований для технологических компаний, я гарантирую, что во всех них есть раздел о том, насколько хорошо кандидаты общаются. Для этого есть веская причина.
Люди не пишут код; команды делают. Это означает обсуждение различных подходов, написание обзоров кода, обсуждение компромиссов с дизайнерами и менеджерами по работе с клиентами, а также все виды письменного и устного общения. Ко всему этому я был совершенно не готов.
В школе я привык писать код самостоятельно. Я думал, что работа по кодированию будет включать написание кода и взлом по 8 часов в день. Это было опровергнуто менее чем через неделю на моей первой работе.
Мне потребовалось некоторое время, прежде чем я полностью освоился с общением и обсуждением технических деталей. Вначале я не мог найти слов при обсуждении технических вопросов с менеджерами по продукту и дизайнерами. Я не мог найти нужный язык, чтобы передать препятствия, с которыми я столкнулся. Со временем я стал намного лучше в этом.
Хотелось бы, чтобы я был лучше подготовлен к тому типу общения, которого от меня ожидали. Я все еще активно работаю над своим общением, но я прошел много миль по сравнению с тем, с чего начал.
Не забывайте общую картину
Как новый разработчик программного обеспечения, я был очень сосредоточен на кодировании аспекта работы. Легко потеряться в коде и упустить из виду бизнес-результаты, которые мы пытаемся решить с помощью программного обеспечения. Особенно это актуально для стажеров и младших разработчиков.
Легко попасться в Twitter и войны Github за использование for of loops против forEach. Но, в конце концов, имеет ли это значение, если я не работаю над инструментами или библиотекой? Настоящая конечная цель перебора массива - это, вероятно, что-то показать пользователю.
Не поймите меня неправильно. Необходимо провести множество важных технических обсуждений. Но может быть легко пропустить лес за деревьями, когда мы только начинаем. Велосипедная распродажа слишком распространена в технологических компаниях, и даже знание этой концепции может помочь сосредоточиться на более широкой картине.
Я обнаружил, что общение с коллегами, работающими с клиентами, и изучение целей компании - это простой, но эффективный способ придать смысл и перспективу моей работе.
В настоящее время, когда я начинаю новый проект или работу, я отдаю приоритет пониманию конечного пользователя и основных проблем, которые мы хотим решить, прежде чем я начну писать код.
Будьте в курсе
Я занимаюсь веб-разработкой всего пять лет, и уже видел, как бесчисленное количество технологий, инструментов, фреймворков и шаблонов взлетает и падает. Когда я разговариваю с людьми, которые проработали в этой отрасли десятилетиями, они не могут поверить, насколько сильно изменилась отрасль с тех пор, как они начали.
Я обнаружил, что стоит быть в курсе различных тенденций в отрасли. Это помогло мне по-новому взглянуть на мою работу и убедиться, что мы не отстаем.
Это не означает, что нужно гнаться за каждой новой тенденцией и пытаться использовать новейшие технологии. Это больше связано с тем, чтобы держать руку на пульсе окружающей экосистемы, чтобы понять ключевые темы и проблемы, с которыми сталкиваются люди, а также то, как языки и платформы развиваются для решения этих проблем.
Чтение кода так же важно, как и его написание
Большинство проектов и заданий в университете я выполнял с нуля. Я понимал, насколько важно читать и перемещаться по коду в существующей кодовой базе.
Как разработчик, мы обычно работаем с существующей базой кода - репозиториями кода, где шаблоны были установлены, сломаны и восстановлены. Один из самых важных навыков, который я приобрел за эти годы, - это как погрузиться в невиданную ранее кодовую базу и найти свой путь к ней.
Единственное, что, на мой взгляд, помогло бы мне лучше на этом фронте, - это участие в проектах с открытым исходным кодом.
Тестировать, тестировать и снова тестировать
Тесты были моим худшим кошмаром на первой работе. Они потерпят неудачу - очень часто. Я бы запаниковал и попросил помощи. Я никогда не писал тесты за пределами школьных проектов (кстати, у них очень мало тестов).
Одним из первых крупных проектов на моей первой работе было увеличение охвата тестированием с 40% до 90%, что оказало длительное влияние на то, как я подхожу к тестированию везде, где сейчас работаю. Со временем я стал сторонником 100% тестового покрытия, когда это возможно.
Хотел бы я знать различные методы тестирования и передовые методы тестирования кода. Я даже не знал, что тестовое покрытие - это концепция, когда только начинал работать.
Узнайте, как отлаживать на ранней стадии
Следы стека пугали меня в университете. Я понятия не имел, как их читать, и даже увидеть их означало, что я сделал что-то не так. В начале моей первой работы я был также не готов к отладке общих проблем. Я потратил часы на поиск ошибок в Google, вместо того, чтобы искать первопричину (конечно, иногда ошибки были настолько бессмысленными, что Google был единственным выходом).
Как только я понял, как читать трассировку стека и обнаружил отладчики и журналы, все прошло гладко. Это инструменты, которые я однажды изучил и использую всегда и везде.
В наши дни, если в базах кода, с которыми я работаю, присутствует отладчик, это мой выбор по умолчанию. Это значительно упрощает поиск и устранение проблем.
Хотел бы я быть лучше подготовлен к отладке ошибок. Университет должен был хотя бы научить меня читать трассировку стека :(
Если бы у меня был наставник, когда я начинал свою первую работу, я бы хотел, чтобы они мне сказали вот что. Это помогло бы мне стать более эффективным разработчиком с самого начала, вместо того чтобы изучать эти принципы по ходу дела.
