Всем привет! 👍
🤸 Меня зовут Тимур😐, я работаю Golang разработчиком в платформенной команде в одной из крупнейших компаний на российском рынке, до этого писал на Python в Cloud.ru.

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

Люблю котов, для них у меня есть отдельный канал

👍 Всем привет, подписчики! 🔍
😧 Сегодня хочу поднять важную тему — использование нейросетей в работе программиста.

Сейчас появился своего рода “шорткат” в виде нейросетей: можно минимально напрягаться, просто формулировать запросы и получать готовые решения. Нужно лишь подобрать правильный промт. Но, выбрав такой путь, вы рискуете через пару лет оказаться невостребованными на рынке труда. Почему? Потому что всё, что вы сможете делать — это читать задачу, загружать кодовую базу в нейросеть и мучить её запросами, пока не получите валидное решение. 🤬

🍎 В чём основная проблема?
⏺ Нейросеть даёт ответы, но не объясняет их.
⏺ Мы быстро привыкаем к этому удобству и перестаём думать самостоятельно.
⏺ Проще написать очередной запрос, чем разобраться в сути задачи. 😘

🤔 Как правильно использовать нейросети в работе?
Меняйте подход с “хочу быстрее сделать X любой ценой” на “хочу понять, как это работает, и научиться использовать этот инструмент”. Это особенно важно, если вы только начинаете карьеру.

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

Накидайте 🔥 и я расскажу вам свою историю "тупения" из-за нейронок.

Всем привет!👍
История о том, как я два раза отупел, но смог восстановиться(но это не точно).😘

🍎 Мое знакомство с ChatGPT началось еще в 2023 году, когда я работал Python-разработчиком.
🔊Использовать нейросеть в работе я начал постепенно, но регулярно. В итоге, спустя несколько месяцев, я практически перестал писать код самостоятельно, зато тратил много времени на составление промптов и подачу контекста в нейросеть.😋

🔊Когда я начал готовиться к собеседованиям по Python, быстро понял, что даже простейшие задачи даются мне с трудом — словно я не программировал несколько недель.
Особенно это ощущалось во время длительных перелетов из Новосибирска в Сочи и обратно (4+ часа). Незабываемое чувство беспомощности.😩

🔊После этого я ненадолго отказался от использования нейросетей для написания кода, но перерыв оказался коротким. Летом 2024 года я решил попробовать Supermaven (аналог Copilot, но работал без VPN).

🔊На работе требовалось писать много кода, и мне показалось, что такой инструмент поможет “увеличить производительность”. Так я проработал около двух месяцев и буквально разучился программировать без помощника.😐

🔊Переломным моментом стала ситуация, когда мне нужно было в режиме лайвкодинга показать что-то коллеге. Мы созвонились, я пошерил экран и вдруг понял, что мой “помощник” не работает (обновился плагин в Vim, и нужно было заново ввести ключ). Когда настал момент что-то закодить, я просто сидел и тупил, как человек, который никогда не писал код.🤬
Со стороны это выглядело еще хуже.😩

🔊После этой встречи я решил больше не пользоваться автокомплитом. Такой инструмент слишком легко “отключает” мозг: ты смотришь на код и думаешь — “ну, вроде норм”, а через пару дней фиксишь баги, которые он наплодил с твоего молчаливого согласия.😐

🔊Когда пишешь код самостоятельно, приходится держать весь контекст в голове, постоянно думать и анализировать свои решения. Благодаря этому логические ошибки можно заметить и исправить сразу. В случае с “помощником” контекст находится внутри него, тебе не нужно его удерживать, а значит, ошибки сложнее отловить.🤔

🔊Copilot и прочие помощники определенно повысят твою производительность в моменте, но расплачиваться придется своим временем в будущем. Это как пить энергетики чтобы не заснуть, вроде бы помогает, но потом отсыпаешься по 12+ часов.🤬

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

😐 ЗА ЧЕСАНИЕ ЯЗЫКОМ ТОЖЕ ПЛАТЯТ ДЕНЬГИ, НУЖНО ВСЕГО ЛИШЬ… 😂

Уже представили, как вы, лёжа с ноутбуком, получаете 600 к в наносекунду? 😁
Тогда читайте внимательно.

😱Сегодня поговорим о софт-скиллах.

Вы наверняка много раз слышали, что зачастую софт-скиллы важнее хард-скиллов в IT. Однако понятие софт-скиллов очень размыто: сюда можно притянуть даже ваше умение пить пиво литрами на корпоративе🍺. Но это не те софт-скиллы, за которые вам заплатят деньги (хотя это не точно).

👍Какие софт-скиллы повысят вашу зарплату?

Я выделяю несколько важных навыков, которые помогут вам увеличить доход:
⏺ Фича-лидерство — умение управлять краткосрочными и долгосрочными проектами, обеспечивать прозрачность процессов, а также правильно презентовать результаты своей работы.
⏺ Коммуникабельность — способность ясно и эффективно доносить информацию до коллег, особенно тех, кто не погружён в контекст вашей системы.
⏺ Problem solving — ориентация на решение проблем стейкхолдеров, а не только на выполнение конкретных задач в Jira.
⏺ Фасилитация дискуссий — умение эффективно организовывать и направлять групповые обсуждения, обеспечивая участие всех членов команды и достижение конструктивных решений.

