Pull to refresh
0
Дайырбек Артелов @4unkurread⁠-⁠only

Веб разработчик

Send message

Я обращал внимание на то, что каждая задача в скорости своего решения натыкается на боттлнек:

  • Невозможно понять, что нужно, из описания задачи. Начинается долгий интерактивный процесс выяснения о чём речь. Бывает, что задача содержит в себе описание решения, которое не работает и нужно отдельно доказывать, что надо делать "не так". Это communication bottleneck.

  • Задача реализуется в продукте с большим неудобным feedback loop'ом (у этого может быть миллион уважительных причин, речь не про это). В этой ситуации задача с одной стороны env bottleneck, с другой стороны всё равно занимает мозг, потому что нельзя выкинуть контекст из головы. Даже если затык не на CI, а на компиляции в 20 минут, это всё равно та же проблема "компилируется". Сюда же включаются все внешние сущности, которых нужно "ждать" (пока выкачается, пока загрузится, пока запустится, пока whatever).

  • Задача требует объективно большого числа нажатий кнопок. Например, перевести все workflow на новую технологию. 400 файлов по 20 строк в каждом, не поддающиеся механическому изменению (требующие чуть-чуть внимания и локальных адаптаций). Это typing bottleneck. Это же относится к задачам уровня CRUD и большого числа boilerplate. Надо печатать. Но думать. Но печатать.

  • Задача алгоритмически сложная. Не обязательно это 'state of art'. Может быть, это что-то уровня "как мы обеспечим инвариант этой функции". Над такой задачей надо думать, и она чаще всего приводит к самому сложному и плотному коду, иногда к 3-10 строкам, выражающим решение задачи. Это local hard-thinking bottleneck.

  • Задача не решаемая в существующем коде и нужно сделать тонкий сложный рефакторинг в множестве мест для того, чтобы решение оказалось консистентным с остальным кодом. Сам новый код может быть тривиальным, но его последствия распространяются на множество малосвязных сущностей и из-за этого изменения затрагивают несчётное (не удерживаемое в голове) количество "мест" (компонент и т.д.). Это global hard-thinking bottleneck.

  • И есть задачи, решения которых не существует в настоящий момент, потому что не понятно что делать, как делать, делать ли, или изменять условия задачи. Часто это связано с новыми технологиями, новыми обстоятельствами или передумыванием подхода на уровне архитектуры. Это research bottleneck.

Соответственно, у разных классов боттлнеков разные ресурсы являются дефицитными. Для communication - это количество сессий с разными людьми (завершённых дискуссий). Худший паттерн - это множество сессий между несколькими людьми, когда с одним человеком возникают новые и новые сессии из-за новых обстоятельств от других людей.

env bottleneck зависит только от часов на стене. Можно три дня по 8 часов отлаживать ci, который падает "в самом конце" в рамках одной задачи. Нагрузка на мозг есть, но она напоминает нагрузку на водителя на трассе. Смотришь, смотришь, иногда чуть-чуть делаешь, дальше смотришь.

typing bottleneck зависит от модели клавиатуры ресурсов человека для контроля этих мелких обстоятельств и является комбинацией запаса концентрации и времени (т.е. тихого времени и неуставшего мозга). Оно напоминает вождение на горной дороге или в городе в условиях плотного движения без пробок. Множество мелких действий, которые происходят почти постоянно и требуют большого внимания.

Оставшиеся три - это чистый стресс на мозг, причём каждый имеет свой профиль по нагрузке. Именно для этих трёх типов человек продолжает работать даже когда не печатает (более того, самая важная работа происходит в перерывах между нажатиями кнопок, потому что сами кнопки - это typing bottleneck, а реальные решения происходят в голове между сеансами typing).

Это моё имхо. Почти пост?

Information

Rating
Does not participate
Location
Бишкек, Кыргызстан, Кыргызстан
Date of birth
Registered
Activity