Two test suites can have exactly the same average runtime and still create completely different development workflows. I modeled 300 code → test → fix cycles while keeping mean feedback latency close to ten seconds and changing only its variance. One runner behaved predictably. The other was usually fast but occasionally became extremely slow. The average stayed almost the same. The cost of waiting did not.

A test taking 20 seconds does not necessarily cost a developer only 20 seconds. At some point during the wait, staying in the IDE becomes less attractive than opening a browser, checking documentation, reading a message, or starting another small task. I built a simulation of 300 code → test → fix cycles to estimate what happens when test latency begins to trigger context switching, and why cutting a test from 20 seconds to 10 may be much more valuable than cutting it from 5 seconds to 1.

Недавно поймал себя на знакомом состоянии. Сел разбираться с задачей, открыл IDE, начал копаться в логике — и в какой-то момент оказалось, что прошло почти шесть часов. Без перерывов.

Обычно про концентрацию говорят через призму продуктивности: техники, таймеры, планирование. Но мне стало интереснее другое — что происходит в мозге разработчика во время длинной сессии кодинга.

Я немного почитал исследования, немного понаблюдал за собой и сделал несколько маленьких экспериментов. В том числе написал пару простых скриптов на Python, чтобы попробовать зафиксировать изменения в состоянии во время длинной работы.

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