👋 Привіт! Мене звати Дмитро, я Tech Lead з ~15 роками комерційного досвіду. Встиг попрацювати в аутсорсі, аутстафі, фрілансі, продуктових компаніях і навіть запускати власні продукти. Завжди намагався уникати "15 разів по 1 року" – працював у різних доменах, з різними технологіями, командами та масштабами.

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

Останні 8 років я переважно працюю як Backend Tech Lead у маленьких командах. Маю кілька гіпотез про швидкість:
* маленька команда швидша за велику
* кілька маленьких – швидші за одну велику
* але одна маленька швидша за кілька маленьких

🛠 Мій типовий стек: TypeScript, NestJS, PostgreSQL, ArgoCD, GitHub Actions, сервіси AWS. Маю "пунктик" на Observability і вважаю, що хороший бекенд-розробник має вміти сам розгорнути свій код.

🧠 Моя суперсила – швидкий запуск перевірки продуктових гіпотез. Те, що часто називають MVP або MLP (про Minimum Lovable Product ще поговоримо). Або PoC (Proof of Concept) для нової технології. Інакше кажучи, я вмію перетворювати бізнес-вимоги у робочий бекенд.

Баланс швидкості й якості – окрема велика тема. Як би хто не хотів, майже завжди швидкість важливіша. Але важливо памʼятати: швидкість завжди існує в рамках вимог. Ви ж не деплоїте в прод непрацюючий код просто заради швидкості? (сподіваюся 😉)

Цей канал – моя спроба відрефлексувати власний досвід, поділитися ним з комʼюніті і розповісти про те, що мені здається вартим уваги. У мене, ймовірно, є чимало контроверсійних думок і підходів — але це лише мій погляд, ви не зобов’язані з ним погоджуватися.

📌 Про що планую писати:
- мої гіпотези про команди, стек і людей
- ефективна і швидка розробка
* що насправді означає "роби нормально — буде нормально"
* як зрозуміти, коли "нормально" вже досить, а коли треба "добре"
* вплив складності технічних рішень на долю продукту
* найм класних людей
* рецензії на матеріали, які я вважаю вартими уваги
* варіанти вирішення конкретних технічних проблем

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

💛 Донатьте на Сили оборони України, покривайте код тестами, будьте котиками.
Побачимось✌️

📘 "Хто. Як наймати найкращих"
За порадою прочитав "Who: The A Method for Hiring" від Geoff Smart і Randy Street. Це книжка про те, як наймати не просто «норм», а гравців-А – людей, які з великою імовірністю покажуть топ-результат.

Найважливіші рішення, які ухвалюють бізнесмени, це не рішення що, а рішення хто

– Джим Коллінз, автор *Good to Great*

Ця книжка – основа hiring-культури Genesis. І не просто так.

💡 Суть книги в одному реченні:
Збираєш команду з гравців-А → будуєш сильну компанію.
🔹 Гравець-А – це кандидат, який з 90% імовірністю покаже результат, якого досягає лише 10% ринку.

📈 Замість "вуду-найму" – А-метод:
1 Картка найму – місія, досягнення, результати, компетенції
2 Пошук – мережа, рекомендації, прямий підхід
3 Вибір – структуровані інтерв’ю
4 Залучення – переконати приєднатися і втримати
⠀
📌 З чим погоджуюсь:
– Картка найму – must. Без неї ви не знаєте, кого шукаєте
– Найкращі – з рекомендацій співробітників. Побудуйте свій пул талантів
– Інтервʼю закінчується, коли зрозуміло «не той»
– Кандидат, який не знає свої досягнення = червоний прапор
– Ніякої токсичності, мудаків не наймати та звільняти одразу
– Наймайте командних гравців, не «суперзірок». Хімія вирішує
– cultural mismatch + ego = біда
– Гравець-А відповідає картці найму і хоче цю роль
– Офер – не кінець, переконання триває до першого робочого дня і далі
– Перші 3 місяці – найкритичніші
– Не «все вмію», а «в одному – топ». І команда під це

📎 З чим не згоден / де контекст інший:
– Реферальне інтерв’ю (дзвінки до 7+ знайомих кандидата) – в IT це виглядає дивно. Зробити 1–2 перевірки – ок, але масштабувати складно

