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

Вы рассказываете своим друзьям, семье, и это здорово, что вы Хан Соло из Visual Basic - вы чувствуете, что можете пройти код менее чем за 12 парсеков. Теперь вам не терпится написать больше кода, попробовать новые платформы, получить больше этого ощущения.

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

Позвольте мне сразу вас остановить, это неправда.

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

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

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

Все, что вам нужно, это любовь к коду

Думаю, это самый важный совет, который я вам дам. Джон, Пол, Джордж и Ринго тоже.

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

Суть в том, что если вы хотите стать лучше в кодировании, вы должны быть уверены, что вам это нравится.

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

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

Уравнение простое. Если вы заботитесь о своих товарищах по команде, а они заботятся о вас, те моменты, когда вы не знаете, как что-то делать - и поверьте мне, приятель, их будет несколько, они будут заботиться о том, чтобы вы учились, как и о том, как вы завершаете задача, которую вы выполняете. Так что времена, когда вы добьетесь успеха, будут потрясающими, и они будут воодушевлять вас на успех снова и снова.

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

Любите код, любите свою команду, любовь - это все, что вам нужно.

Считать

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

Во-первых, прекратите печатать и сосредоточьтесь на том, как лучше всего решить возникшую у вас проблему. Не торопитесь, прочтите документацию, распределите проблему на более мелкие проблемы, и, возможно, вы решите большую проблему.

Не все в кодировании - это просто кодирование. Вы мне не верите?

Хорошо, я собираюсь предоставить вам лучшую строку кода, которая когда-либо была написана:

Вы не поняли? Где линия?

Его не существует. Строки, которые мы не пишем, - это большие строки, которые мы пишем. И вы сэкономите строки кода, только если будете думать до написания кода, а не после.

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

Ой, я забыл, не думай дважды, все в порядке. Решите проблему, не создавайте новых.

Задавайте умные вопросы

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

У вас могут быть вопросы, у всех есть вопросы, даже у самых опытных разработчиков. Никогда не переставать задавать вопросы так же важно, как и умение иногда отвечать самому себе.

Если вы зададите умные вопросы, вы не станете «парнем, который не знает о существовании Google», к вам будут относиться более серьезно. Плюс одно из преимуществ поиска в Google и самостоятельного обдумывания состоит в том, что вы учитесь читать документы и думать самостоятельно, и это всегда пригодится.

Забота о времени своей команды так же важна, как и умение быть хорошим разработчиком и писать тонны кода.

Не торопитесь, один раз

Чтобы объяснить это, я приведу вам два примера, два сценария, и вы скажете мне, какой сценарий вы считаете лучшим.

Первый сценарий: вы получаете задание и сразу же начинаете печатать, вы продвигаете свой PR, прежде чем просматривать его. Тогда у вас есть 30 комментариев по поводу вашего пиара, 15 по поводу линтинга - Поверьте, я был там. В результате вы представляете себя безрассудным программистом и еще полтора часа будете поправлять свой PR. Ты тратил всеобщее время и плохо выглядишь.

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

Так что ты думаешь? Мне? Сейчас я предпочитаю сценарий номер два, сначала я выбирал сценарий номер сто раз, но давай, вот почему мы учимся, не так ли?

У тебя есть право ошибаться

Если вы все время спрашиваете себя: «Правильный ли этот подход?», «Могу ли я сделать это так?», «Это неправильно?», Позвольте мне сказать вам, что это вас ни к чему не приведет.

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

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

Доверьтесь своей интуиции, возможно, вы не так ошибаетесь, как думаете, но если вы ошибаетесь, наслаждайтесь.

Гит аккуратный урод

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

В вашей спальне может быть беспорядок, вы можете быть беспорядком, но не ваша ветка git, она должна быть безупречной.

Вот несколько советов:

-Изучите как можно больше о git, я имею в виду основные концепции git, а не только основные команды, каждый знает, как сделать коммит.

-Короткие коммиты: делайте одно после того, как добавили одну функцию, а не целую их группу, поэтому, если вам нужно вернуться к фиксации, вам не придется переписывать тонны кода.

-Дайте правильное описание ваших коммитов, как я сказал ранее, это полезно, если вам нужно вернуться к фиксации, вы знаете, какой из них.

-Сделайте git pull каждый раз, когда вы собираетесь сделать push, чтобы вы всегда работали с чистым листом, и вы также избегали проблем слияния.

-Комментарии к вашим PR, о чем они? Зачем ты это делаешь? Это полезно, если кто-то его проверит, он сможет понять, о чем идет речь и почему вы это сделали.

-Это визуальное изменение? Добавьте снимок экрана, это будет намного проще понять, если вы все сделали правильно, если все это видят.

-Избегайте 30-ти файловых PR-15-ти файлов, такой PR невозможно просмотреть, а также меньше шансов, что ваша команда может обнаружить ошибку.

Держите свой Git в чистоте.

Примите вызов

Это был девиз компании, в которой я работал. Я всегда думал, что это простая фраза. Но пока шли спринты, я понимал, что это больше, чем девиз, это образ жизни.

Трудно бросать себе вызов в новых вещах, и если вы это читаете, это означает, что вы уже начали, вы учитесь программировать.

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

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

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