Серебряной пули нет
Такую статью написал Фредерик Брукс, аж в 1986 году, где он утверждает, что, даже в отдаленном будущем, никакая технология, техника менеджмента или способ разработки не улучшат производительность, надежность и простоту разработки ПО. Подробнее об этом можно почитать на вики https://en.wikipedia.org/wiki/No_Silver_Bullet но так как этого все равно никто не сделает, я поделюсь его ключевыми мыслями, так как это очень совпадает с моими представлениями о том, как оно работает.

Если кратко, Брукс определяет два вида сложности: случайная и необходимая.

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

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

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

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

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

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

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

Утром встал, из любопытства глянул - и СРАЗУ понял, в чем проблема. Сразу блин, за ноль минут.

Просто перепутал && и || 😂

Так тупо, капец

В общем, алгоритм от капитана:
1) устал - отдохни (кофе - не отдых, если чо)
2) отдохнул - работай
3) при необходимости повторить

Несколько лет назад с другом обсуждали такую идею, на работников навешивать какой-нибудь аппарат типа ЭЭГ, и замерять уровень усталости (хз, есть такие или нет). Возможно так будет эффективнее (и для работника, и для работодателя), чем среднее по больнице: работай 8 часов с перерывом на обед, и может быть в среднем по планете будет норм.

Пятничный наброс

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

В первом случае ты выдаешь проработанную аналитиками задачу, обкладываешь сотрудников регламентами, правилами, обязательным % покрытия тестами, обеспечиваешь автоматический и ручной контроль каждой строчки, 2 апрува обязательно, навязываешь истинно правильный подход к разработке, объясняешь как именно надо работать с базой данных (с ORM там или без), апрувить новые либы могут только избранные, выкатывать на прод только Вася и только в определенное время и еще 100500 инструкций.

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


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

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

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

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

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

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

Причем всё, можно сказать, практически на пальцах, насколько это возможно. Для тех, у кого нет общего понимания здесь - must read:

https://cpu.land/

Подпишись на канал о разработке Cross Join

В статье про комплексную эффективность разработки есть забавные цифры про концентрацию программиста:

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

Инженеры в больших корпорациях по статистике имеют лишь 16.9 часов в неделю, когда они могут нормально сосредоточиться (против 22.5 в более маленьких компаниях).

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

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

Что можно сделать навскидку: регулярные встречи двигать в самое начало (конец) дня или вплотную к обеду; выделять в календаре блоки времени "я работаю", чтобы никто не вставил туда встречу; на скучных митингах выключать звук - это хорошее время спокойно поработать 🙂

Если серьёзно, то очень хорошо, что эту тему начали поднимать. Пройдет лет 5, и учет непрерывности времени разработки может быть будет стандартом. Хотя, хрен там, наверно 10

P.S. Когда падает прод, чайка-менеджмент из серии "ну че, скоро там почините?" тоже не добавляет концентрации

Петя в канале "Пятиминутка PHP" (советую подписаться!) скинул восхитительную новость. Так вот для чего были все эти вопросы на собеседованиях про сортировку :)))) 👇

Замена алгоритма сортировки в sysinit позволила ускорить загрузку FreeBSD
Во FreeBSD принято изменение, меняющее в коде инициализации ядра (sysinit) алгоритм сортировки массивов. Вместо ранее применявшегося алгоритма пузырьковой сортировки в sysinit задействован более эффективный алгоритм сортировки слиянием, что позволило на 2 мс сократить время загрузки ядра в виртуальных машинах Firecracker.

Ого, в Microsoft Excel добавили поддержку Python. Для анализа данных, очистки, визуализации (matplotlib и др), machine learning и так далее. Запускаться это будет в облаке Microsoft Cloud. Достаточно лишь написать "=PY", больше ничего якобы настраивать будет не надо.

https://techcommunity.microsoft.com/t5/excel-blog/announcing-python-in-excel-combining-the-power-of-python-and-the/ba-p/3893439

Оказывается, в Гитлабе можно настроить MR так, чтобы сразу подсвечивалось полосками, какие строки покрыты тестами, а какие - нет. Для этого надо ваш файл покрытия сконвертировать в xml нужного формата (cobertura) и положить это в артифакт:

  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage.xml

(подробная инструкция здесь)

Далее, после того как весь пайплайн полностью пройдет, появится подсветка, как на картинке выше.

Для языка Go покрытие конвертируется в xml с помощью утилиты gocover-cobertura, для других языков тоже есть аналоги.

Пример:

go test -coverprofile  cover.out ./...

go install github.com/boumenot/gocover-cobertura@latest

gocover-cobertura < cover.out > coverage.xml

P.S. Гоша, спасибо за наводку :)

git - мерзавец, мудак
github - хаб мудаков
gitlab - лаборатория мудаков
trunk - ствол
log - бревно
logger - дровосек
bash - погром
shell - оболочка
yarn - пряжа, нить
node - узел
RESTful - спокойный
docker - портовый грузчик
MySQL часто произносят как my sequel, т.е. "моё продолжение"
Oracle - предсказатель, оракул
daemon - демон
stack - стог
heap - куча
noscript - сценарий

Java, Kotlin - остров Ява, остров Котлин
Rust - ржавый
Swift - стриж, быстрый

Angular - угловой
scrum - схватка, баталия

Чего только не бывает на свете.

