Вчора під час пробіжки слухав випуск The Pragmatic Engineer Podcast про те, як побудований AWS S3 і трохи залип. Mai-Lan дуже глибоко розбирає речі, про які зазвичай або мовчать, або згадують одним реченням: data structures like replicated journal, протоколи когерентності кешу, і як усе це разом дозволяє реалізувати strong consistency у S3.

Після подкасту пішов копати далі — і натрапив на книгу A Primer on Memory Consistency and Cache Coherence. Виглядає цікаво + у книзі багато уваги приділено формальній верифікації моделей консистентності. Рівно те, що теж обговорювали в контексті S3: як не просто «вірити», що система коректна, а мати строгі докази цього.

🎧 Подкаст:
https://youtu.be/5vL6aCvgQXU?si=269ZVHpsHVaW7bMR

📘 Безкоштовний PDF книги:
https://pages.cs.wisc.edu/~markhill/papers/primer2020_2nd_edition.pdf

У 2025 році кількість software-інженерів на GitHub досягла 180 мільйонів — лише за минулий рік зростання склало +36 мільйонів. Джерело з деталями.

Історично, коли окремі частини професії стають продуктивнішими, сама професія зазвичай стає популярнішою, а не навпаки. Саме тому я переконаний: 2026 - найкращий рік, щоб почати шлях у software engineering.

Факт: тех компанії вже зараз активно наймають інженерів. Ось відкриті позиції просто сьогодні:
Google — 808 ролей
OpenAI — 117 ролей
Anthropic — 18 ролей
xAI — 24 ролі
NVIDIA — 892 ролі

Ринок не "вмирає" - він ускладнюється. І саме тому попит зростає на інженерів із фундаментальним, глибоким мисленням, розумінням дизайну систем, алгоритмів, перформансу та AI.

👉 CS Osvita якраз про це. Ми вчимо не «синтаксис мови програмування», а інженерне мислення, яке дозволяє: заходити в професію усвідомлено, зростати до рівня Big Tech та топових AI/HFT команд, будувати карєру на роки, а не на хайпі.

2026 — найкращий рік, щоб почати вчитись на software engineer.

Дуже цікава стаття вийшла в Finanical Times. Китай системно інвестує в елітну освіту, щоб виростити власних «геніїв» — через спеціальні класи, жорсткий відбір і олімпіадну модель навчання. Держава шукає та підтримує талановитих дітей з раннього віку, роблячи ставку на математику, фізику та AI. Мета — не залежати від Заходу в науці й технологіях і сформувати власну інтелектуальну еліту, навіть ціною сильного тиску на дітей та звуження гуманітарної освіти.

На жаль, росіяни діють за схожою логікою: випускники їхніх топових вишів, що заснували компанії на кшталт яндекса, вже давно інвестують ресурси назад в університети, які самі закінчили, стимулюючи розвиток науки та олімпіадного руху.


Нам точно не можна відставати в питанні реінвестицій в освіту — це одна з небагатьох стратегій, що працює в довгу.

Anthropic виклали блогпост про те, як витратили $20000 та 2 тижні часу, щоб автономно з нуля зібрати C-компілятор, жодного компайлер-інженера в процесі не було. Замість цього вони запустили 16 інстансів Claude на новій моделі Opus 4.6 (яку щойно релізнули) і дали їм працювати паралельно. Компілятор вийшов на ~100 000 рядків коду на Rust.

Попри весь вау-ефект, скепсис уже під’їхав. Буквально одразу зявилися перші issues - наприклад, компілятор не збирає навіть hello world. Тобто це не готовий інструмент. Плюс важливий момент, модель тренувалася на інтернеті, де вже є купа open-source C-компіляторів. Це не out-of-domain задача. Якщо дивитись на це як на eval - він би не пройшов базові тести, бо тут змішуються training data і "тестування". І до того ж: якщо я введу git clone і зберу gcc - це ж не означає, що я побудував C-компілятор за $0. Тоді виникає логічне питання: $20k - за що саме?

