6 ответов на «зачем мне учиться программировать» на личном примере

2022-10-10 16:08:28 Время чтения 9 мин 328

Привет! В статье делюсь выводами, чему меня научила ИТ-разработка за 7 лет пока в ней нахожусь. Путь был тернистым и не все сразу получалось. Статья делится на две части. В первой краткая история моего вкатывания в ИТ, во второй — чему я научился, когда вкатился.

До 2015 года особого интереса к программированию не проявлял. Мне были интересны точные науки (математика, физика, химия), но чтобы сесть и написать какую-то программу - нет, а зачем? На уроках по программированию делал смелый выбор в сторону NFS Underground, GTA Vice City и CS 1.6. Лабораторные работы по программированию в институте вряд ли можно считать серьезным опытом в ИТ.

Дело изменилось, когда появилась прикладная задача на первом месте работы. Нужно было сделать расчет в Matlab. Здесь то меня и зацепило. Можно не только делать расчеты, но и прикрутить интерфейс для управления параметрами — вау, а еще рядом построить графики и наглядно показать какая модель более эффективная.

Потом были пол года самостоятельного изучения Java. Почему именно Java? Конечно, можно рассказать байку, как я взвесил все за и против, опросил много людей, это был сложный путь; но нет, у нас же про личный опыт. Это была абсолютная случайность, рядом сидел коллега, который сказал попробуй пройти интерактивный курс по Java, учат с нуля. И я просто попробовал, затянуло. Изучил основы языка, алгоритмы, основы фреймворков и SQL, сделал несколько pet-projects.

Затем были два месяца провальных собеседований. К провалам научился относиться философски. Записывал вопросы, находил ответы, откликался на следующую вакансию. В результате получил оффер от небольшой веб-студии из Москвы, набирали стажеров на Java. Здесь стоит отметить, что мне очень повезло с наставником (СТО). Это был играющий тренер, который обладал обширными знаниями во всех направлениях веб-разработки. Многому меня научил, а главное, показал, что можно разбираться не только в одном фреймворке, а одновременно править код на фронте, бэкенде и в мобильном приложении. Чтобы не затягивать рассказ, далее были несколько позиций Java-разработчика в крупных интеграторах. Но всегда тянуло создать что-то свое, независимое. Увидели с Евгением восходящий тренд чат-ботов и основали агентство BotCreators.ru и компанию Искусство Автоматизации.

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

1. Отличать декларацию от реализации

Написанный код — это лишь текст, хоть сто раз сохрани его в блокноте, он еще не станет работающей программой. Требуется, говоря на языке программистов, среда выполнения программы (runtime). На ум приходит первая аналогия с реальной жизнью.

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

2. Решением может быть многоходовочка, а не сделай А->B->C и получи результат

Этот пункт до меня долго доходил. Как нам всем хочется — нажал на кнопку, получил результат. И действительно, это срабатывает на простых задачах. Но когда речь идет о задачах средней и высокой сложности, решить "в лоб" не всегда удается. Из компьютерного мира приходит аналогия с конечным автоматом. Автомат может приходить в целевое состояние через 50, а то и 100 переходных состояний. В задачах просчета вариантов, конечно, компьютер выигрывает у человека с большим отрывом. Но можно хотя бы взять на заметку и напоминать себе, что на пути из точки А в точку Б есть те самые переходные состояния, которые на данный момент трудно удержать в голове.

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

3. Чем меньше составных частей, тем ниже вероятность ошибки

Что в бизнесе, что в программировании прослеживается понятная аналогия: чем больше уровней абстракции, интеграций / контрагентов или подрядчиков, тем в геометрической прогрессии возрастает вероятность сбоя. Если в программировании нам на помощь приходят различные виды тестов, то в бизнесе — автоматизация, упрощение бизнес-процессов, резервирование исполнителей. Вспоминается фраза: самое плохое число для бизнеса это один; один клиент, один расчётный счет и т.д.

4. Где-то, кто-то уже решал твою задачу, погугли

За всю карьеру программиста я не задал ни одного вопроса ни на одном из форумов. Даже в далеком 2015 году как-то находились ответы на любые вопросы. Пользовался в основном StackOverflow и SQL. ru (лютый в самом деле форум, где тебя сначала обложат матом и потом, может быть, помогут; поражала его токсичность, почему так / зачем?).

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

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

5. У одной задачи может быть множество решений

Допустим, перед нами стоит задача скачать файл по ссылке. Сколькими способами можно сделать? Сходу могу назвать 5 (cURL, браузером, скрипт на любом языке программирования, через Postman).

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

6. Ты не многопоточен, ты однопоточен, но выход есть

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

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