Мне что-то сегодня не остановиться.

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

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

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

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

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

🫥 Cross Join
⠀

В работе лида очень важно слушать свою интуицию.

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

Например:

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

Короче, в идеале код должен писаться легко и непринуждённо, как пет-проект дома. Если есть какой-то раздражитель, надо его ослаблять (в идеале убирать).

То же самое и с положительными эмоциями:

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

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

🫥 Cross Join
⠀

Чем горутины отличаются от async/await функций в других языках?

Логически это примерно то же самое, но:

1. В Go не надо помечать асинхронные функции специальным ключевым словом async, они все там такие. Т.е. асинхронный код выглядит как синхронный, по сигнатуре не отличишь, только по тому что они делают (есть ли блокировки, сисколы и тд).

2. Стек: в горутинах при блокировке (саспенде) просто сохраняется указатель на стек, сам стек остаётся как был (в куче). Когда функция должна заработать снова, в регистр SP записывается указатель на стек

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

🫥 Cross Join
⠀

Про предварительную оптимизацию.

Слышал, что в VictoriaMetrics абсолютное большинство кода никак не оптимизировано, а задрочено под скорость только пара процентов кода (короче, узкие места). И вроде всё верно.

Однако наткнулся на такой коммент на реддите (там не про victoriametrics, но всё же), вот примерный перевод:

"Вы [...] утверждаете, что ЛЮБУЮ оптимизацию следует откладывать, пока она не станет проблемой. В реальности ваша архитектура буквально может сделать оптимизацию невозможной, если вы её даже не учитывали. Эти архитектурные решения НЕЛЬЗЯ просто переработать позже, если только вы не готовы остановить постоянную разработку новых функций и вложиться в ускорение вашего продукта. В реальности никто не хочет этого делать. Так что вы застреваете с программным обеспечением, которое работает как патока, и молитесь богу, чтобы не появился конкурент, который может делать то же, что и вы, но не раздражая пользователя (что буквально сделала Apple с iPhone и захватила целую индустрию). И вы можете избежать загона себя в угол, просто потратив несколько часов на обдумывание требований к производительности, выявление вероятных узких мест и написание эффективного кода с самого начала."

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

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

🫥 Cross Join
⠀

Почему микроменеджмент - это всегда плохо.

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

Короче, не оптимизируй частности, оптимизируй только результат.

Т.е. если ты заставляешь человека (или команду) выполнять какие-то обязательные приседания:

- % покрытия кодом,
- 2 апрува на ревью,
- строгое абсолютное следование таким-то принципам ( SOLID/шмолид или любым другим),

то система будет стремиться ВНЕЗАПНО к:
- % покрытия кодом,
- апрувам на ревью
- и таким-то принципам.

Но вот будет ли при этом бизнес-результат - это вопрос случайности. Означает ли покрытие тестами X%, что код работает без ошибок? Или что покрыт осмысленный процент кода, а не тот, который легче покрывать? Означает ли апрув на ревью и следование принципам, что бинес-задача сделана правильно и потрачено оптимальное количество времени?

Спойлер: да хой там плавал.

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

тогда разработчик (команда) сделает ВНЕЗАПНО так, что

- сделаны важные задачи для бизнеса
- прод не будет валиться
- код будет более менее

Ну, люди в целом делают примерно то, что просят )

И если сделает - то будут какие-то плюшки, не сделает - будут какие-то антиплюшки. Система оптимизируется в правильном направлении. А какие там принципы, покрытие кода или, может, вообще, вместо этого шаман в бубен бил - не важно.

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

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

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

В общем, микроменеджмент противоречит теории систем.

Вот такой вот воскресный наброс на канале 🫥 Cross Join
⠀

Ментальные ловушки софтваре девелопера
в статье прям всю мою жизнь описали.

TLDR:

1. Планирование и оценки:

Ошибка планирования — недооценка времени на задачи, даже имея опыт подобных проектов

Эвристика доступности — принятие решений на основе недавних событий, а не реальной статистики

Эффект якоря — слишком сильная привязка к первой полученной оценке


2. Выбор инструментов:

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

Синдром "не изобретено здесь" — отказ от готовых решений в пользу разработки с нуля

Эффект присоединения к большинству — выбор трендовых технологий без учета реальных потребностей


3 .Работа в команде:

XY-проблема — попытка решить неправильно сформулированную задачу

Ошибка атрибуции — обвинение людей вместо анализа системных причин

Конформизм — молчание при несогласии с групповым решением

Предвзятость авторитета — слепое следование мнению старших коллег


4. Самооценка:

Синдром самозванца — недооценка собственных навыков

Эффект Даннинга-Крюгера — переоценка способностей новичками и недооценка экспертами

Эгоистическая предвзятость — приписывание успехов себе, а неудач — внешним факторам


5. Принятие решений:

Эффект IKEA — переоценка собственного кода и сопротивление рефакторингу

Велосипедный сарай — фокус на мелочах вместо важных проблем

