Вчера дописал 14-ю задачу из двадцати 2-го модуля, надеюсь, её сегодня разберут на созвоне.
С удивлением вчера обнаружил, что пошла только 3-я неделя, как я на курсе, а такое ощущение, что прошло уже пара месяцев. Кажется, силы заканчиваются быстрее, чем я рассчитывал, надо бы немного сбросить темп, но так не хочется.
Знания по предмету пока что не очень, хочется пойти почитать больше теории, чтобы понимать материал глубже. Останавливает только то, что у меня совершенно на это нет времени.

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

В первые пару дней поиска HR пишет, что откликов очень много, больше 300 человек в первый день, и продолжают расти. Отлично, значит, скоро уже закроем эту вакансию!
Но реальность оказалась совершенно другой: за 2 месяца я провёл только одно собеседование. И то кандидат с треском провалился.

Что же не так?
Кандидаты не берут трубку, когда им звонит HR, чтобы назначить собеседование, другим назначают встречу, а они не приходят и не берут трубку потом. Те, которые приходят, не могут ответить на те 10 вопросов, которые я составил для проверки базовых знаний.
Один кандидат отвечал на них больше 2 часов, а потом просто встал и ушёл.

Я это к чему всё пишу?
Когда буду искать работу, надо понимать, что те цифры, которые показывает сайт поиска работы, — почти полная чушь.
Половина кандидатов просто не придут на собеседование, еще 40 процентов окажутся профнепригодны, еще несколько просто передумают в процессе самого собеседования. И останется всего 2-3 человека, между которыми и будет конкуренция за вакансию.

Скажите, у вас бывает так, что вы покупаете книги или скачиваете их из интернета, складываете на красивую полочку и потом никогда не читаете? (уверен, что да)
Вот у меня так же было с книгой Р. Мартина — «Чистая Архитектура».
Купил её ещё лет 6 назад, мне её посоветовали со словами: «Мастхэв для любого разработчика!».
Я прочитал где-то первые страниц 50, ничего не понял, и с тех пор она создаёт видимость моего могучего интеллекта на полке.
На этих выходных я закончил второй модуль по курсу и решил: прежде чем бежать сразу на третий, начать читать книгу.

Книги Мартина — это такой вид технической литературы, который потребует от вас не компьютера под рукой, а скорее блокнота, ручки и многозначительного неподвижного взгляда в глубины космоса.
В первых двух главах Боб рассказывает, что такое архитектура и дизайн, и как программисты жили в те времена, когда они были учёными, а не писателями промтов для ИИ.

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

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

Говоря языком программного продукта:
Архитектура — это высокоуровневая абстракция: монолит или микросервисы, протоколы взаимодействий, паттерны безопасности.
Дизайн — это низкоуровневая абстракция: названия классов и методов, алгоритмы, структуры данных, обработка ошибок.

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

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

Вчера начал делать 3-й модуль, он, как и оказалось, намного сложнее предыдущего. Мне всё еще довольно тяжело понимать, что требуется по заданию, не знаю, только ли у меня так, но мне приходится довольно много времени тратить, чтобы составить себе план работы.
Очень надеюсь, что в будущем или я привыкну к этому, или задачи станут более понятными.
Пока что грешу на себя и поэтому параллельно читаю книгу Джона Боднера «Go: идиомы и паттерны проектирования».

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

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

На прошлой неделе сделал первые задачи по 3-му модулю, но не удержался и пошёл смотреть лекции на YouTube по горутинам.
Оказалось, что до этого я совершенно неправильно их понимал.
С одной стороны, новое знание немного облегчило муки от пробелов в понимании "что тут происходит", но, как водится, появилось осознание, что эту тему я буду учить еще дольше, чем планировал изначально.

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

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

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

Итак, что же было за этот месяц:

1) Программа обучения:

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

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

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

2) Сколько времени ушло на учёбу:

- Первый модуль я закрыл довольно быстро — за 5 дней, так как уже имел опыт в программировании, в том числе и на Go.