Тому так - це все ще вражає, як демонстрація orchestration, автономності й масштабу. Але ні, це не "job-killing" момент і не доказ, що LLM уже завтра замінять compiler engineers.

Gemini 3.2 вийде раніше, ніж ви встигнете дочитати цю книгу. Але книга точно буде кориснішою 😄

Поки Google випускає чергову "найрозумнішу модель у світі" Gemini 3.1 Pro, - Martin Kleppmann тихо випускає книгу, яка переживе їх усіх. Нова модель SOTA в reasoning, кодингу, STEM. Б'є всіх на бенчмарках. Альтман нервово курить. Звичний понеділок в AI-індустрії. А поки всі стежать за цим - вийшло друге видання Designing Data-Intensive Applications. Без пресрелізів та заяв про революцію. Що нового в другому виданні автор розповів сам. Електронка - вже наступного тижня. Паперова через 3-4 тижні.

Розповім маленький секрет: є книжка, на яку я чекаю навіть більше, ніж на нове видання Клеппмана.

Її автор — Eric Lippert. Людина, яка була Principal Engineer у Microsoft, проєктувала мову C#, працювала над JScript, а згодом у Meta займалася Bean Machine (probabilistic programming, компіляторні задачі для статистичних моделей). Але для мене найважливіше навіть не це.

Приблизно 15 років тому він сильно вплинув на мене особисто. Бо відповідав мені — тоді ще молодому й зеленому — на листи, давав поради, як рости як інженеру, що читати, як мислити про кар’єру і як готуватися до співбесіди у Facebook. Просто написав йому, бо любив читати його блог :)

Тепер він випускає книгу: Fabulous Adventures in Data Structures and Algorithms — про реальний досвід застосування нетривіальних алгоритмів і структур даних. І мені дуже відгукується саме цей кут подачі: не "алгоритми заради алгоритмів", а алгоритми як інструмент інженера в реальних задачах. До речі, є його інтерв’ю про те, чому базова computer science освіта не втрачає цінності навіть в еру AI — дуже рекомендую послухати.

А нижче — уривок з однієї з наших переписок, який мене вразив ще багато років тому. Здавалося б, проста задача — знайти n-те число Фібоначчі. Але почитайте, як мислить сильний інженер:

If I had this question in an interview then I would spend most of the interview discussing the requirements; why does the caller need to know fib numbers? What are they going to do with the output? What inputs are valid? How often is this method going to be called? If I want to memoize solutions, what's my space budget? What's my time budget? The code is trivial; understanding how it is going to be used is the hard part. If the inputs are large, is it acceptable to use Binet's formula, and trade off time for accuracy? If the outputs are BigIntegers, how big do we expect the big integers to get? Tens of bytes, hundreds of bytes, millions of bytes? How are we going to manage that memory?

Оце, як на мене, і є суть інженерного мислення: не просто "написати код", а зрозуміти контекст, обмеження і ціну кожного рішення.

P.S. І якщо вам близький саме такий підхід і не хочеться чекати — у мене якраз стартує курс. Там про власний досвід застосування алгоритмів і структур даних в продакшені - від Dell до Amazon.

Ех, минулого тижня помер сер Чарльз Ентоні Річард Хоар. Легенді було 92 роки.

Для більшості це ім’я асоціюється з quicksort, але його внесок набагато ширший: quickselect, Hoare logic, CSP, вплив на дизайн мов і взагалі на те, як ми думаємо про correctness та concurrency.

Про quicksort цікаво не лише те, що він швидкий. Там сильна сама ідея partition. Із неї природно виростає quickselect: median, p95, k-й елемент, top-k cutoff - без повного сортування. У багатьох таких задачах інженери автоматично беруть heap, але для одноразового selection на статичному масиві partition-підхід часто простіший і дешевший: in-place, без зайвих структур, із середнім O(n). Саме тому ця ідея досі живе в алгоритмах на кшталт nth_element в C++.