https://smolsite.zip/ - позволяет разместить содержимое сайта прямо в урле. Т.е. можно взять папку, в которую положить index.html, картинки и т.д., зазиповать, перегнать в base64 и добавить в урл после слеша: https://smolsite.zip/[тут ваш base64]

Вот пример

В итоге, ваш сайт отобразится по этому урлу.

Непонятно только зачем, а главное - науя

Очень интересное приложение нашел. Общаешься голосом с роботом (на основе chatgpt) и тренируешь английский. Задания там всякие и всё такое. Для английского я его и поставил. Удобнее, чем italki и skyeng, потому что не надо назначать время, подгадывать, а просто учишь, когда хочешь, хоть 24/7. И на порядки дешевле.

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

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

В конце он мне еще и рассказал, что я там сказал не так, что "to rule" - это грубо, лучше "to lead", что у меня бедноватый словарный запас там то и там то. Просто супер. Да, он иногда бывает глуховат и странноват, но и реальные преподы не лучше.

Просто 11/10

В языке Go меняют фундаментальную вещь - цикл. Если раньше в циклах были проблемы с замыканиями, так как переменная цикла имела скоуп всего цикла, а не одной итерации, то в 1.22 это поведение поменяют.

проще показать на примере:

```go

 funcs := []func(){}

 for i := 0; i < 5; i++ {
  funcs = append(funcs, func() {
   fmt.Println(i)
  })
 }

 funcs[0]()

```

Последняя строка примера напечатает 5 в go 1.21, но в go 1.22 будет уже интуитивно понятный 0.

С одной стороны, это вроде бы нарушение обратной совместимости, но зато не надо писать пугающее новичков i := i для починки скоупа.

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

Говорят, такой же трюк проделывали с C# в 2012 году, и все довольны

UPD. Написал статью на Хабр

#golang

Мотивация и сложность

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

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

Так как же стыковать эти нестоковочки? Я предложу несколько своих вариантов, а вы предложите в комментариях свои. Уверен, у многих найдутся какие-то интересные лайфхаки на этот счет.

Йеркс-Додсон
Сначала хотел написать вам про закон Йеркса-Додсона, который говорит, что сложные задачи даются хорошо при слабом уровне мотивации, легкие – при высоком, а средние – при среднем. Но если почитать, что же за эксперименты эти господа проводили, то окажется, что «мотивацией» они называют удары током. Вернее мотивация – это то, что вас током били, а теперь перестанут, если задание сделали.
Я подумал, что это к нашим реалиям не очень применимо, тем не менее знайте, что если кто-то вам рассказывает про Закон Йеркса-Додсона и мотивацию, то там «есть нюанс».
Хотя, может, мы чему-то и можем научиться и здесь, например, что желательно людей не бить током, если хотим, чтобы они что-то сложное нам сделали.

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

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

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

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

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

Бонусный контент
Пост на эту тему мы решили написать с моей весьма опытной в сфере управления коллегой Мариной Востриковой. Мы знакомы недавно, но, читая её канал, я понял, что у нас на некоторые вещи довольно схожие взгляды. Сейчас мы и узнаем, насколько 🙂 Её пост тут.
А ещё Марина – одна из немногих моих знакомых, кто написал книгу. Всегда такое дело во мне пробуждает большое уважение.

Ключ к эффективности разработки: делать то, что нужно, но лишнего не делать.

Кучу времени можно сэкономить если:

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

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

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

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

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

Проверять на код ревью важные вещи
Не докапываться до стилистических мелочей и вкусовщины, а некоторые очевидные MR(PR) вообще не проводить через код ревью

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

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

Я призываю всегда думать и взвешивать вероятности. Быть осознанным. Ключевой вопрос "А что будет, если не делать?". Это точно окупится.

Короче, нормально делай - нормально будет, и подписывайся на Cross Join

Написал статью, про то, как найти мёртвый код в Go-программе, а также заодно пересчитать тестовое покрытие относительно живого кода

https://habr.com/ru/companies/karuna/articles/764326/

В последние дни несколько раз натыкался на обсуждения ниши языка Go

Вот краткое резюме:

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

C++ производительнее, но очень сложный и надо внимательно следить за памятью

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

Rust суперсложный.

Java, PHP, Ruby и т.д. - они не такие дубовые синтаксически, как Go, но производительность в большинстве случаев на практике получается намного хуже. И научиться языкам с нуля сложнее.

Go - где-то по середине. Это идеологически как C (такой же бедный), но только туда вкорячено еще чуть-чуть ООП (без наследования), горутины и управление памятью.

Т.е. если нужно писать большой монолит со 100 слоями абстракций - Go подойдет наверно не очень, лучше брать Java.

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

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

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

Хотя программирование там тоже есть )
Надеюсь, его зарождающийся бизнес выстрелит!

https://habr.com/ru/articles/766054/

Вопрос от анонима (мопед не мой), нужен совет, бест практис:

"Я иногда собеседую людей и меня всегда удивлял тот факт, что никто еще не сделал идеального мониторинга.
Мы для себя придумали правила, по которым пытаемся настраивать мониторинг, чтобы он отвечал на главный вопрос - надо ли отрывать жопу и бежать фиксить.

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

Тут надо отметить, что не все нотификации приводят к алерту (не отсылаются в on-call), а только те, что мы определили как Critical. Warning и Info просто насыпают в Slack.

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

Как побороть это говно? Как сделать мониторинг, в котором будут только реальные проблемы?"