Share This
Связаться со мной
Крути в низ
Categories
//📈 5 сложных навыков, которые позволят экспоненциально расти в программировании

📈 5 сложных навыков, которые позволят экспоненциально расти в программировании

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

5 slozhnyh navykov kotorye pozvoljat eksponencialno rasti v programmirovanii 63f0c56 - 📈 5 сложных навыков, которые позволят экспоненциально расти в программировании

Перевод публикуется с сокращениями, автор оригинальной статьи Pen Magnet.

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

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

Посмотрим на следующую диаграмму:

5 slozhnyh navykov kotorye pozvoljat eksponencialno rasti v programmirovanii 2820fa3 - 📈 5 сложных навыков, которые позволят экспоненциально расти в программировании

Экспоненциальная кривая (источник: Википедия)

Мы говорим о зеленом графике.

Рассмотрим 5 вещей, которые могут привести к незамедлительному экспоненциальному росту вашей карьеры программиста.

1. Возня с игрушками

Какое отношение игрушки (гаджеты) имеют к программированию?

Когда мне было 8 лет, я сломал свои цифровые часы, чтобы понять, как работает контроль времени. Мне потребовалось 2 дня, чтобы собрать все заново. После всех мучений я не смог понять, какова связь между микросхемой и цифрами на LCD-панели.

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

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

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

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

В этом занятии есть три важных момента:

  • Это не должно быть сложно (нужно найти время, желание и т. д.).
  • Это должно быть добровольным (не запихивайте своих детей в школы программирования). Хотя можно создать среду и направить их.
  • Самое важное – это настойчивость. Сломайте все, и не сдавайтесь, пока не почините. Настойчивость подпитывает длительное желание решать проблемы. Это чувство – именно то, что поможет выжить в безжалостной индустрии ПО.

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

Больше полезной информации вы найдете на нашем телеграм-канале «Библиотека программиста». Интересно, перейти к каналу

2. Бросать вызов самому себе

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

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

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

Допустим, вы написали функцию, которая считывает набор переменных из конфига. Реализация будет включать жестко заданное имя файла (например, «myfile.config»). Ее интерфейс выглядит следующим образом:

         func readParams()     

Чтобы испытать себя, после написания этой функции настройте ее так, чтобы она принимала имя файла (с аргументом по умолчанию, который является именем файла).

         func readParams(filename: String="myfile.config")     

Только подумайте, сколько возможностей откроет это небольшое изменение:

  • Разработчик вашего клиента или конечный пользователь могут изменить параметры конфигурации в рантайме, а вам придется перезагрузить исполняемый код. Поэтому необходимо оптимизировать этот код и инкапсулировать его в функцию initialize(), которая вызывается в начале + при каждом изменении файла конфига.
  • Предполагая, что файл имеет связь с пользователем, существует возможность поддержки нескольких пользователей с одной и той же установкой приложения.

3. Грамматика

В течение многих лет эксперты твердили: правое и левое полушария мозга контролируют различные функции. Одна из них делает вас лучше в математике, а другая – в искусстве и языке.

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

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

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

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

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

Почему мы ставим словарный запас на второе место по сравнению с грамматикой? Потому что грамматика – это не что иное, как оперирующие словами правила. Каждый компилятор тоже является грамматикой. Обладая основными знаниями (времена, глаголы и т. д.), вы легко сможете найти более эффективные синонимы/подходящие слова. Обратное невозможно.

4. Презентация

Когда дело доходит до работы, программисты практически не общаются. Они либо общаются на непонятном для других техническом жаргоне, либо просто пишут код.

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

Представьте себе сценарий входа в систему, объясненный 2 программистами:

Программист A:

Пользователь приходит на экран авторизации, вводит имя пользователя/пароль и нажимает кнопку входа. Если он вводит символы #, & или *, вход отклоняется, и пользователь остается на той же странице. Если все хорошо, генерируется запрос к API. Пароль должен быть хэширован, т. к. API сопоставляет хэш пароля с хэшем, хранимым в БД. Эта проверка не должна происходить, если имя пользователя не совпадает. Когда совпадают оба введенных параметра, возвращается код 200 и пользователь перенаправляется на страницу профиля, а если нет – 401. В случае успеха выдается токен, который действителен в течение 2 недель.

Программист Б:

  • У нас есть два процесса: внешний код и внутренний API (рисуем два квадрата).
  • Оба общаются через HTTP-запрос (соединяем их стрелками).
  • Фронтенд принимает вводимые пользователем данные и проверяет их.
  • Бекенд должен проверять наличие пользователя в БД и правильность хэша пароля.
  • И здесь начинается важная часть: если ответ будет успешным, фронт получит токен от серверной части, который будет хранить 2 недели. Пока он действителен, пользователь может сразу попадать на страницу профиля. Эта логика проверки токенов предшествует странице авторизации.
  • Вы можете посмотреть подробности API в документе, который я отправил всем/загрузил в облако.

(на этом этапе, возможно, на доске/блокноте много стрелок, и каждая стрелка помечена порядковым номером)

Чья презентация будет успешной? Программист А может быть на 100% прав, но он наверняка потерпит неудачу в своей передаче идеи. Коллегам было бы скучно из-за его неорганизованного способа представления и ненужных деталей (коды статуса HTTP). Программист Б будет удерживать внимание своей аудитории, а также побуждать их к изучению деталей после презентации.

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

Цель презентации – ясность и простота.

В Amazon это уже осознали и теперь предпочитают шестистраничную памятку, а не PPT-файл. Если вы не можете с помощью 6 страниц описать свою идею, она не заслуживает внимания. Упростите любой ценой!

5. Переключение контекста

Мозг большинства программистов подобен микросервисам. Разберемся на примере.

Монолитный подход:

API: /get/payments

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

Микросервисный подход:

Микросервис более специфичен и ориентирован на объекты.

Микросервис для учетных записей (/get/payments) будет возвращать платежи только для учетной записи, с которой совершается вход.

Микросервис для платежей (/get/payments) вернет все платежи, произведенные в системе.

В чем разница? Парсинг – это налог за наличие монолита. Другими словами, микросервис уже знает, что он должен делать.

Микросервисы знают свою область видимости, которая привносит контекст.

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

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

Ваша работа программиста требует только доставки кода.

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

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

  • Решите, нужно ли вам срочно отвечать на этот вопрос.
  • Если да, уточните его категорию, прежде чем формулировать свой ответ.
  • Все несрочные дела могут подождать.
  • Для повторяющихся задач вы можете кэшировать свои ответы, как это делает ваш софт.
  • Чаще всего ваш код является вашим главным приоритетом. Не тратьте сосредоточенность впустую. Сведите к минимуму время отвлечения внимания, используя переключение контекста.

Заключение

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

Естественно, речь здесь не идет о продуктивном программировании.

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

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

Истина лежит где-то посередине.

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

Дополнительный материал:

  • Программирование с пассивным доходом: 5 способов для разработчиков ПО
  • Функциональное программирование: рефакторинг, замыкания и функции высшего порядка
  • Программирование на Go с нуля: 9 полезных видеоуроков
  • Как превратить программирование в профессиональное ремесло за 8 простых шагов
  • Асинхронное программирование: концепция, реализация, примеры

  • 0 views
  • 0 Comment

Leave a Reply

Ваш адрес email не будет опубликован.

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Свежие комментарии

    Рубрики

    About Author 01.

    blank
    Roman Spiridonov

    Моя специальность - Back-end Developer, Software Engineer Python. Мне 39 лет, я работаю в области информационных технологий более 5 лет. Опыт программирования на Python более 3 лет. На Django более 2 лет.

    Categories 05.

    © Speccy 2022 / All rights reserved

    Связаться со мной
    Close