Ще важливіше для мене - CSP, Communicating Sequential Processes. У своїй роботі Хоар запропонував дивитися на concurrent system як на композицію незалежних sequential processes, які взаємодіють через явну комунікацію. Ключовий момент тут у тому, що send/receive - це не просто передача даних, а синхронізація: подія відбувається лише коли обидві сторони ready. Це rendezvous-модель. Плюс guarded choice: процес може чекати на кілька можливих communication events і продовжити виконання по тому, який став доступним. Дуже багато того, що сьогодні здається “природним” у Go - channels, select, і сама ідея share memory by communicating - росте саме звідси, офіційні матеріали Go і Rob Pike прямо відсилають до CSP. Хоча Go, звісно, не є буквальним CSP.

І окремо - Hoare logic. Трійки {P} C {Q} дали просту, але дуже сильну рамку: код треба не лише тестувати, а й уміти пояснити, за яких передумов він коректний і що гарантує після виконання.

Майже точно я згадав не все. Але, мабуть, це і є найкращий показник масштабу людини: коли навіть короткий список її ідей уже змінив цілу індустрію. Дякую вам, сер Ентоні 🫡

Хотів поділитися корисною штукою - почав користуватися додатком Opal.

Він блокує сповіщення та доступ до вибраних апок у ті години, коли хочеться нормально попрацювати без постійних відволікань. І це блокування складно обійти (навіть не знаю як). Як результат, це поступово відбило звичку зранку одразу хапатися за телефон і читати новини. Через це ранок став значно спокійнішим. Загалом, дуже рекомендую тим, хто хоче трохи краще контролювати свою увагу.

Ну і приємний бонус: для України річна підписка на PRO у мене показує $0.49.

А які у вас є свої маленькі хаки чи біохаки, які реально покращили фокус, ранок або загальний стан? Буде цікаво зібрати мікропоради в коментарях.

Останнім часом часто бачу дві крайності.

З одного боку - розмови в стилі "ринок помер", "джуніори більше не потрібні", "AI скоро всіх замінить". З іншого - реальність, у якій великі компанії продовжують наймати інженерів сотнями й тисячами. У нас, наприклад, зараз активний найм.

Тому вирішив подивитися на цифри:

у Citadel Securities вийшов репорт із графіком, де видно, що загальна кількість вакансій на Indeed падає ще з січня 2024 року. Але вакансії саме для software engineers, навпаки, ростуть з червня 2025. Схожу картину показує і Pragmatic Engineer на основі даних TrueUp: з 2023 року кількість інженерних вакансій у tech-компаніях теж йде вгору.

І тут цікаво не лише саме зростання, а й контраст. Паралельно ми постійно читаємо, що "код скоро писатиме AI", "вхід у професію закривається". Але якщо подивитися на дії, а не на заголовки, то AI-компанії, big tech і сильні продуктові гравці чомусь не припиняють найм. Навпаки.

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

Так, просто “знати синтаксис” уже недостатньо. Так, конкуренція вища, і планка теж вища. Але потреба в людях, які вміють думати, будувати системи, розбиратися у нюансах/компромісах, читати чужий код, дебажити прод, працювати з невизначеністю й доводити рішення до результату - нікуди не зникла.

Мені навіть здається, що зараз цінність хорошого інженера стала більш видимою. Бо коли рутинні шматки роботи спрощуються, ще краще видно, хто просто щось кодив, а хто реально вміє вирішувати задачі.

Тому я б точно не вівся на наратив "все, розробка закінчилась". Скоріше навпаки: професія змінюється, інструменти змінюються, але сильні інженери все ще дуже потрібні.

