Всим доброго недільного ранку.

Там мій друг, Віктор Турський (той що веде канал Жабаскрипт), почав стрім де показує як вайбкодить проект з Claude Code:
https://www.youtube.com/watch?v=BtHQyH6mniQ

Якщо ви ще не спите, то скоро у вас буде можливість прочитати нову статтю )

Лайк, якщо вереом в пʼятницю ви вже НЕ працюєте )

-= Коли твій мозок вже здався, а ти ще ні =-

Сидиш над задачею о 23:00. Думаєш: "Ще трохи — і закінчу". О 00:30 все ще сидиш. Вранці прокидаєшся як після похмілля, але переконуєш себе: "Зате вчора багато зробив".
Знайомо, так?

Так от. Швидше за все, ти зробив менше, ніж міг би за нормальний робочий день. І завтра зробиш ще менше.

Це не мотиваційна порожнеча. Це банальна нейробіологія.

—

Що кажуть дослідження
Fucci з колегами (2018) взяли 45 програмістів. Половина не спала ніч, інша — спала нормально.

І що?

Якість коду впала на 50%
Синтаксичних помилок — на 35% більше
Залученість — на 30% менше
Одна ніч без сну. І ти видаєш вдвічі гірший код. Не "трохи гірший". Вдвічі.

Van Dongen (Sleep Medicine) виявив ефект накопичення:

14 днів із 6 годинами сну = мозок як після 2 ночей без сну
14 днів із 4 годинами = як після 3 ночей
І от що цікаво: люди не розуміли, наскільки погано вони працюють. Їм здавалося, що "адаптувались". А тести показували катастрофу.

FeedBaG++ (MSR 2018) — реальні дані про програмістів:

2 години без перерви — невдач на 10% більше
Найкращі результати — при помірному навантаженні
Чим більше годин, тим гірше працюєш
От так. Більше годин ≠ більше результату.

—

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

Gloria Mark виявила: після переривання потрібно 23 хвилини, щоб повернутись до концентрації. А коли ти втомлений — навіть не помічаєш, що твоя "концентрація" давно імітація.

Ознаки, що ти вже перебрав (і їх легко проігнорувати):

• Перечитуєш той самий код 3-4 рази і все одно не розумієш
• Рішення, які раніше були легкими, тепер вимагають зусиль
• Лаєшся на "дурні" помилки компілятора
• Обираєш найпростіше рішення, бо на правильне немає сил
• Відкладаєш складні речі "на потім"

• Це не "трохи втомився". Це виснаження. І продовжувати = плодити технічний борг.


Математика перепрацювання
Business Roundtable дослідив, що відбувається при 60 годинах на тиждень:

Тиждень 1: о, є приріст!
Тиждень 4: приріст майже зник
Тиждень 8: загальний результат = як би працював 40 годин
Ти витратив на 50% більше часу. Заплатив здоров'ям. І отримав... нуль.

А от що отримав реально:

Більше багів
Технічний борг
Вигорання
Гірші рішення
Вітаю з перемогою.

—

Скільки реально можна кодити?
Anders Ericsson (той, що популяризував "10 000 годин") виявив: експерти — від музикантів до шахістів — можуть тримати глибоку концентрацію максимум 3-4 години на день. Не 8. Не 12. Три-чотири.

А програмісти?

Активний кодинг: 52 хвилини на день (медіана!)
Читання коду та документації: ще 41 хвилина
Решта — мітинги, слак, переключення контексту
Ось тобі й "8-годинний робочий день".

4 години глибокої роботи > 10 годин імітації

"Відіспатись на вихідних" — міф
Sleep Journal (2021) перевірили: якщо ти спав 5-6 годин у будні, вихідні не рятують.

Після 1 ночі нормального сну тобі здається, що відпочив
Реальна продуктивність відновлюється лише на 40%
Щоб повністю прийти до тями — 2-3 ночі нормального сну
Тобто твій понеділок — це все ще робота на батарейці 60%.

—

Що з цим робити
1. Правило 90 хвилин

Мозок працює циклами — 90-120 хвилин, потім йому треба відпочити. Не "перевірити телефон" — а реально встати, пройтись, подивитись у вікно. 15-20 хвилин.

2. Максимум 2-3 глибокі сесії

Плануй 2-3 блоки для складної роботи. Решту — на мітинги, рев'ю, рутину. Не навпаки.

3. Не після 22:00

Синє світло екранів пригнічує мелатонін. Кодинг перед сном = гірший сон = гірша продуктивність завтра. Замкнене коло.

4. 7-8 годин сну — не розкіш

Із 6 годинами через 2 тижні ти працюєш як після 2 безсонних ночей. Це не дискусійне. Це фізіологія.

5. Слухай себе

Ловиш себе на тому, що:

Перечитуєш код і не розумієш
Відкладаєш рішення
Робиш найпростіше, а не найкраще
Зупинись. Зараз. Не завтра. Зараз.

Головне
Свідоме програмування — це не тільки про те, як писати код. Це про те, коли закрити ноут.

Герої, які сидять до 3 ночі "заради проекту"? Не герої. Генератори багів, технічного боргу і власного вигорання.