Искажение выжившего — изучение только успешных кейсов без анализа провалов

Предвзятость подтверждения — поиск фактов, подтверждающих существующие убеждения


Вот такие когнитивные искажения на канале 🫥 Cross Join
⠀

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

https://github.com/gauntlet-lang/gauntlet

Вот описание от авторов языка, я с половиной не согласен, но в целом что-то в этой идее есть.

Какие проблемы Go решает Gauntlet?

- Раздражающая ошибка "неиспользуемая переменная"
- Многословная обработка ошибок (if err ≠ nil повсюду в вашем коде)
- Неудобный способ импорта и экспорта (например, использование заглавных букв для экспорта)
- Отсутствие тернарного оператора
- Отсутствие выразительной конструкции switch-case
- Сложные циклы for
- Странный оператор присваивания (чья это была идея использовать :=)
- Отсутствие способа плавно связывать функции в цепочки

Возможности языка

- Транспилируется в поддерживаемый, легко читаемый код на Golang
- Использует точно те же соглашения/идиомы, что и Go. Практически отсутствует кривая обучения.
- Последовательный и знакомый синтаксис
- Практически мгновенное преобразование в Go
- Простая установка с помощью единственного самодостаточного исполняемого файла
- Красивая подсветка синтаксиса в Visual Studio Code

Пример

package main

// Seamless interop with the entire golang ecosystem
import "fmt" as fmt
import "os" as os
import "strings" as strings
import "strconv" as strconv


// Explicit export keyword
export fun ([]String, Error) getTrimmedFileLines(String fileName) {
  // try-with syntax replaces verbose `err != nil` error handling
  let fileContent, err = try os.readFile(fileName) with (null, err)
  
  let fileContentStrVersion = (String)(fileContent) // Type conversion

  let trimmedLines = 
    // Pipes feed output of last function into next one
    fileContentStrVersion
    => strings.trimSpace(_)
    => strings.split(_, "\n")
    

  // `nil` is equal to `null` in Gauntlet
  return (trimmedLines, null)
    
}


fun Unit main() {
  let a = 1 // No unused variable errors

  // force-with syntax will panic if err != nil
  let lines, err = force getTrimmedFileLines("example.txt") with err
  
  // Ternary operator
  let properWord = @String len(lines) > 1 ? "lines" : "line"

  let stringLength = lines => len(_) => strconv.itoa(_)

  fmt.println("There are " + stringLength + " " + properWord + ".")
  fmt.println("Here they are:")

  // Simplified for-loops
  for let i, line in lines {
    fmt.println("Line " + strconv.itoa(i + 1) + " is:")
    fmt.println(line)
  }

}

🫥 Cross Join
⠀

Go отказывается от улучшения синтаксиса обработки ошибок

Команда разработчиков языка программирования Go приняла решение: они прекращают попытки изменить синтаксис для обработки ошибок. Об этом сообщил Роберт Грисемер в официальном блоге проекта.

Проблема, которую не смогли решить

Многословность обработки ошибок в Go — это главная жалоба разработчиков уже много лет. Типичный код выглядит так:

x, err := call()
if err != nil {
    // обработка ошибки
}

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

Безуспешные попытки решения

За 7 лет команда Go предложила несколько вариантов:

2018 год: механизм check/handle — слишком сложный
2019 год: встроенная функция try() — скрывала поток управления, получила резко негативную реакцию сообщества
2024 год: оператор ? (как в Rust) — также не получил поддержки

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

Почему решили остановиться:

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

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

Что дальше?

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

🫥 Cross Join
⠀

Вышел go 1.25 rc1 (ожидаемая дата релиза: август 2025)

Вот некоторые штуки, которые там есть:


>> Среда выполнения (Runtime)

GOMAXPROCS теперь учитывает контейнеры

На Linux автоматически ограничивается лимитами CPU в cgroup (важно для Kubernetes)
Динамически обновляется при изменении доступных CPU

Новый экспериментальный сборщик мусора

Включается через GOEXPERIMENT=greenteagc (описание GC)
Обещает снижение накладных расходов на 10-40%



>> Инструменты

Команда go

Новая директива ignore в go.mod для исключения каталогов

go doc -http запускает веб-сервер с документацией

Поддержка JSON в go version -m -json

Новые анализаторы в go vet

waitgroup - находит неправильное использование sync.WaitGroup.Add

hostport - предупреждает о проблемах с IPv6 в сетевых адресах



>> Стандартная библиотека

Новые пакеты

testing/synctest - для тестирования конкурентного кода

encoding/json/v2 - экспериментальная новая реализация JSON (быстрее декодирование)

Улучшения производительности

Компилятор чаще размещает слайсы на стеке

Параллельное выполнение cleanup-функций в runtime



>> Безопасность и исправления

Компилятор

Исправлена проверка nil-указателей (некоторый код может начать паниковать)

// этот код ошибочно не паниковал в случае ошибки, 
// хотя f использовалось до проверки err != nil
package main

import "os"