- На второй модуль я потратил 15 дней.

- Третий пока в процессе — сегодня 9-й день, как я к нему приступил.

3) Ощущения от курса:

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

- За месяц стало понятно, что общения в Telegram-чатах курса практически нет. Но если самому проявлять активность, то людей можно раскачать на какую-нибудь движуху.

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

4) Что с прогрессом:

- Я каждый день делаю что-то связанное с кодом. Даже когда нет времени или сил, я просто смотрю чужие репозитории, ролики на YouTube, читаю книги.

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

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

Это был отличный месяц! 👍🏻

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

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

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

В такие моменты главное — не сорваться и удалить весь проект целиком. Нужно распутать этот клубок, даже если очень не хочется. Падать — это нормально, пока есть силы, чтобы снова подняться. Главное — не пытаться решать проблему с тем же настроем и теми же «мозгами», которые привели к такому исходу.

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

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

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

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

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

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

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

Сегодня был очередной созвон, где мы не разбирали код, а просто делились своими успехами и неудачами. Мне рассказать было особо нечего: я как дописал свой прошлый проект, практически ничего не делал. Лёгкая простуда переросла во вполне себе полноценную болезнь. Так что я решил сделать небольшой перерыв на 3–4 дня, пока не стану чувствовать себя лучше.

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

«Пока ты отдыхаешь, другие люди уходят вперёд. Отдохнёшь, когда достигнешь определённого этапа по плану».

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

Не буду спорить, такая стратегия тоже может быть рабочим вариантом. Хотя подходит она от силы одному-двум из десяти.
К сожалению, разумные люди, которые опираются на свои ощущения и знают предел своих сил и возможностей, которые умеют корректировать свои планы, а не ломать своё тело и психику ради цели, плохо продавались бы в качестве главных персонажей книг и фильмов.

Так что я не чувствую никакой вины или грусти по потерянным 4 дням.
Я ничего не потерял и ни от кого не отстал.
Я не персонаж книги, я обычный человек, который идёт к своей цели.

На прошлой неделе сдал последнюю задачу по третьему модулю.
Ментор оставил больше 30 комментариев: снова куча ошибок по стилистике и даже пара потенциально критических.
В этот раз я решил не бежать сразу всё править. Похоже, что, исправляя ошибку на автомате, мозг просто вычёркивает её из списка проблем, и в следующий раз в похожей ситуации красная лампочка «Внимание!» не загорается. Поэтому теперь я превращаю замечания в чек-лист и возвращаюсь к нему перед сдачей каждой новой программы.

Посмотрел на свои последние проекты и сравнил с тем, что знал о Go-разработке в начале курса. Приятно удивился. Моё понимание программирования сильно изменилось. Возможно, дело в специфичной культуре самого Go, но так или иначе — ни книги, ни курсы до этого не давали такого эффекта. Думаю, ключевую роль сыграло живое общение с реально крутыми программистами.

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

Немного пофилософствую 🧐

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

Нет правильного или неправильного пути. Есть только тот, который нужно пройти именно тебе.

Немного выпал из учебной жизни, ездил на родину Страды 😜
Отдохнул, переключился — и вот уже вернулся в рабочий режим.
В прошлую пятницу закончился мой второй месяц обучения.

Описывать подробно, чем я занимался в этот раз, не буду. Оставлю это на следующий месяц, потому что в этом ритм учёбы был очень рваный. Я то писал код 3–4 дня почти по 10 часов, то 2–3 дня занимался рабочими и домашними делами или отдыхал. Из итогов могу отметить, что я закончил 3-й модуль и сегодня вот сделал чуть больше трети 4-го. Познакомился базово с тестами, с архитектурой папок, которая принята в Go-проектах, и с веб-сервером Gin.

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

Если вы перфекционист, это может побудить вас всё бросить, повесив табличку: «Это, наверное, не моё». Но если постараться подстроиться под изменения графика, выкинуть из головы красивые картинки, которые многие видели в соцсетях, где люди "красиво" учатся — процесс будет продолжаться.