Це просто БІМБА!

Нарешті, такі техно гіки як я можу отримати собі справжній PDA. І навіть повноцінний купуктер в кишені!
Так, сучасні сматрахвони це трошки не те...
Бо я застав ті славні часи, коли в мене був Nokia N800 зі справжнім Debian Linux.
Коли можна було зайти на свій побудований HA кластер і подивитись чого впав sendmail з любого місця. І не таскать ноут ))

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

Хтось ще памятає часи КПК на Symbian та WIndows CE?

Чи я один тут з ким не страшно ходити в ожеледицю ? ))

https://mecha.so/comet

Скоро буде дуже довгий пост.

Намагався тему розжувать якомога краще.
І дуже потрібен ващ фідбек.
Чи цікаво таке... чи не дуже...
І як взагалі тему роскрив.

Черканіть там щось в коментах, або лайк/дизлайк.

#не_проходьте_мимо

Баг, що зникає коли на нього дивишся (1/3)

Уяви: ловиш баг. Він є. Ставиш breakpoint — зник. Прибираєш — повернувся. Додаєш console.log — знову зник.

Ні, ти не збожеволів. Ти просто зустрів Heisenbug.

І це не просто курйоз. Це вікно у дивну правду: немає об'єктивного стану програми. Є тільки стан відносно того, як ти дивишся.
———
Як народився термін