🐍 Колись у нас в команді виникла дискусія в одному з піарів — як правильно перевіряти список на порожність: if not mylist чи len(mylist) == 0. Частина наполягала, що len() — читабельніше. Інша казала, що перший варіант більш пітонячий. Кожен при своїй думці. Я вирішив розібратися до кінця, бо ця перевірка виконувалася в гарячому циклі.

Спойлер: пітон-лайк варіант швидший майже вдвічі. І причини цього глибоко всередині CPython VM. Дивимося на заміри:

timeit.timeit(
  "not mylist",
  number=100_000_000,
  globals={"mylist": list()}
)
# 0.869 сек

timeit.timeit(
  "len(mylist) == 0",
  number=100_000_000,
  globals={"mylist": list()}
)
# 1.939 сек

Майже 2x різниця для операції. Чому так?

У CPython всі об'єкти мають спільну ієрархію. PyObject — базовий хедер для кожного типу:

struct _object {
    Py_ssize_t ob_refcnt;  // reference count
    PyTypeObject *ob_type; // тип + function pointers
};

PyVarObject — розширює PyObject для sequence-типів:

typedef struct {
    PyObject ob_base;
    Py_ssize_t ob_size; // кількість елементів
} PyVarObject;

PyListObject — власне list, наслідує PyVarObject:

typedef struct {
    PyObject_VAR_HEAD
    PyObject **ob_item;   // масив елементів
    Py_ssize_t allocated; // скільки пам'яті виділено
} PyListObject;

PyObject → PyVarObject → PyListObject

Поле ob_size завжди лежить прямо в хедері. Але щоб дістатись до нього через ob_type, потрібно пройти ланцюжок: ob_type → tp_as_sequence → sq_length → list_length → ob_size. 5 рівнів pointer indirection — і кожен з них потенційний cache miss.

⚡️ if not mylist — що відбувається під капотом

Компілятор генерує лише 2 VM-інструкції: LOAD_FAST + TO_BOOL. TO_BOOL — інструкція, яка не знає тип об'єкта наперед. При першому виконанні йде через ті самі 5 рівнів indirection.

Але починаючи з CPython 3.12, після першого виклику спрацьовує instruction specialization — VM замінює TO_BOOL на TO_BOOL_LIST. Ця спеціалізована інструкція читає ob_size напряму, одним memory access, без зайвих dereference'ів. Фактично — inline-функція без overhead'у виклику. Результат: в hot loop-і перевірка зводиться до одного читання з пам'яті.

🐢 len(mylist) == 0 — де губиться час

VM генерує 5 інструкцій: LOAD_GLOBAL, LOAD_FAST, CALL, LOAD_CONST, COMPARE_OP.

1. Function call overhead — CALL це не безкоштовно. Stack frame setup, register spills, jump до C-коду. В tight loop'і накопичується.

2. len() теж не знає тип наперед — всередині йде через ob_type → tp_as_sequence → sq_length, ті самі 5 рівнів indirection. І на відміну від TO_BOOL_LIST — не отримує спеціалізації.

3. Порівняння з нулем — після повернення з len() VM ще виконує LOAD_CONST 0 і COMPARE_OP. Дві зайві операції на кожну ітерацію.

🔬 Чому переходи за вказівниками — це погано?

L1 cache access — ~4 такти
Cache miss → main memory — 100–200 тактів. Чим глибший ланцюжок dereference'ів, тим вища ймовірність вийти за межі кешу. 5 рівнів замість одного — це потенційно на порядок дорожче при cold cache. Особливо помітно в будь-якому performance-critical коді, де перевірка на порожність стоїть у циклі.

Як ми пришвидшили запит до БД в 100 разів 🐘

Писали Python-сервіс, який за набором device ID-шників витягував дані з таблиці на кілька мільйонів рядків. Логіка проста — є список девайсів, які нас цікавлять, йдемо в базу:

device_ids = [123, ...]  # ~15к девайсів
cursor.execute("""
    SELECT d.id, d.meta, r.region_name
    FROM devices d
    JOIN regions r ON d.region_id = r.id
    WHERE d.id = ANY (ARRAY[%s])
    AND d.region_id = 1
""", (device_ids,))

Виглядає невинно. І працювало нормально — поки кількість девайсів була маленькою.

Але коли девайсів стало ~15к, запит почав виконуватися 20+ секунд. Полізли в EXPLAIN ANALYZE і побачили Bitmap Heap Scan з ручним перебором рядків.

Проблема в тому, що Postgres бачить ARRAY[...] як один суцільний параметр і не розкладає його на окремі значення на етапі планування. Тому він не може сказати “ось 15к конкретних ключів, піду за кожним в індекс”. Натомість робить навпаки: спочатку сканує таблицю за умовою region_id, збирає всі кандидати — а потім фільтрує кожен рядок вручну, перевіряючи, чи є його id в масиві.

Із 15к девайсів це десятки тисяч зайвих перевірок. І це при тому, що таблиця частково була закешована в RAM — тобто Postgres навіть не йшов на диск. Просто сам факт ручної перевірки кожного рядка вже коштував 20+ секунд. Замість “знайди мені ось ці конкретні рядки” виходить “знайди багато рядків, а потім я сам розберуся, які потрібні”.

Фікс виявився абсурдно простим — замінити ARRAY на VALUES:

values = ",".join(f"({id})" for id in device_ids)

cursor.execute(f"""
    SELECT d.id, d.meta, r.region_name
    FROM devices d
    JOIN regions r ON d.region_id = r.id
    WHERE d.id = ANY (VALUES {values})
    AND d.region_id = 1
""")

VALUES (...) — це підзапит із тимчасовою таблицею. Optimizer бачить конкретні рядки, хешує їх і робить точковий Index Scan по кожному device ID. Тобто саме те, що й очікувалося від початку.

20 000 мс → 200 мс. В 100 разів швидше.

Ця історія про те, що проблеми з продуктивністю живуть на різних рівнях. Минулого разу ми говорили про Python. Тут — один рядок SQL, який ламав весь запит. Щоб бачити такі речі одразу, треба розуміти, що відбувається під капотом — і в Python, і в базах даних. Саме для цього ми запустили два курси:

🐍 Python Advanced — модель пам'яті CPython, GIL, multiprocessing, async, zero-copy підходи. Читає Senior Python Engineer з N-iX, яка проєктує high-load системи. Старт сьогодні.

🗄️ Database Internals — як написати свою БД і по ходу розібратися, як насправді працюють індекси, join, order by, як дані зберігаються на диску, query optimizer, транзакції та MVCC. Читає інженер Embucket, ex-SingleStore, ex-Microsoft. Старт 31 березня.

Як би я хотів аби такі курси були в моєму універі :)

Parameter Golf від OpenAI

OpenAI нещодавно запустила цікавий контест — потрібно натренувати максимально якісну модель фіксованого розміру (до 16 MB) на заданому датасеті.

Лідерборд і код сабмітів відкриті, тому вже зараз можна подивитися, які оптимізації реально працюють.

Що особливо круто: розміри задачі невеликі, тобто не потрібна велика інфраструктура, але при цьому це все ще реальна ML-інженерія, а не іграшка. Так, GPU потрібні, але OpenAI дає кредити для експериментів, якщо хочете взяти участь.

💡 І цікавий момент. Потрапити на співбесіду в OpenAI - складно, навіть якщо ти сильний інженер. І цей контест - це один зі способів знайти крутих людей серед великої кількості резюме.

Якщо вам здається, що більше потоків = швидше — дуже раджу подивитися це відео від відомої HFT компанії: про реальну вартість concurrency на рівні CPU cache lines, синхронізації і того, чому іноді багатопоточність робить систему повільнішою. Якщо вам зайде лектор Jon Gjengset - він також викладає курс MIT https://missing.csail.mit.edu/ Курс про речі, які майже не вчать в університеті: shell, git, debugging, profiling, tooling і вчать інтернів на стажуванні.