Самое главное правило в учёбе, которое я себе повторяю каждое утро: «Дисциплина — прежде всего». Это действует на меня как магическое заклинание. Даже небольшие усилия лучше, чем отказ от борьбы.

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

История появления тестов начинается в 1950-х годах.
Во времена, когда компьютеры были огромными, а машинное время стоило колоссальных денег, но программисты всё равно, на свой страх и риск, загружали перфокарты с кодом, надеясь, что лампа внутри ЭВМ не перегорит, а программа выдаст результат.

Первой на это обратила внимание одна из выдающихся программисток того времени — Ида Роудс. Она поняла, что проверять программу «в лоб» на реальных данных — это путь к катастрофе.
Она предложила метод, который назвала Picture Runs (образные прогоны).

Суть метода такова:

— Выделить логику: взять только изолированную математическую формулу или часть алгоритма.

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

— Сравнить результаты: машину запускали только на этом микро-наборе данных. Если «картинка» совпадала, то алгоритм работал правильно и предсказуемо, и его допускали для анализа больших данных.

Ничего не напоминает? Это был первый в истории прообраз Unit-тестов и концепции ассертов (утверждений), когда корректность кода доказывается прогоном через заранее известный тест-кейс.

Но тесты не сразу были приняты сообществом программистов на вооружение. Ещё очень долго их считали чем-то второстепенным.

В 60-х годах применяли «каскадную модель разработки».
Процесс шёл строго сверху вниз: проектирование → написание кода → сборка → тестирование.
На практике это означало, что тестам практически не уделяли внимания. Код проверяли «на коленке» сами разработчики.

В 70-х индустрия поняла, что разработчик подсознательно защищает свой код и проверяет только то, что работает.
В то же время выходит книга Гленфорда Майерса «Искусство тестирования программного обеспечения». В ней он говорит о том, что цель тестирования — не доказать разработчику, что он написал "некачественный код", а найти ошибки и баги, которые обязательно всплывут после. Под влиянием этого появляются целые отделы тестеров, которые занимаются тем, что пытаются «сломать» программу, найдя в ней уязвимости и ошибки.

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

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

🚀 История про надежды: крушение космической станции «Луна-25» (2023 год).
Бортовой компьютер выдал команду торможения, но блок датчиков скорости не включился из-за внутренней ошибки. Алгоритм не получил никаких данных, не выдал ошибку и просто бесконечно ждал, пока станция не врезалась в Луну.

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

Решение: Юнит-тестирование функции управления двигателем на граничные значения (Edge Cases). Нужно было проверить поведение кода, если на вход вместо массива данных от датчиков приходит nil или пустая строка, и жёстко зашить защитный тайм-аут по времени.

💸 История про деньги: банкротство финансового гиганта Knight Capital (2012 год).
Компания обновляла код на серверах, но на одном из восьми узлов случайно остался старый исполняемый файл. При запуске торгов этот «сервер-зомби» начал использовать новые конфигурационные флаги со старой логикой, устроив хаос на бирже.

Последствия: Потеря 440 миллионов долларов всего за 45 минут и мгновенное банкротство компании.

Решение: Интеграционное тестирование всей инфраструктуры и сквозная проверка деплоя. Тест на тестовой среде перед запуском в прод сразу бы выявил, что один из узлов сети отвечает некорректно и нарушает общую логику системы.

💔 История про жизни: смертоносный медицинский аппарат Therac-25 (1985 год).
Из-за ошибки в параллельных потоках управления на ассемблере возникало «состояние гонки». Если оператор клиники вводил данные слишком быстро (быстрее 8 секунд), один поток перезаписывал память другого, и аппарат выдавал струю чистой радиации вместо безопасного рентгена.

Последствия: Тяжёлое облучение и гибель нескольких пациентов.

Решение: Стресс-тестирование интерфейса и тесты на многопоточность. В современном Go для предотвращения таких трагедий используют каналы, мьютексы и встроенный детектор гонок (go test -race), который ищет одновременный доступ к памяти на этапе сборки.