UC Berkeley, 1960-ті. Bruce Lindsay і Jim Gray, два комп'ютерні вчені, б'ються з багом в операційці CAL-TSS (одна з перших time-sharing систем — коли багато користувачів працюють на одному комп'ютері одночасно). Баг є. Потім зникає. Потім повертається. Класика.

Lindsay колись вчив фізику. І в якийсь момент до нього дійшло: та це ж observer effect! Коли вимірюєш систему — ти її змінюєш.

Так народився "Heisenbug" — каламбур на імені фізика Гайзенберга.

(До речі, технічно це не принцип невизначеності Гайзенберга, а ефект спостерігача — різні речі. Але назва прилипла, і вже пізно щось міняти.)
———
А тепер цифри

1985 рік. Jim Gray аналізує логи помилок на кількох десятках систем.

Результат: 131 зі 132 багів — Heisenbugs.

Один. Один нормальний, передбачуваний баг на 132. Решта — примари.

Пізніше дослідники з Illinois вивчили 105 concurrency багів у MySQL, Apache, Mozilla та OpenOffice:

Що знайшли                          Скільки
Баги тільки між 2 потоками          96%    
Баги через ≤4 звернення до пам'яті  92%    
"Фікси", що все ще містили баги     60%    

96% проблем — між двома потоками. Навіть у системах, де їх сотні. Вікно помилки мікроскопічне. Але цього достатньо.
———
Чому debugger все ламає

Breakpoint — це не пауза. Це втручання.

Уяви: твоя програма виконує мільйони операцій на секунду. Ти ставиш breakpoint — і що відбувається?

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

Здається, ти просто "поставив на паузу". Але насправді ця "пауза" — сотні додаткових операцій процесора. Для багу, який живе в циклі що крутиться мільйони разів на секунду, ця затримка — як вставити годинну перерву між кожним кроком.

Баг залежав від точного timing'у? Ти його щойно вбив своїм breakpoint'ом.

Printf — це вічність

Що робиш           Скільки часу
`printf` в stdout  ~4000 нс    
`fprintf` в файл   ~250 нс     
Запис в буфер      ~10 нс      

4000 наносекунд. А race condition може мати вікно в 50 нс. Твій printf — як стіна між двома бігунами, що мали зіткнутися. Вони більше не зіткнуться.

Debug vs Release — різні програми

Серйозно. Різні:
• Debug: guard bytes навколо пам'яті, змінні в RAM
• Release: агресивні оптимізації, змінні в регістрах
• Floating-point: регістри = 80-bit, пам'ять = 64-bitТи буквально запускаєш іншу програму, коли перемикаєш режим. І дивуєшся, що баг зник.
———
Колекція абсурду

OpenOffice: не друкує щовівторка (2009)

Користувач пише: "OpenOffice не друкує щовівторка. В інші дні — нормально."

Усі думають — тролінг. Але ж ні.

Контекст: PostScript — це формат файлів для друку. Принтер отримує такий файл і знає, що саме малювати на папері. Більшість офісних програм генерують PostScript, коли ти натискаєш "Друк".

При генерації файлу OpenOffice додавав дату:

%%CreationDate: (Tue Mar 3 19:47:42 2009)

А тепер баг: Linux має утиліту file, яка визначає тип файлу. Вона дивиться на перші байти і вгадує: "це картинка", "це PDF", "це код".

Для файлів мови Erlang утиліта шукала текст "Tue" на позиції 4. Чому "Tue"? Бо Erlang-файли часто починались з такого патерну.

І от проблема: у вівторок PostScript-файл мав "Tue" рівно на позиції 4. Утиліта думала: "О, це Erlang!" Система друку отримувала "Erlang-файл" замість PostScript. І падала.

Понеділок — "Mon" — працює. Середа — "Wed" — працює. Вівторок — "Tue" — збіг з патерном Erlang — падає.

Webpack: не працює в понеділок (2019)

Баг, що зникає коли на нього дивишся (2/3)

Контекст: webpack — популярний інструмент для JavaScript-розробників. Збирає всі твої JS-файли, CSS, картинки в один бандл для браузера. webpack-cli — його командний інтерфейс.

Розробники webpack-cli додали банер для донатів. Показувався тільки в понеділок:

if (now.getDay() === MONDAY) {
    if (fileOwnerId === process.getuid()) // 💥
}

process.getuid() — це Linux-функція. На Windows її немає. Баг з'являвся ТІЛЬКИ в понеділок, ТІЛЬКИ на Windows. Шість днів на тиждень — ідеально.

Internet Explorer: DevTools як квантовий колапс

Контекст: DevTools — це інструменти розробника в браузері (F12). Там консоль, мережа, DOM-дерево. console.log() — найпростіший спосіб дебажити JS: виводиш змінну в консоль і дивишся.

У IE об'єкт console не існував, поки не відкриєш DevTools. Код з console.log() падав у звичайних користувачів — бо в них DevTools закриті. Розробник відкривав DevTools подивитись — працює. Закривав — все ще працює.

Чому? Бо об'єкт console вже створився при відкритті. Акт спостереження змінив систему назавжди.

Therac-25: коли Heisenbug вбиває (1985-1987)

Це вже не смішно.

Контекст: Therac-25 — медичний апарат для променевої терапії раку. Пацієнт лягає, апарат опромінює пухлину точною дозою радіації. Race condition — це коли два процеси "змагаються" за ресурс, і результат залежить від того, хто встигне першим. Непередбачувано.

Therac-25 мав race condition в софті. Іноді давав летальні дози радіації замість терапевтичних. Загинуло щонайменше троє людей.

Баг з'являвся тільки коли оператор друкував дуже швидко — потрібні були дні практики, щоб випадково натрапити. При стандартному тестуванні — все ідеально. Виробник місяцями не міг відтворити проблему.

Heisenbug, який ховався від спостереження. І вбивав.
———
Класифікація багів (для нердів)

Програмісти створили цілу "фізичну" таксономію:

Баг               Фізик              Що робить                                                         
**Bohrbug**       Niels Bohr         Стабільний, передбачуваний. Нудний, зате ловиться.                
**Heisenbug**     Werner Heisenberg  Зникає, коли дивишся                                              
**Mandelbug**     Benoit Mandelbrot  Фрактальний: чим глибше копаєш, тим більше знаходиш               
**Schroedinbug**  Erwin Schrödinger  Код, що не мав би працювати, але працює — поки хтось не подивиться

———
Що з цього випливає

"Працює" — це не так чи ні

Програма не "працює" або "не працює". Вона працює за певних умов. Debug/release. Linux/Windows. Понеділок/вівторок. З логуванням/без. Змінив умови — змінив результат.

Debugger — не вікно. Це втручання.

Ти не "дивишся на програму". Ти створюєш нову систему: програма + debugger. А вона поводиться інакше.

"Працює на моїй машині" — не жарт

Memory layout різний. OS scheduler різний. Timing різний. Ти і твій колега буквально запускаєте різні програми. Обидва праві. Обидва ні.

Баг існує?

Залежить від того, хто дивиться. Як одночасність подій у теорії відносності — немає абсолютної відповіді.
———
Як ловити те, що тікає

Баг зник під debugger'ом? Це не проблема. Це підказка.

Ти щойно дізнався: баг чутливий до timing'у. Значить, шукай race conditions, memory ordering, timing-залежну логіку. Коло звузилось.

Баг, що зникає коли на нього дивишся (3/3)

Інструменти:
• rr — записує виконання програми один раз (включно з timing, потоками, всім). Потім можеш "перемотувати" назад і вперед скільки хочеш. Баг більше не втече.
• ThreadSanitizer (TSan) — додаєш прапорець -fsanitize=thread при компіляції, і він слідкує за всіма зверненнями до пам'яті. Якщо два потоки лізуть в одне місце без синхронізації — покаже.
• CHESS (Microsoft) — систематично перебирає всі можливі порядки виконання потоків. Не чекає, поки баг "випадково" вилізе — шукає сам.Факт: CHESS відтворив за 30 секунд баг, що з'являвся раз на місяць.
———
Головне

Немає "правди" про програму. Є правда відносно того, як дивишся.

Це не баг у звичному сенсі. Це природа складних систем.

Не питай "де баг?" Питай: "при яких умовах система поводиться так, а при яких — інакше?"

У цьому питанні вже половина відповіді.
———
Наступного разу, коли баг зникне під debugger'ом — посміхнись. Ти щойно побачив квантову механіку в дії.

Heisenbug передає привіт.

Ну як же мило ))

Лайк за ввічливість ))

Пару місяців дослідів, спогадів, роскопок веб-архіва...
І скоро на DOU вийде нова стаття з серії "Еволюція Фронтенда".


#анонс #DOU