👋 Привіт! Мене звати Дмитро, я 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 для банку.