📷 Концепція Ягня vs Гепард – топ.
Ягня – милий і зручний, але не тягне.
Гепард – різкий, результативний. Вибір очевидний.
Вживу бачив коли компанія ставила на Ягня і не досягала жодних успіхів.

📚 Рекомендую всім, хто має стосунок до найму.
Навіть якщо думаєш, що знаєш усе – перечитай.
Бо помилки в наймі, зазвичай, найдорожчі у бізнесі.

На протязі всієї книги автори наводять приклади найму гендиректорів або керівників напрямків. Дуже відчувається дух «Атлант розправив плечі», де правильні керманичі витягують усіх з економічної катастрофи й приводять компанію до надзвичайного успіху.
Я читав цю книгу з позиції хайрінг-менеджера або баррейзера, який займається наймом рівнів Junior–Middle–Senior. І, як на мене, багато ідей у книзі натягнуті саме на найм C-level-кандидатів. Взяти хоча б приклад із залученням через подарунок Porsche кандидату і шуби його дружині (sic!). Та й за 17 років з моменту виходу книги світ трохи змінився.
Але все це можна масштабувати на нижчі рівні. І я загалом погоджуюсь з ефективністю описаного методу найму.

Мої думки, що резонують із книгою:
Я бачив чимало невдалих наймів, коли хайрінг-менеджер не розумів, кого саме шукає, що кандидат має вміти, як це оцінити і як обрати серед кількох.
Завжди проблема була в тому, що або картки найму не було взагалі, або вона була зроблена «аби було». Це фундаментальна помилка.
Щоби скласти картку найму, просто подумайте: що таке успіх на цій посаді? Як його можна виміряти? Якими показниками? Якою поведінкою?
Правильно складена картка допоможе вам не лише під час вибору кандидата, а й згодом – щоб оцінити, наскільки людина справді успішна у ролі. Бо критерії успіху – формалізовані, прозорі. І кандидат знає, як його будуть оцінювати.

Вам потрібні найкращі кандидати – ті, до кого ви реально можете дістатися. Вони мають талант, підходять до культури компанії, і вміють те, що вам справді потрібно.
Не можна найняти суперзірку й намагатися перевиховати її «під себе» – отримаєте не результат, а конфлікти.
Негативна, токсична людина просочує колектив своєю отрутою – падає моральний стан, втрачається ефективність, люди йдуть. Наймайте командних гравців, з якими в команди буде «хімія».
Чим більше А-гравців – тим вища ефективність і амбіції всієї команди. Бо всі тягнуться до середнього рівня організації. І саме ви визначаєте, яким він буде.

Якщо ви використовуєте WebStorm у роботі — не пропустіть свіже оновлення.

🔹 З цікавого: додали підтримку TypeScript-Go language server, який дає змогу використовувати збірку @typescript/native-preview, що написана на Go.

(Поки Prisma мігрує з Rust на TypeScript, сам TypeScript тим часом мігрує на Go.)

🔹 Також зʼявилася підтримка MCP для Junie,
🔹 І можливість додавати атачменти в чат з AI.

Повний список змін

🛠️ Використовуєте Sentry лише для помилок, а Observability — окремо?

Є сенс звернути увагу на новий пакет @sentry/node-core.

Він не тягне за собою свої версії OpenTelemetry залежностей, не патчить пакети та не налаштовує експортери за замовчуванням.
Тобто працює лише у вашому кастомному стеку — без магії.

Я використовую Sentry в NestJS-додатках для відстеження помилок та моніторингу cron'ів. А traces з OpenTelemetry надсилаю деінде.
Із попереднім SDK це було незручно — доводилося лізти в сорси Sentry й OpenTelemetry, щоб зрозуміти, як уникнути конфліктів.

Було так:

import * as Sentry from '@sentry/nestjs';
import { SentryPropagator } from '@sentry/opentelemetry';
import { CustomSampler } from './sampler';

const sdk = new NodeSDK({
  traceExporter,
  sampler: new CustomSampler(),
  spanProcessors: [new BatchSpanProcessor(traceExporter)],
  contextManager: new Sentry.SentryContextManager(),
  textMapPropagator: new SentryPropagator(),
  instrumentations: [...],
});
sdk.start();

Стало так:

const sdk = new NodeSDK({
  traceExporter,
  spanProcessors: [new BatchSpanProcessor(traceExporter)],
  instrumentations: [...],
});
sdk.start();

