Якщо ви використовуєте 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

📘Книга "Soft skills: Бути собою"

Це перша книга видана оригінально українською мовою, яку я щиро раджу.
Написана викладачкою і бізнес-консультанткою Оленою Жильцовою та психологом-психотерапевтом Володимиром Станчишином. Саме таке поєднання ідеально розкриває тему мʼяких навичок у професійному контексті.
Текст читається легко, і під час читання постійно спливають знайомі робочі ситуації, що відгукуються в пам’яті.

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

Я навіть не буду витягувати з книги якісь цитати/думки, бо вона досить компактно передає суть. Зупинюсь лише на її змісті:

1. Креативність. Інноваційність
2. Допитливість, відкритість до навчання
3. Критичне мислення
4. Емпатія
5. Резильєнтність
6. Комунікаційна майстерність
7. Взаємодія
8. Стратегічне мислення
9. Відповідальність
10. Самообізнаність

Ці навички відповідають сучасним підходам до soft skills і є загальновизнаними компонентами професійної поведінки в команді та кар’єрі загалом.

Вважаю, що цю книгу має прочитати кожен, хто стикається в роботі з людьми, тобто практично всі. Особливо лідери/керівники команд.
Особливо корисно тим, хто:
- скептично ставиться до терміну та важливості "софт скілів"
- думає, що хардові навички важливіші
- не розуміє поведінку команди
- вважає себе розумнішим за колег

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

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

P.S. Почув про цю книгу завдяки докладу пана Артема Биковця.
Доклад теж раджу подивитися.

Не всі цінують простоту

Прочитав статтю Nobody Gets Promoted for Simplicity і загалом погоджуюся з її тезами.

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

Ось думки, на яких я б хотів закцентувати увагу.

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

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

Розрізняйте види complexity: складна задача це не теж саме, що складне рішення.

Ведіть brag document, документуйте свою роботу, прийняті рішення, та, по можливості, як це було обумовлено. Це стане в пригоді, коли ви втратите частину доменних знань або під час performance review.

Останні дві теми я розкрию окремими дописами.

Complicated vs. Complex

Найбільша проблема, яка, з мого досвіду, вбиває системи – це нерозуміння/ігнорування різниці між complex і complicated.

Обидва терміни зазвичай перекладаються як "складний", але це зовсім різні речі.

Complex система – коли складною є сама предметна область: білінг, банкінг, платіжні системи, логістика, медицина. У таких системах багато сутностей, залежностей, винятків, взаємодій та сертифікацій. Складність є невід'ємною частиною проблеми, її не можна просто прибрати. Спробуй зробити власний query planner для PostgreSQL або реалізувати спеку ZooKeeper, щоб зрозуміти про що я)

Complicated рішення – коли ми самі створюємо складність, часто на рівному місці.
Наприклад:
- надлишкові абстракції
- 10 шарів зайвої "архітектури"
- купа мікросервісів, щоб відправляти 100 email на день
- усі патерни, що запамʼятали з книги
- кілограм коду, просто заради DI (привіт, NestJS)
- "архітектура", яку вже ніхто не розуміє, а кожна зміна викликає непевність і страх

Таку складніть можна і треба прибирати.

Будь-яка система з часом деградує, і ви з цим нічого не зробите. Команда людей вирівнюється до середнього рівня. Система стає складнішою навіть попри ваші спроби цьому запобігти.
Складність накопичується природно:
- нові вимоги
- нові edge кейси
- костилі
- тимчасові рішення на час міграції
- компроміси

Хороше інженерне рішення – це не боротьба зі складністю домену, це боротьба з надмірною складністю, яку ми самі й створюємо.

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

Cognitive load is how much a developer needs to think in order to complete a task.

Головне питання до будь-якого рішення: чи зменшує воно когнітивне навантаження?
Не наскільки воно "красиве", елегантне або абстрактне. А наскільки швидко нова людинаагент зрозуміє:
- що тут відбувається
- де шукати проблему
- як безпечно внести зміну

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

Хороший інженер не придумує складне рішення. Він бере складну проблему і може зробити її настільки простою, наскільки це можливо (але не простіше за це).

Простота – це не відсутність складності.
Простота – це коли складність знаходиться тільки там, де вона справді необхідна.
Робіть просто.

Почитати:
• https://www.infoq.com/presentations/Simple-Made-Easy/
• https://github.com/zakirullin/cognitive-load