Что я узнал после того, как изменил свой взгляд на программирование. (Выводы из личного опыта)

Вы когда-нибудь зацикливались на том, как начать кодировать определенную проблему или даже заблудиться в своем собственном коде! Так что это был я очень давно. После двух лет использования в основном JavaScript, синдром самозванца начал даваться. Это было вызвано такими вещами, как; -

  • Отказ в приеме на работу (к которому, я думаю, всем следует привыкнуть).
  • Неспособность понять почему ваш код ломается после небольшого изменения.
  • Чтение успешных историй о программистах, получивших хорошую работу всего за несколько месяцев до самоучки, в то время как вы все еще пытаетесь объединить пул-реквест (конечно, сравнения плохи, но, черт возьми, мы люди).

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

Всегда имейте ручку и книгу по программированию перед тем, как начать работу над проектом!

Да, физическая книга. (Хорошо, не так физически, иногда вкладка или блокнот, но если это что-то, на чем можно свободно писать и рисовать.) Почему? Вы узнаете важность этого в конце этой статьи.

В большинстве случаев, когда я хотел начать проект, я обычно знал, чего я хочу достичь в итоге, но редко думал о том, как этого достичь, другими словами, о процессе. Знание того, что я хотел, в конце концов, автоматически дало мне понять, о чем именно гуглить, но все, что я искал, это решения (готовые идеи / проекты), но не процесс (как были достигнуты решения), и все, чему я мог восхищаться, это то, как про "рабочее решение" писали, реально продумали. Фактически я был кодером, но не программистом.

Программисты думают о том, как прийти к решению, программисты записывают решение на своем предпочитаемом «тарабарщине».

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

1. Работайте над тем, что вам интересно

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

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

Если вам всегда было интересно, как работает определенная система или функция, питайте свое любопытство и не останавливайтесь, пока не воспроизведете ту же систему или функцию. По пути вы можете многое узнать и узнать.

Приятно работать над проектом, который вам интересен, чем тот, который вам был рекомендован.

2. Используйте наброски, заметки и диаграммы.

Это самый важный шаг, хотя и второй.

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

Вот тут-то и пригодится книга по программированию, вкладка, ручка или карандаш. Подумайте, как лучше всего можно найти решение, напишите и нарисуйте его, а когда вы застрянете, тогда и появится поиск в Google (я расскажу о что в следующем пункте).

По крайней мере, старайтесь гуглить только тогда, когда вы застряли.

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

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

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

3. Гугл только когда застрял

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

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

4. Использование хороших и понятных имен переменных.

Я знаю, что вы, возможно, слышали об этом, но позвольте мне подчеркнуть это больше, так как я нашел это жемчужиной. Поскольку я кодирую на языках высокого уровня, то есть на Python и JavaScript, если быть точным, мне нравится, когда я читаю свой собственный код, как будто я читаю по-английски. Серьезно, зачем делать собственный код скучным для чтения? Чего я избегаю при именовании переменных; -

  • Сокращающие слова; Если я выберу имя переменной, и оно будет небольшим, я напишу его как есть. Я лучше number, чем num.
  • Использование ‘_’ вместо camelCase; Если это не командный проект, который следует определенным правилам, я лучше объявлю var previous_letters = '', чем var previousLetters = ''.

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

«Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям »- Мартин Фаулер.

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

Если вы нашли эту статью интересной и содержательной, пожалуйста, хлопните в ладоши. ваше здоровье:)