Кэл Эванс, программист с многолетним опытом, делится полезными советами с начинающими разработчиками. Он начинал работать еще на Commodore 64, писал код на диалекте языка BASIC в фирме своих родителей. Занимается программированием более 30 лет, хотя формально нигде этому не учился. В своей статье Эванс рассказывает о том, что он узнал за эти годы и что ему было бы полезно знать с самого начала.

Проявляйте терпение к себе и другим

Если вы младший разработчик, то, естественно, многого не знаете и будете ошибаться. Если вам повезло получить работу в компании, которая готова вас обучать, воспользуйтесь этим. В хорошей компании понимают, что вы еще учитесь, назначат вам наставника, который поможет во всём разобраться, и укажут правильное направление, когда вы потеряетесь.

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

Будьте терпеливы к самому себе. Если вы будете настойчивы, то в конце концов избавитесь от слова «джуниор» в своей должности, но для этого нужно время, много работы и много ошибок.

Научитесь учиться

Всё меняется. За последние 35 лет это единственная константа в разработке программного обеспечения. Языки приходят и уходят, фреймворки меняются и исчезают, со временем меняются даже передовые практики. Как молодой разработчик, вы оказываетесь под двойным ударом. Вы должны освоить существующий стек технологий, чтобы быть полезным здесь и сейчас, но вы также должны быть в курсе изменений в стеке. Кроме того, вы должны следить за новыми технологиями, которые могут оказаться полезными, а могут и нет.

Навыки самообучения — это залог успеха в карьере. Послушайте как автор статьи обсуждает эту проблему с профессиональным коучем Оливией Лиддл в подкасте No BS Engineering.

Освойте принципы, а не инструменты

Языки, фреймворки, платформы, интегрированные среды разработки, инфраструктуры — всё это приходит и уходит. Вы будете учиться пользоваться определенным фреймворком три или четыре года, но потом неминуемо перейдете на новый, и эти интеллектуальные инвестиции пропадут.

Такие концепции, как объектно-ориентированное программирование, функциональное программирование и паттерны проектирования, послужат вам в работе с разными языками и фреймворками.

Это не значит, что вы не должны постараться стать отличным Java-разработчиком или что вам не надо изучать все тонкости вашего технологического стека и инструментов, но совместите это с концепциями, лежащими в основе языка и инструментов, которыми вы пользуетесь. Эти знания пригодятся и для других языков и стеков.

Умейте изобретать колесо

Тот, кто сказал «не надо изобретать колесо», был идиотом! Никто бы не поставил велосипедную шину на гоночный автомобиль, для них изобрели специальные покрышки. Разработчики ПО переизобретают «колеса» всё время, потому что им нужны «колеса» с определенными свойствами.

Конечно, не стоит писать весь код самому. Исследуйте чужой код на GitHub или GitLab. У PHP-разработчиков есть отличный инструмент под названием Packagist, у разработчиков на JavaScript есть похожая штука — npm. С каким бы языком вы ни работали, изучите инструменты управления пакетами и зависимостями, чтобы понять, что другие люди сделали до вас. С вероятностью 99% то, что вам нужно, уже существует. Проверьте.

Если вы не можете найти решение, которое бы удовлетворяло вас на 100%, посмотрите, есть ли проект, который вы можете довести до ума, вместо того, чтобы писать с нуля?

Да, иногда разработчики изобретают колесо, но мы знаем, почему мы так делаем, и можем обосновать свое решение, когда это требуется.

Читайте, читайте, читайте… затем пишите

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

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

Найдите наставника

Моя история началась еще до появления интернета. Мы пользовались электронными досками объявлений, но знаниями на них делились мало. Мне приходилось покупать книги, читать их, писать код и экспериментировать, пока у меня не начало получаться. Я учился в одиночестве, с книгой и плюшевой обезьянкой, которой я объяснял код (она был моим первым ментором).

В наши дни разработчики имеют массу возможностей для получения информации и примеров кода: Stack Overflow, Stack Exchange, Reddit и так далее. Тем не менее, поиск кода — это только половина проблемы. Вторая половина — понять, является ли ваше решение хорошим. Единственный способ это понять — найти хорошего наставника.

Найдите кого-то, кто может выслушать ваши идеи. Кого-то, кто желает вам успеха и готов вкладывать в вас своё время

Когда найдете ментора, помните о золотом правиле «Да не потрать зря времени наставника». Не задавайте простые вопросы, на которые можно найти ответы в интернете. Напротив, спрашивайте о том, что вызывает ступор. На этом этапе карьеры наставники — ваша путеводная звезда. Они зададут направление и поделятся советом, но не ждите от них готовых решений.