func main() {
    f, err := os.Open("nonExistentFile")
    name := f.Name()
    if err != nil {
        return
    }
    println(name)
}

Генерация отладочной информации в формате DWARF 5

TLS

Запрещены SHA-1 алгоритмы подписи в TLS 1.2

Поддержка Encrypted Client Hello

🫥 Cross Join
⠀

Теория ограничений (ТОС): как работает на практике?

Тема нового эпизода — теория ограничений систем, также известная как теория ограничений (от англ. Theory of Constraints, ТОС).

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

Будем выходить на уровень надсистемы, а ещё пофилософствуем, действительно ли всегда люди должны быть заняты и какой жизнью жить — лёгкой или полной?

Наш проводник в этой теме — Саша Брызгалова, практик, эксперт и немного фанатик ТОС.

Дискутируем, накидываем на вентилятор, приводим примеры, чтобы разобраться:
👉 Что есть теория, что система, а что — ограничение?
👉 В каких системах есть ограничения и чем они не являются?
👉 С какой целью создаются системы и как связаны цели личные и цели компании?
👉 Что является самым популярным ограничением в проектном управлении?
👉 Когда «упороться по-максимуму» сыграет злую шутку?
👉 Что такое локальная оптимизация и почему правила во имя неё губят систему?
👉 Почему незавершённые проекты и переключения — бич для эффективности? Никогда такого не было, и вот мы опять обсуждаем эту тему 🫠
👉 В каких ситуациях, работая работу, чувствуешь себя молодцом?
👉 Какие установки нам мешают достигать целей и чем вредны KPI?
👉 Почему аргумент «мы всегда так делали» aka «так исторически сложилось» не аргумент вовсе?
👉 Для каких проблем ТОС не подходит и в каких случаях инструменты не эффективны? Ещё больше примеров в докладе Саши.
👉 Какой вопрос из теории ограничений непременно стоит себе задать?
👉 Win-win решения — правда или вымысел?
👉 С чего же начать, чтобы внедрить теорию ограничений в свою работу?

Этот эпизод, как и весь сезон, выпускается при поддержке драйвовой команды инженеров — @AvitoTech. Ребята создают сервисы, которыми пользуется треть жителей России каждый месяц.
В июне знакомьтесь с ними лично: с 10 по 15 июня, Сочи, South Hub — встречайте активности от C-level, и 26-27 июня, Санкт-Петербург, Saint TeamLead Conf — заглядывайте в playbook lounge, чтобы понетворкаться и узнать ценности и принципы каждого тимлида в AvitoTech.

🎙Ведущие выпуска — Виктор Корейша, руководитель направления Managed Services в Ozon, и Евгений Антонов, ведущий технический менеджер в Yandex Infrastructure, автор канала «Тимлид Очевидность».

🎧 Слушайте подкаст «Кода кода» в Яндекс Музыке, Apple Podcasts, Spotify, VK и много ещё где по ссылке: https://kodakoda.mave.digital/ep-84

🐝 Пишите отзывы, предлагайте темы, спорьте или соглашайтесь с гостями и ведущими.
Внимательные слушатели, ставьте ⚡️к этому посту.
Нам важна ваша обратная связь!

Реклама. ООО «‎Авито Тех»‎, ИНН 9710089440, erid: 2SDnjcQ4ZD7

прикол.

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

Из интересного:

Отношение к искусственному интеллекту среди лидеров становится все более скептическим. Если в 2024 году 42% считали, что ИИ негативно влияет на индустрию, то в 2025 эта цифра выросла до 51%. Более того, 60% опрошенных не видят значительного роста продуктивности своих команд от внедрения ИИ-инструментов.
Основные проблемы с ИИ связаны с качеством результатов и сложностью интеграции в существующие процессы, особенно в крупных компаниях, где есть вопросы безопасности. Наиболее популярными остаются инструменты для кодирования, автоматической генерации кода и рефакторинга, но даже здесь результаты часто не оправдывают ожиданий.

🫥 Cross Join
⠀

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

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

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

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

Но с развитием прогресса затрачиваемое время на попытки будет неизбежно сокращаться, а "и так норм" будет неизбежно худеть.

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

🫥 Cross Join
⠀

⚡️Как легко отправлять деньги зарубежным фрилансерам?

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

В таких случаях отлично помогает payroll-платформа Stape. Работает по простой схеме: компания заключает договор с российским юрлицом, оплачивает счёт в рублях 1–2 раза в месяц — и всё, дальше платформа берёт всё на себя. Без головной боли с валютным контролем, курсами и выбором платёжных систем. Плюс все расходы можно учесть в бухгалтерии и налогах.

Что получают фрилансеры:

📍 Контракт с американской компанией — это удобно для ВНЖ, счёта в банке и прочего.
📍 Деньги выводятся в фиате или крипте, с быстрой конвертацией — за 1 день.
📍 Все документы (инвойсы, справки и т.д.) для отчётности перед банком или налоговой — в личном кабинете.

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

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

👉 Подробнее — на канале сервиса Stape