Вы пользуетесь системами контроля версий?

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

Разработчики далёкие от дата-инженерии тут должны вытаращить в ужасе свои глаза. Но так сложилось, что в олдскульных DE-подходах логика часто строилась на хранимых процедурах внутри DWH или проприетарных SSIS-пакетах. Хотя те же SSIS-пакеты всё таки в Гите мы сохраняли, но следить за конкретными изменениями так было невозможно, оставалось доверять лишь комментариям автора коммита.

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

Всем кто считает себя инженером советую немедленно прокачаться в Гите. Я и сам продолжаю закрывать пробелы в образовании, вот решил освежить голову на родном Степике: https://stepik.org/course/3145/syllabus

Но эта версия курса, похоже, что оказалась урезанной. Но ничего страшного, по Гиту в интернете ещё очень много материалов. Например, таких (осторожно, мат)

В личку пишут ознакомиться с курсом от Хекслета: https://ru.hexlet.io/courses/intro_to_git

P.S. Конечно, бесплатным. Я вам так просто платное не буду советовать)

Саморефлексии пост

Вдруг обнаружил странную логическую цепочку в своей голове с примесью селф-эйджизма и FOMO.

Началось с ситуации: я решил попробовать Codex — ИИ-агента от OpenAI, который встраивается в VSCode и работает по типу Copilot. И он как-то меня взбесил своей медленной работой и не очень адекватным результатом, что я его тут же отключил и... начал испытывать чувство (!) вины, что я не тренде и не использую модные популярные ИИ-агенты! Следом закрались мысли, что вот уже мозги стареют, отрицают новое.

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

Потом я успокоился, понял, что мне так комфортнее. ChatGPT теперь живёт в отдельном приложении, чтобы не путаться во вкладках браузера. Код я пишу сам, к ИИ хожу не с просьбами, а с вопросами. Тире тоже в текстах пишу сам. Внутри VSCode минимум расширений, разве что Pylance. Ещё бы в Телеграм лишний раз не заходить во время работы, тогда всё будет замечательно.

Где-то на Реддите увидел мельком совет не зацикливаться на SQL и ETL, а позиционировать себя как универсального SWE — Software Engineer. Читать холивар ниже я не стал, т.к. изначально искал инфо вообще по дата-инженерным инструментам.

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

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

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

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

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

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

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

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

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

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

Вместо метафор из РПГ мне больше нравятся метафоры из мира инвестирования: при инвестировании в себя у нас есть как минимум две метрики — риск и доходность. Для упрощения по дефолту будем считать, что вы инвестируете свои ресурсы только в интересные вам направления, а то добавление скуки/интереса слишком всё усложнит.

Что такое риски при инвестировании в себя как специалиста? Это про потенциальный разброс результата.

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

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

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

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

Что мы можем инвестировать в себя? Время, деньги, но ещё больше мне нравится мыслетопливо по Дорофееву. Грубо говоря ваш мыслительный ресурс ограничен и заставлять себя учиться и работать по 12 часов в сутки, расписывая всё по тайм-менеджменту не выйдет. Постоянная работа тоже отжирает большую часть мыслетоплива, поэтому встаёт вопрос, как найти свободные литры мыслетоплива, чтобы прокачивать себя параллельно основной работе.

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

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

Что можно сделать? Как вариант, начать научить себя (!) не пользоваться смартфоном дома при возможности решить вопрос через компьютер.

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

И всё таки я в последние полгода смог сократить экранное время смартфона в пользу компьютера. Что я имею? Например, полный отказ от коротких видео, ведь на телефоне принципиально не установлен VPN. И да, спасибо РКН, что он бережёт мою психику. Я не шучу. Блокировки только сначала кажутся дикостью и посягательством на свободу, но по факту блокируются довольно вредные пожиратели свободного времени. Нет, мессенджер МАХ я рекламировать не буду, обычная сотовая связь и без мессенджеров ловит на парковке.

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

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

Always be the worst guy…

Always be the worst guy in every band you’re in. If you’re the best guy, you need to find another band. And always be around people who are better than you, so you can learn.

– Чад Фаулер, «The Passionate Programmer»

Эта фраза из книги так зацепила меня, что я решил осмыслить ее через написание поста 🙂

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

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

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

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

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

Наша траектория формируется не великими решениями, а ежедневными мелочами. С кем мы работаем. У кого учимся. Как проводим время. Куда ходим – на конференцию или в бар. Хотя, если честно, и в баре иногда завязываются отличные знакомства – просто не стоит делать это своей основной стратегией развития 🙃