У попередній версії ще бажано було додавати:

Sentry.init({
  skipOpenTelemetrySetup: true,
  registerEsmLoaderHooks: false,
});

У @sentry/node-core цього не потрібно — він не втручається в OTel доки ви самі не захочете.

🎯 Висновок:

Якщо вам потрібен Sentry тільки для помилок — @sentry/node-core ідеально підходить:
- менше сторонньої магії
- більше контролю
- менше шансів на поламану інтеграцію з OTel
- швидше старт додатку через меншу кількість патчів пакетів

Рекомендую спробувати замість @sentry/nestjs 👌

Також варто спочатку прочитати Migration guide.

🛠 X-Entity-Ref-ID

Коли ви надсилаєте email із коду, Gmail за замовчуванням групує всі листи з однаковими темами в один тред. Якщо хочете, щоб кожен лист відображався окремо — додавайте до кожного листа хедер X-Entity-Ref-ID з випадковим значенням. Наприклад:

headers: {
  'X-Entity-Ref-ID': randomUUID(),
}

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

P.S. Зверніть увагу на метод спаму через хедер Return-Path.
Будьте пильні, зловмисники використовують нові способи обходу фільтрів.

📢 Нагадую: пройдіть опитування State of JavaScript 2025.

Навіщо?
Результати опитування бачать інші розробники, автори бібліотек/фреймворків і компанії.
Це можливість показати, що «болить» і що хотілося б змінити, вплинути на напрямок розвитку екосистеми.
Розробники пакетів отримують реальний зворотний зв’язок.

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

Fix real problems first. Technical problems are a luxury you can afford later.

Рекомендую прочитати https://www.ivan.codes/thoughts/technical-experts-have-zero-customers

Fix real problems first. Technical problems are a luxury you can afford later.

Абсолютно згоден.

Хороший код кращий за поганий. Підходяща архітектура – краще, ніж її відсутність.
Але технічно досконалий продукт, який не вирішує бізнес-проблему, – нікому не потрібен.
Спочатку зробіть, потім зробіть добре.

Єдині винятки – коли ви з самого початку зобов'язані гарантувати прописані нефункціональні вимоги (типу надійності чи пікового навантаження).
Але здебільшого ми тут про воронки і крудіки, а не SLA для банку.