❔ Как прокачать свои софт-скиллы?

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

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

😘ПРОГРАММИРОВАНИЕ ЭТО ВИРТУАЛЬНЫЙ ЗАВОД⌛️

😐Если вы ещё не работаете в IT-индустрии, профессия программиста может казаться чем-то вроде алхимии: творческой, сложной, «недоступной простым смертным». Этот миф упорно культивируют скуфы-гейткиперы с синдромом бога. Только не показывайте им этот пост — рискуете обрушить их манямирок и нарваться на истерику. Оно вам надо?💀

На самом деле программист — это заводской рабочий XXI века. Судите сами: мы штампуем винтики и болтики, из которых собирают корпоративные «машины». График, оклад, KPI. Разница лишь в том, что вместо станка — редактор кода, вместо спецовки — худи и джинсы.

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

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

😐Да, сегодня программисты в дефиците — профессия молодая, спрос задрал зарплатные вилки. Но вспомните историю: когда-то и ткачи ручной работы ценились на вес золота. Пока не изобрели станки. Когда мы приблизимся к цифровой сингулярности, наш труд станет таким же массовым, как труд столяра или сварщика. Зарплаты сравняются, романтика испарится — останется рутина.🚬

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

🤩Welcome to the digital factory, comrades!

Я больше не отрицатель нейронок⌛️

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

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

Затестили сегодня https://coderabbit.ai/ для нашего внутреннего проекта. Это реально имба. Делает суммари по изменениям, строит sequence диаграмму, предлагает инлайн саджесты и промты для ai агента для исправления. Будущее наступило😘

🍆 Пока Cursor летит в канаву, Claude Code набирает популярность. Четвёртый день тестирую CC на подписке за 100 долларов — в целом, для большинства задач этого хватает. Но вот за 2,5 часа активной работы лимиты заканчиваются (сбрасываются каждые 5 часов, таймер стартует с первого промта).

Узнал несколько лайфхаков:
⏺Используйте команду /clear после завершения каждой фичи — так окно контекста будет меньше, а значит, и расход токенов снизится.
⏺Для planning mode лучше использовать мощную модель Claude 4 Opus, а для реализации — более дешевую Sonnet.
⏺В существующем проекте можно запустить команду /init, и Claude сгенерирует базовый claude.md — аналог cursor rules.
⏺В memory (с помощью оператора #) можно добавить обязательные действия, которые агент должен выполнять после внесения изменений — например, запуск тестов, линтера, форматтера или проведение security-проверок.

Погромирую miniapp целиком силами вайбкодинга, попробовал много разных подходов, но самым эффективным оказалось создавать отдельных агентов под написание кода и под проработку UI/UX. Самый гемор конечно это искать дыры в безопасности еще одним агентом и тестировать это все руками.

А еще пришлось запариться с локальным запуском miniapp c помощью cloudflare tunnel + traefik.

На все это уходит много времени, но без знаний фронтенда я бы потратил еще больше на написание руками💀

Да кто этот ваш observability?😐

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

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

Представьте ситуацию, когда у вас несколько микросервисов, через которые проходит запрос, в котором проблема, вы смотрите на логи (если они вообще есть😁) и не можете понять, где может крыться ошибка. Вы добавили побольше логов, пытаетесь воспроизвести ошибку и не можете найти лог, привязанный к вашему запросу. После нескольких часов поиска бага, вы рвете волосы на голове и материтесь на монитор (да, было😱).
Я был в такой ситуации, тогда я дебажил асинхронный пайплайн обработки ивентов из очереди. Чтобы разобраться, мне пришлось писать огромные логи принты с исчерпывающими данными о состоянии приложения, вплоть до значений переменных и body запроса. Баг я, конечно, нашел, но какой ценой. Сейчас это кажется смешным, но будь у нас хотя бы нормальные структурированные логи, то баг нашелся бы гораздо быстрее.😣

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

🗒Логи обычно помогают локализовать ошибку в рамках сервиса, с помощью них вы можете найти конкретное место, в котором произошла ошибка, если, конечно, вы правильно написали лог, а не напихали "ERROR: %s" по всему коду. Лучше использовать структурированные логи в формате json, так их проще фильтровать по атрибутам.

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

🎧Метрики же помогают численно описать состояние вашего сервиса, обычно базовые метрики - это latency и ошибки по ручкам + какие-то метрики производительности: загрузка cpu, ram и т.д. Метрики обычно выводятся в Grafana, там вы можете увидеть метрику, привязанную ко времени, так вы можете следить за состоянием сервиса на дистанции. Также на метрики можно настроить алерт, например, можно назначить алерт на всплеск 5xx ошибок у вашего сервиса, так вы сможете сразу узнать о проблемах в вашем сервисе.

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

🫡Если вам интересно послушать о надежности сервисов, то накидайте огоньков и клоунов.