Поэтому если чувствуешь, что вокруг все слишком знакомо и спокойно – возможно, пора сменить окружение.

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

#мысли

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

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

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

Проблема ритейла была в том, что он был ограничен стеком от MS SQL и Windows Server просто из-за недостатка ресурсов на нормальную инфраструктуру (это типично для многих компаний масштабом поменьше Х5)

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

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

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

Те кто читаю мой канал, наверное заняты интеллектуальным трудом. В основном меня читают дата-аналитики и дата-инженеры, а эта работа требует концентрации внимания.

Спонсор нашего сегодняшнего поста — цифровая депривация!

Мой маленький отчёт: зависимость от телефона оказалась мной преувеличена, а недооценённой оказалась зависимость от Телеграма: общение с друзьями, чтение разных каналов и тд.

Каковы рецепты противодействия цифровой зависимости, которая портит концентрацию и мешает работе?

1) Убирать телефон из поля зрения. Прямо в момент начала написания поста я не знал, где находится мой телефон. Правда, когда я уже задумался, то нашёл его. А если я не знаю, где находится мой телефон, то я не могу машинально его достать и отвлечься на какое-либо приложение.
Хинт: можно поставить себе правило не находиться в одной комнате с телефоном, если нужна концентрация. Работать, читать книжки — всё в комнате, где телефона нет рядом. В крайнем случае убирать его в тумбочку с глаз долой.

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

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

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

Я уже поднимал вопрос на тему дата-инженер — это программист или кто? На днях столкнулся с тем, что иногда стоит быть программистом. Ковырял я инструмент для перекачки данных через кафку под названием Kafka Connect и столкнулся с необходимостью преобразовывать налету сообщения от Debezium.

Напомню, что Debezium — популярный инструмент для CDC, который непрерывно вычитывает из лога базы-источника все изменения данных и кладёт в кафку, например, с помощью коннектора фреймворка Kafka Connect.

И оказалось, что преобразовывать сообщения перед отправкой в Кафку или выгрузкой оттуда можно, для этого есть специальный инструмент — Single Message Transformations (SMT). Но среди готовых SMT я не смог найти нужного, так что умный GPT не посоветовал мне ничего лучше, чем написать свой кастомный SMT на джаве, собрать джарник с помощью Maven и добавить в нашу сборку Kafka Connect как плагин!

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

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

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

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

Лет 10 назад на парах по английскому мы часто смотрели разные TED Talks и разбирали выступления. В качестве практики языка дома я тоже часто смотрел выступления различных мотивационных спикеров на TED, которые очень убедительно излагали: follow your passions, make your dreams come true ...

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

Выступления спикеров на TED, топ-менеджеров корпораций и консультантов из BIG3 про delivering value и corporate values, выступления коммунистов на партийных съездах полвека назад с цитатами Ленина и Маркса — это тот вид речи, который просто целиком состоит из штампов. Автор таких речей похож на языковую модель, которой внутренняя нейросеть подсказывает следующий токен с очередной цитатой классика или общей фразой про ценности, кооперацию, синергию и прочее.

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

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

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

К идее сравнить людей с LLM меня подтолкнула пара приколов.

1) Это шуточный универсальный код речей для выступления перед каким-нибудь рабочим коллективом на советском предприятии.

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

2) Нассим Талеб приводит пример стереотипности человеческого мышления из истории издания своей книги "Чёрный лебедь", которая рассказывает о роли вероятности и случая в нашей жизни (как и все другие книги Талеба).

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

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

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

Это база

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

1. Linux. Как ни крути, но Windows Server в качестве продакшена уходит на пенсию и слава богу. Если вы что-то разрабатываете, то скорее всего оно работает под Linux. Даже если вы запускаете проект в докере, то докер всё равно использует ядро Linux. Практика Linux заключается в работе с командной строкой — command line interface. Этот навык общий для всех UNIX-систем, поэтому маководам тоже совет почаще делать свою работу именно через маковский терминал. В Винде тоже можно настроить работу с командной строкой по-юниксовски, но я бы в 2025 году старался держаться от винды подальше (играть теперь можно и на Linux, ждём Steam Machine)