Та шо ж таке(
https://www.cloudflarestatus.com/incidents/8gmgl950y3h7

📘 Книга "Code Complete" ("Досконалий код")

У мене є guilty pleasure – читати старі книжки про розробку ПЗ.
Чому guilty? Бо часто інформація в них уже неактуальна.
Чому pleasure? Бо цікаво бачити, який шлях пройшла індустрія: як еволюціонували підходи, як спростилася реалізація, і як фокус змістився з залізних обмежень на покращення Developer Experience, а не на оптимізацію ресурсів.

TL;DR:
Особисто я не отримав багато користі з цієї книги у 2025 році.
Але якщо ви – джун або мідл, і вам цікаво подивитись, як мислили розробники у 90-х–2000-х, – з хорошим ментором поруч ця книга може дати корисну рамку мислення.
Але не варто сприймати все буквально – багато речей застаріли або стали де-факто стандартом, про який навіть не переймаєшся.

Мені знадобилось 10 років, щоб виділити час, сісти й прочитати її від початку до кінця. До цього були кілька спроб, але завжди щось зʼявлялося пріоритетніше.
Ця книга була в моєму "must read" списку професійної літератури.

Каюсь: колись для мене був ред флег на співбесіді, якщо кандидат не читав жодної книги з цього списку. Зараз – байдуже. Не важливо, звідки ви черпаєте ідеї, хоч з TikTok.

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

Пишіть код у першу чергу для людей
Це, як на мене, – головний принцип розробки якісного ПЗ.
Ваша ціль – не просто "вирішити бізнес-проблему",
а зробити так, щоб це рішення можна було підтримувати.

- Хитрий код = поганий код
- Пишіть так, щоб зрозумів програміст рівнем нижче
- Коментуйте мету коду, а не що він робить
- Пояснюйте все, що стосується помилок, edge cases, хаків, порушень стилю
- Написання читабельного коду не займає більше часу, ніж заплутаного

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

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

Ретроспектива еволюції розробки ПЗ
Основна проблема залишилась незмінною: боротьба зі складністю.

"Complexity is the primary killer of productivity and quality."

Але стало набагато простіше й комфортніше писати якісний код: лінтери, автоформатування, watch-режим для тестів, AI-асистенти, набагато потужніші компуктери як інструменти.

Ми пройшли шлях від "мистецтва програмування" до "мистецтва перетворення бізнес-вимог у готове рішення".
Швидкість доставки зросла в рази, а якість – не впала.
Хоча… може й впала, якщо глянути, наскільки легше стало щось реалізовувати, і водночас наскільки поганими стали продукти в нормі індустрії.

Не довіряйте сліпо "оракулам програмування"
(і тим більше – моїм записочкам)
Жодна методика не вирішує всі проблеми.
Не вірте в обіцянки типу "наша система універсальна".
Тестуйте на практиці. Порівнюйте. Ітеруйте. Беріть ідеї з різних предметних областей, мов, технологій. Експериментуйте.

Я не знав, що мій підхід має назву
Виявилось, те як я зазвичай пишу код називається Pseudocode Programming Process.
Спочатку я описую проблему на високому рівні, накидаю алгоритм словами, а потім іду по ньому і реалізую вже кодом.

Це дозволяє не губити думку, швидше ітерувати і не фокусуватись одразу на синтаксисі.

Code Complete – книга свого часу. Вона допомагає побачити, з яких ідей виростала сучасна культура програмування, і чому багато речей, які ми сьогодні сприймаємо як очевидні, колись були проривом.

У 2025 вона навряд чи відкриє вам нові інструменти, патерни чи практики. Але може дати історичну глибину, рефлексію, і допомогти сформулювати для себе відповідь на питання: що саме ми вважаємо "хорошим кодом" і чому.

Про метрики, продуктивність і інженерну культуру

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

Я не вважаю, що метрики дають обʼєктивну відповідь на питання продуктивності людей і команд, принаймні у вигляді набору чисел на дешборді.
Водночас я думаю, що метрика потрібна. Просто інша.
Для мене головна метрика роботи інженерної команди – це задоволеність стейкхолдерів. Не як емоція чи "всім все подобається", а як сигнал довіри: команда передбачувана, відповідальна, надійна. Їй делегують рішення, їй вірять, її рекомендації приймають навіть тоді, коли вони складні або непопулярні.

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

Метрики можуть бути корисними. Але вони є інструментом, щоб задати правильні питання, а не відповіддю. Вони добре показують що змінилося, але майже ніколи не пояснюють чому.
Як тільки ми намагаємось замінити метриками розмову з командою – починаємо робити хибні висновки.

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

Але це не означає толерувати халтуру або "просиджування штанів".
Відповідальність ніхто не скасовував: інженера наймають, щоб він працював, брав ownership, докладав зусиль і діяв добросовісно та передбачувано в межах своєї ролі.
Просто ці речі погано вимірюються цифрами – вони краще проявляються через взаємодію, якість рішень, участь у командній роботі та готовність відповідати за наслідки своїх дій.

Там, де метрика стає ціллю, починає працювати Goodhart's Law: люди оптимізують число, а не результат. Зʼявляються косметичні покращення, уникання складних задач і ситуації, коли дешборд "зелений", а працювати стає важче. Доволі часта омана: обмазатися метриками, які на дешборді ростуть, а насправді все навколо палає. This Is Fine момент.

Для мене здоровий підхід виглядає так:
- метрики – дзеркало та сигнали про систему, не про людей
- тренди важливіші за абсолютні значення
- порівнювати варто команду з нею ж у минулому, а не з іншими
- "погані" числа – привід для розмови, а не для тиску і пошуку винних
- культура довіри й психологічної безпеки – must have та умова, без якої жодні метрики не мають сенсу.

У маленьких командах розмова майже завжди ефективніша за дешборд. У великих – метрики потрібні як спільна мова, а не як рейтинг.

Тому я не проти метрик. Я проти ситуації, коли числа підміняють мислення, а контроль – розвиток.

Метрики мають допомагати думати.
А рішення все одно мають приймати люди.

Продуктивність – не те, що добре виглядає на дешборді, а те, чому довіряють поза ним.
mic drop