https://bytebytego.com/
Дає безкоштовний доступ до матеріалів на місяць

Зміна місця, роботи чи друзів може допомогти покращити твоє життя, але ніщо не зрівняється зі зміною твого мислення. Стан твого розуму впливає на все, що ти сприймаєш.

CS 153: Frontier Systems | Stanford University
https://cs153.stanford.edu/

Прикольний тим, що це спроба пояснити, як виглядає вся АІ система загалом. Бо зазвичай ми бачимо тільки верхівку — ChatGPT, Copilot, Midjourney. А під цим — величезний стек: датацентри, GPU, distributed systems, тренування моделей, і тільки потім вже продукт.

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

Типу:
Jensen Huang розповідає про залізо,
Andrej Karpathy — про моделі,
Sam Altman — про продукт і майбутнє,
Satya Nadella — як це все впливає на великі компанії.

По суті це такий system design для AI епохи. І головна думка AI — це вже давно не “модель”, це інфраструктура. Якщо ти бачиш тільки модель — ти бачиш десь 10% картини.

Перша лекція

Зранку трохи пустив сльозу.

Почав викладати в ліцеї інформатику, перша пара і раптом о 9:00 всі ліцеїсти просто встали, щоб вшанувати память загиблих. Причому, що жодного сигналу не було — оповіщувач зламався, то я спочатку навіть трохи розгубився і не одразу зрозумів, що відбувається.

А потім в ліцеї лунає гімн, а вони стоять, приклавши руку до серця.

У такі секунди просто відчуваєш, які хороші діти у нас ростуть.

4 роки тому одне інтерв’ю змінило моє життя.

Березень 2022-го. Війну я зустрів за кордоном. Постійно "на трубі" з друзями. Наш чат на трьох, де раніше були лише меми, перетворився на нескінченне "як ви?".

Одного вечора, коли «Азов» уже був у повному оточенні, у чат прилетіло посилання. Інтерв’ю з Денисом Прокопенком. Відкрив автоматично, щоб відволіктися. І залип. Він говорив чітко, виважено, предметно. Про цивільних, про ситуацію в місті, про полк, що стримує навалу ворога. Сказати, що я був вражений, — це нічого не сказати.

Я така людина, що завжди шукає коріння. Мені цікаво, як людина зростала, що на неї впливало. Тоді я ще не знав, хто такий Редіс. Тому почав вивчати. Ось просто сухі факти з мережі: ультрас «Динамо» та викладач англійської й німецької за освітою. 2014-й — доброволець, солдат. У 26 років — командир «Азову». Герой України. Сьогодні — бригадний генерал.

Але якщо подивитися інтерв'ю про нього від людей, що з ним перетиналися, то всі як один пишуть про фанатичну працездатність. Він — приклад того, як гострий розум множиться на трудоголізм. Один епізод, який пояснює все: Неділя. 04:00 ранку. Єдиний вихідний за тиждень. Дзвінок: «Вибач, що розбудив. Є термінова задача». Це і є Редіс. "Моє серце, моя душа, моє тіло належать Азову". Це і є Редіс.

До чого я це пишу? Після того інтерв’ю я невдовзі повернувся до Києва. Пройшло 4 роки. Сьогодні мені не соромно повідомити, що наша школа csosvita.com перетнула рубіж у 3 000 000 гривень допомоги Силам оборони. Безкоштовне навчання для військових. Понад 1 000 000 гривень ми спрямували саме на «Азов». І від сьогодні ми — їхні офіційні партнери.

Так, я не військовий. Але це мій спосіб бути корисним у цій війні, поки без зброї в руках. Просто робити максимум там, де я є. Просто робити якісну Computer Science освіту.

Дякую за приклад, командире.
"Без бою немає слави" (с) Редіс.