2. Docker. Так сложилось, что докер уже стандарт разработки. Это не значит, что надо бездумно всё паковать в докер, включая все базы и скрипты, но упаковывать зависимости и логику деплоя вашего приложения в докер стало правилом хорошего тона как не выходить на улицу без штанов. Докер будет проще понять, если вы уже освоили работу с Linux. После докера можно освоить kubernetes и какой-нибудь инструмент для деплоя типа Argo CD, но это уже следующая стадия, куда я сам толком не добрался.

3. Git. Жизнь без контроля версий кода — это мазохизм, поэтому с гитом многие уже поверхостно знакомы. Сегодня существует множество графических интерфейсов с кнопочками для работы с Git, но умение работать с гитом напрямую без кнопочек и LLM поможет вам избежать неловких ситуаций, когда что-то не туда нажали, не ту команду скопипастили и непонятно, как это теперь чинить.

4. CI/CD. Возможно, за вас уже всё настроили девопсы, но освоить CI/CD на примере Gitlab CI не так уж и сложно. Если вы понимаете, как собраны ваши CI-пайплайны, то у вас будет меньше вопросов, почему ваш код не проходит через merge request. Практики CI/CD так или иначе становятся стандартом современной разработки — ведь ни к чему лазать по продакшену и обновлять там код вручную.

5. Сети, протоколы. Тут у меня и у самого пробелы, но отличить TCP от UDP и SSH от HTTP, а также знать, что такое DNS и почему ваш сервис вдруг стал недоступен по имени хоста — это тоже база. Сбои в работе сервисов именно из-за проблем сети не редкость, ведь никто не застрахован от шаловливых ручек админов, которые опять что-то поменяли.

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

Желаю всем не бояться работать ручками и не зависеть от помощи других коллег, так вы почувствуете себя куда свободнее!

GPT как тьютор

Я решил пойти своему же списку "базы" и в свободный вечер уселся поглубже освоить своё владение Linux. Вообще я с Линуксом так или иначе работаю больше 5 лет, но никогда не чувствовал себя прям таки очень уверенным в нём.

Для начала я решил развернуть виртуалку и поставить на неё чистый Debian без графического интерфейса. Настроил SSH, прокинул для этого порт на локалхост, поигрался с файерволлом, перекидыванием файлов через scp, запускал процессы в сессиях tmux...

Выполняя эти, не самые сложные, действия, на каких-то этапах я сталкивался с вопросами, с которыми мне помогал разобраться тот самый Chat GPT. Например, я узнал, что свой публичный SSH-ключ можно прокинуть на сервер с помощью одной команды ssh-copy-id. Также я на практике раньше никогда не пробовал пробрасывать порты через SSH для того же HTTP. Во время настройки сети возникали всякие приколы, когда виртуальная сетевая карта оказывается выключенной, её нужно оживить через ip link, а потом с помощью dhclient выдать этому сетевому интерфейсу свой ip-адрес.

Я начинаю с простой задачи, как настройка SSH —> возникает затык —> GPT даёт совет —> возникают новые вопросы —> новые ответы и так далее как снежный ком нарастает переписка и спектр освещённых тем. Я совсем не ожидал, что буду изучать сетевые интерфейсы через ip a, маршрутизацию до внешней сети через ip route, смотреть за состоянием разных портов через ss и многое другое.

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

Но как я решал с чего начать? Сами темы к изучению может подсказывать тот же GPT, но в качестве источника вдохновения можно использовать курсы и книги, которые готовили живые люди. Одним из источников вдохновения я выбрал просто древнючий курс по Linux от института биоинформатики на Stepik. В каком-то смысле это уже ретро, но фундаментальные знания несильно устаревают и за 10 лет.

Как бы я дальше использовал GPT как тьютора? Брал бы темы из книжек и курсов, раскрывал бы их глубже на практике, задавая вопрос по каждому нюансу GPT. Любые знания должны быть отработаны руками с помощью команд набранных в терминале. Если что-то и копируется из окна с GPT, то разбирается даже не построчно, а побуквенно.

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

Ещё в конце прошлого года пошли разговоры про 2025 как год эффективности, компании массово сокращали бюджеты на фоне высокой ставки (корпорации часто платят по плавающей ставке)...

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

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

Неплохой анализ ситуации на рынке российского айти я прочитал тут. Читательские комментарии приветствуются!

Попробовал посмотреть на итоги года на канале от нейросетки — https://tgwrapped.com/

Забавно посмотреть на себя со стороны (чьей? робота?), особенно с учётом осознанного роста техноскептицизма.

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

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