tgoop.com »
United States »
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc. » Telegram Web
Forwarded from Михаил
Наткнулся на любопытную статью про ООП, хочу порекомендовать вам ее в контексте недавних обсуждений: https://blog.sigma-star.io/2024/01/people-dont-understand-oop/ и перевод на хабре.
Хабр
Люди не понимают ООП
«ООП для меня означает лишь обмен сообщениями, локальные ограничения и защиту, сокрытие состояния процесса и крайне позднее привязывание», — Алан Кэй (человек, придумавший термин...
🔥6👍2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Вот хорошая книга про конфронтации и споры. https://www.ozon.ru/product/dzhedayskie-tehniki-konstruktivnogo-obshcheniya-orlov-aleksandr-elektronnaya-audiokniga-917253665/?asb=Be%252FFUBK71EHhLQk04ZAlECN22i2r54PLYZjRAV%252FwRMo%253D&asb2=b3hGw0AlGeI7bXnX6OqomduBi5…
💬 Пример из жизни. На одном из тренингов на этапе сбора ожиданий мы обычно спрашиваем всех участников, чего они ждут от этих двух дней и какие вопросы хотят разобрать. Доходит очередь до инженера лет тридцати с очень уставшим видом:
– Я хотел бы научиться отказываться от проектов.
– ?.. Расскажите нам больше…
– Понимаете, сейчас я работаю над пятью проектами одновременно. И мне очень тяжело. Я хотел бы, когда принесут шестой проект, так ловко от него отказаться, чтобы не взять его и чтобы руководство не обиделось.
– А что было, когда вам давали пятый проект?
– [после паузы] Я работал над четырьмя… Мне было очень тяжело… Я им говорил, что не потяну… А они сказали, что очень надо…
– Ну и как, вы потянули?
– Потянул…
– Тогда руководство знает, как дать вам и шестой проект…
Довольно часто руководство и заказчики приходят к нам со срочными просьбами о совершении подвига. И на слова «это невозможно» всегда находится аргумент «ребята, очень надо». После чего мы обычно беремся за этот воз, не спим ночами и совершаем небольшое чудо (иногда вместе с командой). Выдыхаем и надеемся спокойно поработать дальше. И это не получается.
Как эта ситуация выглядит с точки зрения руководства /заказчика? Приходишь к ребятам, просишь что-то сделать.
Поначалу они сопротивляются, говорят, что это невозможно, но после аргумента «очень надо» берут и делают, большие молодцы!
Или, наоборот, руководство подозревает, что, когда вы говорите «невозможно», то, мягко говоря, лукавите. Значит, и дальше надо грузить.
Ни один реальный подвиг не должен оставаться «непроданным». Любой подвиг – это повод для обсуждения с заказчиком подвига (после совершения, когда тот находится в приятственном расположении духа, хорошо к вам относится и готов вас слушать): «Как там, все нормально? Так вот, я поэтому и пришел. То, что произошло, – это чудо, потому что… Как бы нам сделать так, чтобы это все предусмотреть и в следующий раз вас не подвести?»
Зачастую решение одной проблемы создает следующую, которую мы упускаем из виду. И это тоже распространенноенарушение принципа своевременности.
-- "Джедайские техники конструктивного общения" Александра Орлова
– Я хотел бы научиться отказываться от проектов.
– ?.. Расскажите нам больше…
– Понимаете, сейчас я работаю над пятью проектами одновременно. И мне очень тяжело. Я хотел бы, когда принесут шестой проект, так ловко от него отказаться, чтобы не взять его и чтобы руководство не обиделось.
– А что было, когда вам давали пятый проект?
– [после паузы] Я работал над четырьмя… Мне было очень тяжело… Я им говорил, что не потяну… А они сказали, что очень надо…
– Ну и как, вы потянули?
– Потянул…
– Тогда руководство знает, как дать вам и шестой проект…
Довольно часто руководство и заказчики приходят к нам со срочными просьбами о совершении подвига. И на слова «это невозможно» всегда находится аргумент «ребята, очень надо». После чего мы обычно беремся за этот воз, не спим ночами и совершаем небольшое чудо (иногда вместе с командой). Выдыхаем и надеемся спокойно поработать дальше. И это не получается.
Как эта ситуация выглядит с точки зрения руководства /заказчика? Приходишь к ребятам, просишь что-то сделать.
Поначалу они сопротивляются, говорят, что это невозможно, но после аргумента «очень надо» берут и делают, большие молодцы!
Или, наоборот, руководство подозревает, что, когда вы говорите «невозможно», то, мягко говоря, лукавите. Значит, и дальше надо грузить.
Ни один реальный подвиг не должен оставаться «непроданным». Любой подвиг – это повод для обсуждения с заказчиком подвига (после совершения, когда тот находится в приятственном расположении духа, хорошо к вам относится и готов вас слушать): «Как там, все нормально? Так вот, я поэтому и пришел. То, что произошло, – это чудо, потому что… Как бы нам сделать так, чтобы это все предусмотреть и в следующий раз вас не подвести?»
Зачастую решение одной проблемы создает следующую, которую мы упускаем из виду. И это тоже распространенноенарушение принципа своевременности.
-- "Джедайские техники конструктивного общения" Александра Орлова
👍10🔥2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
💬 Пример из жизни. На одном из тренингов на этапе сбора ожиданий мы обычно спрашиваем всех участников, чего они ждут от этих двух дней и какие вопросы хотят разобрать. Доходит очередь до инженера лет тридцати с очень уставшим видом: – Я хотел бы научиться…
В этой же книге:
💬 Когда два сотрудника друг другу в курилке жалуются на начальство: «Блин, опять переезд в новый офис. Сколько можно? Третий раз за год! Заколебали уже…» – это не вполне конструктивно. Потому что, если есть проблема с переездами, они вряд ли решат ее между собой в курилке.
Вот если кто-то после этого разговора пойдет к начальствувыяснять, что и как с переездами, то произойдет переключение в конструктив.
Тут я с автором второй раз не соглашусь, что, правда, не уменьшает ценность книги. Те, кто знаком с теорией управления изменениями, знают, что иногда большего совокупного эффекта можно достигнуть, если позволить кризису назреть, нежели пытаться его компенсировать. Сейчас уже не вспомню, кто автор этого подхода, кажется John P. Kotter (поправьте, пожалуйста, если я ошибаюсь).
С одной стороны, в условиях кризиса меньше сопротивление изменениям, т.к. необходимость изменений становится очевидной для всех.
С другой стороны, кризис может привести к самосвержению руководства, уровень компетентности которого является причиной кризиса. В моей практике такой случай был. И чем скорее кризис назрел, тем быстрее проект освободился от причины кризиса и начал оздоравливаться.
Существуют еще причины в виде политических дивидендов, о которых упоминал Егор Толстой здесь. Я тоже не считаю такие причины допустимыми для профессионала.
Но хочу упомянуть об одном интересном случае, который я наблюдал на практике. Product Owner пытался убедить руководство в проведении дорогостоящего рефакторинга, но эти попытки оказались безуспешны, и они лишь пошатнули его авторитет в глазах команды слабостью своего влияния. Тогда он переключился на формирование общественного мнения команды, т.е. выступил в роли лидера общественного мнения, и вскоре ему удалось осуществить задуманное. Т.е. он сделал в точности наоборот утверждению автора, и это оказалось конструктивно. Если руководство небезнадежное, то оно мониторит общественное мнение. Правда, Product Owner не ныл деструктивно, как в обсуждаемом фрагменте книги, а конструктивно, как подобает настоящему лидеру, излагал каким именно образом можно облегчить деятельность команды.
В общем, не существует абсолютно правильных решений - многое определяется контекстом.
Можно ли назвать деструктивным самоустранение Ивана Грозного от власти и бегство из Москвы? А заявление Сталина с просьбой освободить его от занимаемой должности? В обоих случаях их влияние только увеличилось, хотя, казалось бы, такое поведение эмоционально и деструктивно.
💬 Когда два сотрудника друг другу в курилке жалуются на начальство: «Блин, опять переезд в новый офис. Сколько можно? Третий раз за год! Заколебали уже…» – это не вполне конструктивно. Потому что, если есть проблема с переездами, они вряд ли решат ее между собой в курилке.
Вот если кто-то после этого разговора пойдет к начальствувыяснять, что и как с переездами, то произойдет переключение в конструктив.
Тут я с автором второй раз не соглашусь, что, правда, не уменьшает ценность книги. Те, кто знаком с теорией управления изменениями, знают, что иногда большего совокупного эффекта можно достигнуть, если позволить кризису назреть, нежели пытаться его компенсировать. Сейчас уже не вспомню, кто автор этого подхода, кажется John P. Kotter (поправьте, пожалуйста, если я ошибаюсь).
С одной стороны, в условиях кризиса меньше сопротивление изменениям, т.к. необходимость изменений становится очевидной для всех.
С другой стороны, кризис может привести к самосвержению руководства, уровень компетентности которого является причиной кризиса. В моей практике такой случай был. И чем скорее кризис назрел, тем быстрее проект освободился от причины кризиса и начал оздоравливаться.
Существуют еще причины в виде политических дивидендов, о которых упоминал Егор Толстой здесь. Я тоже не считаю такие причины допустимыми для профессионала.
Но хочу упомянуть об одном интересном случае, который я наблюдал на практике. Product Owner пытался убедить руководство в проведении дорогостоящего рефакторинга, но эти попытки оказались безуспешны, и они лишь пошатнули его авторитет в глазах команды слабостью своего влияния. Тогда он переключился на формирование общественного мнения команды, т.е. выступил в роли лидера общественного мнения, и вскоре ему удалось осуществить задуманное. Т.е. он сделал в точности наоборот утверждению автора, и это оказалось конструктивно. Если руководство небезнадежное, то оно мониторит общественное мнение. Правда, Product Owner не ныл деструктивно, как в обсуждаемом фрагменте книги, а конструктивно, как подобает настоящему лидеру, излагал каким именно образом можно облегчить деятельность команды.
В общем, не существует абсолютно правильных решений - многое определяется контекстом.
Можно ли назвать деструктивным самоустранение Ивана Грозного от власти и бегство из Москвы? А заявление Сталина с просьбой освободить его от занимаемой должности? В обоих случаях их влияние только увеличилось, хотя, казалось бы, такое поведение эмоционально и деструктивно.
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
💬 Пример из жизни. На одном из тренингов на этапе сбора ожиданий мы обычно спрашиваем всех участников, чего они ждут от этих двух дней и какие вопросы хотят разобрать. Доходит очередь до инженера лет тридцати с очень уставшим видом:
– Я хотел бы научиться…
– Я хотел бы научиться…
👍8👏2
Forwarded from Микросервисы / распределенные системы (Sergey Baranov)
О масштабировании
Будем считать систему масштабируемой, если она способна справляться с возрастающей нагрузкой при добавлении ресурсов. Например, мы добавляем новые узлы в систему, что позволяет ей справится с возрастающей нагрузкой. То же самое с компанией — если при увеличении количества планируемой работы добавляются новые команды и при этом система команд продолжает справляться с возрастающей нагрузкой, то система масштабируема (в реальности это далеко не всегда так).
Производительность и масштабируемость — это связанные, но различные концепции. Производительность — это оптимизация времени ответа. Масштабируемость — это оптимизация возможности держать возрастающую нагрузку.
С точки зрения организационной структуры производительность — это то, насколько быстро мы можем выпускать новую функциональность, а масштабируемость — это возможность реализовать большее число бизнес-инициатив, причем не обязательно с увеличением штата сотрудников.
Улучшение производительности сокращает время ответа, однако поддерживаемая нагрузка может не измениться. При этом улучшение масштабируемости увеличивает возможности держать возрастающую нагрузку. Производительность каждого запроса в отдельности может не измениться.
Что сдерживает машстабирование?
Будем считать систему согласованной, если все члены системы имеют единое представление о ее состоянии. Если мы выполним один и тот же запрос на всех инстансах одного сервиса и получим один и тот же ответ, то система согласована. Точно так же, если в команде или компании, — если мы всем зададим один и тот же вопрос и получим один и тот же ответ, то команда или компания согласованы. В противном случае — система не согласована.
Система является доступной, если она продолжает работать несмотря на отдельные сбои. В интернет магазине может перестать работать поиск, но все остальное продолжит работать. В команде один разработчик может заболеть, но это не повлияет на возможности команды выполнять работу (возможно — медленнее или быстрее).
Микросервисы — это распределенные системы. Распределенные системы разделены в пространстве. Физика накладывает ограничение на скорость передачи информации (скорость света). Когда две системы разделены в пространстве, всегда требуется время для достижения консенсуса. В то время, когда информация передается от источника к потребителю, состояние источника может измениться.
Вышесказанное означает, что получатель информации всегда имеет дело с устаревшей информацией. Это справедливо и для информационных систем и для людей и вообще для любых физических систем. Таким образом, реальность — согласована в конечном счете.
Согласованность в конечном счете гарантирует, что в отсутствии новых обновлений, все обращения за доступом с специфичной части данных, в конечном счете вернут последние актуальные данные.
Существуют и другие виды согласованности — строгая, последовательная, причинно-следственная. Традиционные монолитные системы опираются на строгую согласованность. Строгая согласованность означает, что прежде чем обновленные данные станут доступными, все узлы должны должны подтвердить, что обновили свое состояние. Примеры строгой согласованности в жизни — суд присяжных или жюри, которые должны прийти к общей договоренности (или признать, что это сделать не удалось).
Как достигнуть строгой согласованности, если физика говорит, что это невозможно? С помощью блокировок. Распределенные системы изолируются в не распределенные блокировки. Блокировки привносят оверхед в виде конкуренции.
Любые две системы, соперничающие за доступ к общему ресурсу находятся в отношении конкуренции. Эта конкуренция может иметь только одного победителя. Остальные вынуждены ждать, пока победитель не закончит работу и не освободит ресурс. По мере роста уровня конкуренции, возрастает время освобождения ресурса (так как увеличивается размер очереди для доступа к ресурсу).
По мере увеличения нагрузки в конечном счете система выйдет за рамки приемлемого времени выполнения.
Будем считать систему масштабируемой, если она способна справляться с возрастающей нагрузкой при добавлении ресурсов. Например, мы добавляем новые узлы в систему, что позволяет ей справится с возрастающей нагрузкой. То же самое с компанией — если при увеличении количества планируемой работы добавляются новые команды и при этом система команд продолжает справляться с возрастающей нагрузкой, то система масштабируема (в реальности это далеко не всегда так).
Производительность и масштабируемость — это связанные, но различные концепции. Производительность — это оптимизация времени ответа. Масштабируемость — это оптимизация возможности держать возрастающую нагрузку.
С точки зрения организационной структуры производительность — это то, насколько быстро мы можем выпускать новую функциональность, а масштабируемость — это возможность реализовать большее число бизнес-инициатив, причем не обязательно с увеличением штата сотрудников.
Улучшение производительности сокращает время ответа, однако поддерживаемая нагрузка может не измениться. При этом улучшение масштабируемости увеличивает возможности держать возрастающую нагрузку. Производительность каждого запроса в отдельности может не измениться.
Что сдерживает машстабирование?
Будем считать систему согласованной, если все члены системы имеют единое представление о ее состоянии. Если мы выполним один и тот же запрос на всех инстансах одного сервиса и получим один и тот же ответ, то система согласована. Точно так же, если в команде или компании, — если мы всем зададим один и тот же вопрос и получим один и тот же ответ, то команда или компания согласованы. В противном случае — система не согласована.
Система является доступной, если она продолжает работать несмотря на отдельные сбои. В интернет магазине может перестать работать поиск, но все остальное продолжит работать. В команде один разработчик может заболеть, но это не повлияет на возможности команды выполнять работу (возможно — медленнее или быстрее).
Микросервисы — это распределенные системы. Распределенные системы разделены в пространстве. Физика накладывает ограничение на скорость передачи информации (скорость света). Когда две системы разделены в пространстве, всегда требуется время для достижения консенсуса. В то время, когда информация передается от источника к потребителю, состояние источника может измениться.
Вышесказанное означает, что получатель информации всегда имеет дело с устаревшей информацией. Это справедливо и для информационных систем и для людей и вообще для любых физических систем. Таким образом, реальность — согласована в конечном счете.
Согласованность в конечном счете гарантирует, что в отсутствии новых обновлений, все обращения за доступом с специфичной части данных, в конечном счете вернут последние актуальные данные.
Существуют и другие виды согласованности — строгая, последовательная, причинно-следственная. Традиционные монолитные системы опираются на строгую согласованность. Строгая согласованность означает, что прежде чем обновленные данные станут доступными, все узлы должны должны подтвердить, что обновили свое состояние. Примеры строгой согласованности в жизни — суд присяжных или жюри, которые должны прийти к общей договоренности (или признать, что это сделать не удалось).
Как достигнуть строгой согласованности, если физика говорит, что это невозможно? С помощью блокировок. Распределенные системы изолируются в не распределенные блокировки. Блокировки привносят оверхед в виде конкуренции.
Любые две системы, соперничающие за доступ к общему ресурсу находятся в отношении конкуренции. Эта конкуренция может иметь только одного победителя. Остальные вынуждены ждать, пока победитель не закончит работу и не освободит ресурс. По мере роста уровня конкуренции, возрастает время освобождения ресурса (так как увеличивается размер очереди для доступа к ресурсу).
По мере увеличения нагрузки в конечном счете система выйдет за рамки приемлемого времени выполнения.
👍11🔥3
Forwarded from Микросервисы / распределенные системы (Sergey Baranov)
Продолжение
Здесь стоит сделать отсылку с CAP-теореме, но чтобы не усложнять, приведу пример. У вас была одна команда. Вы добавили вторую. Обе команды разрабатывают разные части системы, но используют одно тестовое окружение. Им нужно договориться (добиться согласованности) о внесении изменений в это окружение. CAP теорема говорит, что достижение одновременно 100%-й согласованности, 100%-й доступности и устойчивости к разделению невозможно. То есть, пока команды не имеют возможности договориться, но им требуется 100%-я согласованность, они теряют свойство доступности, – просто не могут начать тестировать. В распределенных системах, в том числе в структуре команд, необходимо при проектировании закладывать такие принципы и свойства, которые позволят принимать максимальное число решений автономно (в данном случае – собственные тестовые среды), а оставшиеся зависимости должны быть неблокирующими (например, – выпуск частей солюшена разными командами в удобном им ритме, но с испоьзованием версионирования API и Feature Toggle). Это и есть обеспечение устойчивости к разделению с использованием согласованности в конечном счете.
Какие еще аналоги можно встретить в компаниях?
Архитектурные комитеты, если они блокируют работу, общие тестовые среды на несколько команд, если для того, чтобы протестировать необходимо вставать в очередь, интеграционные компоненты, вроде ESB, в которых реализована бизнес-логика и команда поддержки ESB становится таким компонентом системы, сдерживающим масштабирование.
В действительности, проектируя микросервисное решение, мы проектируем организацию, потому что если автономность и независимость микросервисов не поддерживается автономостью и неблокирующими зависимости на уровне структуры организации, польза от микросервисов будет крайней ограниченной, а вот всю привносимую ими дополнительную сложность бонусом компания получит в любом случае.
Обобщая вышесказанное, – говоря о масштабировании микросервисов чаще всего подразумевается возможность технически поддержать возрастающую нагрузку. Но это половина правда. Особенность этого стиля в том, что он явным образом поддерживает и масштабируемость разработки (производственной системы), что для компании иногда даже более важно, а этого добиться без организационных изменений в общем случае невозможно.
Здесь стоит сделать отсылку с CAP-теореме, но чтобы не усложнять, приведу пример. У вас была одна команда. Вы добавили вторую. Обе команды разрабатывают разные части системы, но используют одно тестовое окружение. Им нужно договориться (добиться согласованности) о внесении изменений в это окружение. CAP теорема говорит, что достижение одновременно 100%-й согласованности, 100%-й доступности и устойчивости к разделению невозможно. То есть, пока команды не имеют возможности договориться, но им требуется 100%-я согласованность, они теряют свойство доступности, – просто не могут начать тестировать. В распределенных системах, в том числе в структуре команд, необходимо при проектировании закладывать такие принципы и свойства, которые позволят принимать максимальное число решений автономно (в данном случае – собственные тестовые среды), а оставшиеся зависимости должны быть неблокирующими (например, – выпуск частей солюшена разными командами в удобном им ритме, но с испоьзованием версионирования API и Feature Toggle). Это и есть обеспечение устойчивости к разделению с использованием согласованности в конечном счете.
Какие еще аналоги можно встретить в компаниях?
Архитектурные комитеты, если они блокируют работу, общие тестовые среды на несколько команд, если для того, чтобы протестировать необходимо вставать в очередь, интеграционные компоненты, вроде ESB, в которых реализована бизнес-логика и команда поддержки ESB становится таким компонентом системы, сдерживающим масштабирование.
В действительности, проектируя микросервисное решение, мы проектируем организацию, потому что если автономность и независимость микросервисов не поддерживается автономостью и неблокирующими зависимости на уровне структуры организации, польза от микросервисов будет крайней ограниченной, а вот всю привносимую ими дополнительную сложность бонусом компания получит в любом случае.
Обобщая вышесказанное, – говоря о масштабировании микросервисов чаще всего подразумевается возможность технически поддержать возрастающую нагрузку. Но это половина правда. Особенность этого стиля в том, что он явным образом поддерживает и масштабируемость разработки (производственной системы), что для компании иногда даже более важно, а этого добиться без организационных изменений в общем случае невозможно.
🔥13👍4
💬 Проблема заключается в том, что советы, если они вообще берутся на вооружение, тотчас же становятся механическими инструментами. Это значит, что необходимо вводить интервалы между похвалами. Открываются «текущие счета похвал». Когда-то сердитые менеджеры превращаются в машины для метания похвал, а сотрудники только покачивают головами, замечая: «Он опять был на семинаре». Новая причуда техники управления уходит в пустоту.
Следует признать: многие люди на рабочем месте болезненно переживают дефицит признания. Но чувствуют ли они дефицит похвалы? Здесь уместен скепсис. Потому что похвала при более точном ее рассмотрении представляет собой весьма противоречивый и коварный стиль поведения, роковое действие которого проявляется не сразу. В известных обстоятельствах она, однако, скорее вредит отношениям между начальником и подчиненными, чем идет им на пользу. И это следует пояснить.
...
Тот, кто пользуется похвалой как мотивом, наказывается рапортами об успехах. - Это было бы приемлемо в том случае, если бы удовлетворялась только индивидуальная страсть к похвале, а в остальном работники побуждались бы к быстрому и эффективному достижению целей. Но велика опасность получения сообщений о мнимых успехах.
Подразумевается разного рода обман на этикетках, в статистике, в сообщениях о том, что работа идет полным ходом, в нецеленаправленной активности, результаты которой невозможно проверить. Если дарящий похвалу шеф докапывается до истины, то он, глубоко оскорбленный, жалуется на эгоизм и увертливость своих работников, т. е. на те черты характера, которыми он хотел сам воспользоваться в качестве рычага для получения своей выгоды. И потерпел неудачу в соревновании хитрецов!
..
Наоборот: похвала умаляет достоинство! Тот, кто зависит от похвалы, старается до тех пор, пока не получит, что хочет. Он прилагает усилия до «барьера похвалы». Тем самым он делает похвалу шефа и, следовательно, его критерии оценки масштабом своего величия.
Подсмотрено здесь:
https://www.tgoop.com/ru_arc_chat/23615
P.S.: Что думаете по этому поводу?
Следует признать: многие люди на рабочем месте болезненно переживают дефицит признания. Но чувствуют ли они дефицит похвалы? Здесь уместен скепсис. Потому что похвала при более точном ее рассмотрении представляет собой весьма противоречивый и коварный стиль поведения, роковое действие которого проявляется не сразу. В известных обстоятельствах она, однако, скорее вредит отношениям между начальником и подчиненными, чем идет им на пользу. И это следует пояснить.
...
Тот, кто пользуется похвалой как мотивом, наказывается рапортами об успехах. - Это было бы приемлемо в том случае, если бы удовлетворялась только индивидуальная страсть к похвале, а в остальном работники побуждались бы к быстрому и эффективному достижению целей. Но велика опасность получения сообщений о мнимых успехах.
Подразумевается разного рода обман на этикетках, в статистике, в сообщениях о том, что работа идет полным ходом, в нецеленаправленной активности, результаты которой невозможно проверить. Если дарящий похвалу шеф докапывается до истины, то он, глубоко оскорбленный, жалуется на эгоизм и увертливость своих работников, т. е. на те черты характера, которыми он хотел сам воспользоваться в качестве рычага для получения своей выгоды. И потерпел неудачу в соревновании хитрецов!
..
Наоборот: похвала умаляет достоинство! Тот, кто зависит от похвалы, старается до тех пор, пока не получит, что хочет. Он прилагает усилия до «барьера похвалы». Тем самым он делает похвалу шефа и, следовательно, его критерии оценки масштабом своего величия.
Подсмотрено здесь:
https://www.tgoop.com/ru_arc_chat/23615
P.S.: Что думаете по этому поводу?
Telegram
Sergey Baranov in RASA Chat
По вопросам мотивации и демотивации очень сильно рекомендую.
👍4🔥2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
💬 Проблема заключается в том, что советы, если они вообще берутся на вооружение, тотчас же становятся механическими инструментами. Это значит, что необходимо вводить интервалы между похвалами. Открываются «текущие счета похвал». Когда-то сердитые менеджеры…
Статья о том, почему софтверные компании умирают, когда власть захватывают менеджеры вместо технических профессионалов.
Обращает на себя внимание фраза, которая развивает тему предыдущего поста:
💬 The only person whose praise matters is another programmer.
Именно в этом заключается, как мне кажется, истинный путь к лидерству. Ведь слово "ведущий" (т.е. лидер) имеет смысл только в контексте "ведущий кого"?
Когда специалист действует ради сиюминутной похвалы от руководства, то он тем самым блокирует собственное развитие до топового уровня (или до основания собственной компании) по одной простой причине - у него сформирована потребность в том, чтоб его постоянно "кто-то хвалил сверху". Т.е. он добровольно ограничивает себя ролью второй скрипки.
На практике иногда приходилось наблюдать как специалист уступал профессиональностью своего решения в обмен на благорасположение бизнес-менеджмента, что приводило к утрате авторитета среди коллег, к загниванию системы, и, в конечном итоге, как это ни парадоксально звучит, к утрате того самого доверия менеджмента, ради которого он так действовал, а иногда даже к увольнению под благовидным предлогом, чтоб не задеть ущемленное самолюбие и не спровоцировать негативные отзывы о компании. Специалист думал, что занимая "удобную" для менеджмента позицию он тем самым перекладывает на него всю полноту ответственности за последствия такого решения. Но менеджмент видел это так, что если специалист согласился, то он осознаёт все последствия и считает возможным реализовать "хотелку" без ущерба для системы. Истина в том, что ответственность не перекладывается вместе с полномочиями, но это становится очевидным слишком поздно.
Истинный авторитет обнажается только тогда, когда время отобьет весь шлак дешевого авторитета. На это требуется время и не у всех хватает смелости вытерпеть.
Мудрый специалист мыслит дальше, чем сиюминутная похвала менеджмента, и оценивает свои решения объективными последствиями, от которых зависит то, продолжит ли завтра этот менеджер хвалить его, сохранив свой пост в компании, выстоявшей в конкурентной борьбе.
💬 All successful software companies had, as their dominant personality, a leader who nurtured programmers.
P.S.: Большинство моих бывших коллег-программистов сегодня занимают ответственные руководящие или архитектурные должности в крупных высокотехнологичных компаниях. Я никогда не получил бы поддержку такого количество руководителей ИТ-рынка, если бы пренебрег автортетом перед ними.
А лучшее признание - это признание от своих бывших коллег, с которыми ты уже не работаешь вместе, потому что его бескорыстность не вызывает сомнений.
Обращает на себя внимание фраза, которая развивает тему предыдущего поста:
💬 The only person whose praise matters is another programmer.
Именно в этом заключается, как мне кажется, истинный путь к лидерству. Ведь слово "ведущий" (т.е. лидер) имеет смысл только в контексте "ведущий кого"?
Когда специалист действует ради сиюминутной похвалы от руководства, то он тем самым блокирует собственное развитие до топового уровня (или до основания собственной компании) по одной простой причине - у него сформирована потребность в том, чтоб его постоянно "кто-то хвалил сверху". Т.е. он добровольно ограничивает себя ролью второй скрипки.
На практике иногда приходилось наблюдать как специалист уступал профессиональностью своего решения в обмен на благорасположение бизнес-менеджмента, что приводило к утрате авторитета среди коллег, к загниванию системы, и, в конечном итоге, как это ни парадоксально звучит, к утрате того самого доверия менеджмента, ради которого он так действовал, а иногда даже к увольнению под благовидным предлогом, чтоб не задеть ущемленное самолюбие и не спровоцировать негативные отзывы о компании. Специалист думал, что занимая "удобную" для менеджмента позицию он тем самым перекладывает на него всю полноту ответственности за последствия такого решения. Но менеджмент видел это так, что если специалист согласился, то он осознаёт все последствия и считает возможным реализовать "хотелку" без ущерба для системы. Истина в том, что ответственность не перекладывается вместе с полномочиями, но это становится очевидным слишком поздно.
Истинный авторитет обнажается только тогда, когда время отобьет весь шлак дешевого авторитета. На это требуется время и не у всех хватает смелости вытерпеть.
Мудрый специалист мыслит дальше, чем сиюминутная похвала менеджмента, и оценивает свои решения объективными последствиями, от которых зависит то, продолжит ли завтра этот менеджер хвалить его, сохранив свой пост в компании, выстоявшей в конкурентной борьбе.
💬 All successful software companies had, as their dominant personality, a leader who nurtured programmers.
P.S.: Большинство моих бывших коллег-программистов сегодня занимают ответственные руководящие или архитектурные должности в крупных высокотехнологичных компаниях. Я никогда не получил бы поддержку такого количество руководителей ИТ-рынка, если бы пренебрег автортетом перед ними.
А лучшее признание - это признание от своих бывших коллег, с которыми ты уже не работаешь вместе, потому что его бескорыстность не вызывает сомнений.
👍11❤2🔥1💯1
Forwarded from Бренды на коне
Media is too big
VIEW IN TELEGRAM
Парень сделал краткий пересказ 95% выступлений на IT-конференциях. Я прям ждала, когда он скажет «мы делаем этот мир лучше».
😁33👍15🔥4❤3💯2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
За что отвечает архитектура? 1. За выявление наиболее существенных требований и за разрешение противоречивых (конфликтующих или обратно-коррелирующих требований). 2. За устранение напряжения между требованиями и конструкцией (это когда то, что хотим, - не…
Настоящий лидер, с железной волей и стальными яйцами. И большим болтом на всякую управленческую гниль. И поэтому про него узнал весь мир. Вот таким же решительным должен быть и ИТ-архитектор, в руки которого достался кризисный проект.
https://vk.com/wall-51431740_874175
https://vk.com/wall-51431740_874175
VK
Чумовой Доктор. Пост со стены.
❗ Уволили хирурга, который пришил лицо мальчику
4-летний мальчик, играя в футбол, случайно за... Смотрите полностью ВКонтакте.
4-летний мальчик, играя в футбол, случайно за... Смотрите полностью ВКонтакте.
👍10🔥6
Подборка воркшопов с Сашей Клименко (основательницей Soft Skills Lab) за 5 лет
▫️ «Конфликтовать нельзя договариваться», лето 2023
▫️ «Как перестать искать проблемы в процессах и решать их через коммуникации», весна 2023
▫️ «Конфликты в жизни продакта. Как выстроить экологичную и эффективную коммуникацию в команде», осень 2021
▫️ «Делаем кастдевы круче», весна 2020
▫️ «Конфликты: распознавать, понимать, решать», осень 2019
Источник: https://www.tgoop.com/sslpractice/478
▫️ «Конфликтовать нельзя договариваться», лето 2023
▫️ «Как перестать искать проблемы в процессах и решать их через коммуникации», весна 2023
▫️ «Конфликты в жизни продакта. Как выстроить экологичную и эффективную коммуникацию в команде», осень 2021
▫️ «Делаем кастдевы круче», весна 2020
▫️ «Конфликты: распознавать, понимать, решать», осень 2019
Источник: https://www.tgoop.com/sslpractice/478
Telegram
Soft Skills Lab
👍4🔥3
С сегодняшнего дня я хочу начать цикл постов об антикризисной архитектуре. И постараюсь структурировать все свои знания по этой теме.
Итак, представьте, что Вы - архитектор, и Вам достался кризисный проект. Думаю, что многим не составит это особого труда, т.к. по результатам опроса две трети недовольны условиями работы, а каждый пятый регулярно испытывает желание уволиться. И "здоровый проект" встречается на рынке труда гораздо реже, чем кризисный, в котором все сроки сорваны, люди демотивированы, текучка кадров обретает масштабы потопа, самое употребимое выражение - WTF, устранение одного дефекта порождает несколько других дефектов, клиенты жалуются, performance характеристики сравнялись с возможностями деревянных счет и т.д.
Итак, представьте, что Вы - архитектор, и Вам достался кризисный проект. Думаю, что многим не составит это особого труда, т.к. по результатам опроса две трети недовольны условиями работы, а каждый пятый регулярно испытывает желание уволиться. И "здоровый проект" встречается на рынке труда гораздо реже, чем кризисный, в котором все сроки сорваны, люди демотивированы, текучка кадров обретает масштабы потопа, самое употребимое выражение - WTF, устранение одного дефекта порождает несколько других дефектов, клиенты жалуются, performance характеристики сравнялись с возможностями деревянных счет и т.д.
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Довольны ли вы своими условиями работы (качество организации процессов, морально-психологический климат, отношение руководства, состояние кодовой базы, покрытие тестами, качество документации, темпы разработки и т.п.)?
P.S.: опрос анонимный
Я всем доволен…
P.S.: опрос анонимный
Я всем доволен…
🔥31👍4🤔1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
С сегодняшнего дня я хочу начать цикл постов об антикризисной архитектуре. И постараюсь структурировать все свои знания по этой теме. Итак, представьте, что Вы - архитектор, и Вам достался кризисный проект. Думаю, что многим не составит это особого труда…
Как правило, кризис выражается в том, что внесение изменений в систему длится неприлично долго. Осознание этого факта руководством приводит к стремлению минимизировать количество изменений путем повышения точности проектирования (и прогнозирования). И это, естественно, не срабатывает. Напряжение возрастает. Начинается хронический поиск виновных.
Попытаемся распутать клубок и выстроить тактику поведения в таких условиях.
"Внесение изменения длится неприлично долго" - из этой фразы вытекает два важных вопроса:
1) Почему изменение нужно вносить именно сейчас? Почему нельзя было сразу сделать как нужно?
2) Почему вносить само изменение долго и дорого?
Первый вопрос лежит в Problem Space, и отностися к области анализа и управления процессами разработки.
Второй вопрос лежит в области Solution Space и относится к области Software Design.
Ну а поскольку на стыке этих областей находится архитектура, то это - архитектурная проблема, а значит, если архитектор эту проблему не решит, то её не решит никто, и проект в таком случае, по-сути, обречен.
Главный вывод, который из этого следует, - решение кризиса должно быть комплексным, и должно включать в себя решения в области бизнес-анализа, Software Design и управления процессами разработки (SDLC).
Кроме этого, внесение изменений может встретить сопротивление, что потребует еще и навыков коммуникативной и управленческой психологии.
И отдельно я выделил бы искусство политики/дипломатии, т.е. управление внутриполитическими корпоративными силами и умелое их использование для реализации возложенных на архитектора функций.
Попытаемся распутать клубок и выстроить тактику поведения в таких условиях.
"Внесение изменения длится неприлично долго" - из этой фразы вытекает два важных вопроса:
1) Почему изменение нужно вносить именно сейчас? Почему нельзя было сразу сделать как нужно?
2) Почему вносить само изменение долго и дорого?
Первый вопрос лежит в Problem Space, и отностися к области анализа и управления процессами разработки.
Второй вопрос лежит в области Solution Space и относится к области Software Design.
Ну а поскольку на стыке этих областей находится архитектура, то это - архитектурная проблема, а значит, если архитектор эту проблему не решит, то её не решит никто, и проект в таком случае, по-сути, обречен.
Главный вывод, который из этого следует, - решение кризиса должно быть комплексным, и должно включать в себя решения в области бизнес-анализа, Software Design и управления процессами разработки (SDLC).
Кроме этого, внесение изменений может встретить сопротивление, что потребует еще и навыков коммуникативной и управленческой психологии.
И отдельно я выделил бы искусство политики/дипломатии, т.е. управление внутриполитическими корпоративными силами и умелое их использование для реализации возложенных на архитектора функций.
🔥14👍8
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Как правило, кризис выражается в том, что внесение изменений в систему длится неприлично долго. Осознание этого факта руководством приводит к стремлению минимизировать количество изменений путем повышения точности проектирования (и прогнозирования). И это…
Если мы посмотрим на статистику провалов проектов, то увидим, что на первом месте - несоответствие оценки трудоемкости реальным трудозатратам. На втором месте - увеличение объема работ.
Источник: "Factors Contributing in Failures of Software ProjectsFactors Contributing in Failures of Software Projects"
by Muhammad Hamid, Furkh Zeshan, Adnan Ahmad and Esma Aimeur
http://paper.ijcsns.org/07_book/201905/20190509.pdf
Источник: "Factors Contributing in Failures of Software ProjectsFactors Contributing in Failures of Software Projects"
by Muhammad Hamid, Furkh Zeshan, Adnan Ahmad and Esma Aimeur
http://paper.ijcsns.org/07_book/201905/20190509.pdf
🔥4👍2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Если мы посмотрим на статистику провалов проектов, то увидим, что на первом месте - несоответствие оценки трудоемкости реальным трудозатратам. На втором месте - увеличение объема работ. Источник: "Factors Contributing in Failures of Software ProjectsFactors…
И статистика чуть постарее, но причины те же самые, только в обратном порядке:
1) Изменение объема работ;
2) Несоответствие оценки трудоемкости реальным трудозатратам.
Источник: "Управление требованиями" / Илья Корнипаев
1) Изменение объема работ;
2) Несоответствие оценки трудоемкости реальным трудозатратам.
Источник: "Управление требованиями" / Илья Корнипаев
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
И статистика чуть постарее, но причины те же самые, только в обратном порядке: 1) Изменение объема работ; 2) Несоответствие оценки трудоемкости реальным трудозатратам. Источник: "Управление требованиями" / Илья Корнипаев
Из статистики следует два важных вопроса:
1) Почему реальные трудозатраты на практике существенно превышают прогнозируемую оценку трудоемкости?
2) Почему нельзя заблаговременно установить весь объем работ?
1) Почему реальные трудозатраты на практике существенно превышают прогнозируемую оценку трудоемкости?
2) Почему нельзя заблаговременно установить весь объем работ?
👍5
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Из статистики следует два важных вопроса: 1) Почему реальные трудозатраты на практике существенно превышают прогнозируемую оценку трудоемкости? 2) Почему нельзя заблаговременно установить весь объем работ?
Начнем с Solution Space, или почему вносить изменения в проект становится дорого.
В начале 2000-х размер средней системы на рынке постоянно возрастал и достиг такого предела, когда создавать системы по-старому было уже затруднительно. Основных сдерживающих фактора было два:
1) Когнитивная нагрузка на команду. Размер единовременно рассматриваемой сложности превосходил возможности краткосрочной памяти человека (Закон Миллера). Причем, это была именно существенная сложность, которая не решалась появлением очередного фреймворка. Требовался пересмотр основ моделирования.
2) Проблема Брукса. Рост коммуникативной нагрузки между командами.
По этим же причинам и сегодня многие современные рыночные проекты достигают кризиса по мере увеличения своего размера и численности коллектива разработки. Они просто достигают такого предела, когда развиваться по-старому они больше не могут. И никакой очередной фреймворк, никакая "серебрянная пуля" здесь помочь уже не могут.
Эволюционно эта проблема была решена появлением концепции Bounded Context, на основе которой сформировалась микросервисная архитектура. Ключевое отличие микросервисной архитектуры от сервис-ориентированной заключается в том, что первая отдает предпочтение автономности в ущерб реиспользованию, в то время как вторая - наоборот. Подробней этот вопрос рассматривается в "Microservices Architecture" by The Open Group и в "TOGAF® Series Guide Microservices Architecture (MSA) Prepared by The Open Group MSA Work Group".
Остановимся подробней на том, каким образом концепция Bounded Context может способствовать удешевлению разработки.
В начале 2000-х размер средней системы на рынке постоянно возрастал и достиг такого предела, когда создавать системы по-старому было уже затруднительно. Основных сдерживающих фактора было два:
1) Когнитивная нагрузка на команду. Размер единовременно рассматриваемой сложности превосходил возможности краткосрочной памяти человека (Закон Миллера). Причем, это была именно существенная сложность, которая не решалась появлением очередного фреймворка. Требовался пересмотр основ моделирования.
2) Проблема Брукса. Рост коммуникативной нагрузки между командами.
По этим же причинам и сегодня многие современные рыночные проекты достигают кризиса по мере увеличения своего размера и численности коллектива разработки. Они просто достигают такого предела, когда развиваться по-старому они больше не могут. И никакой очередной фреймворк, никакая "серебрянная пуля" здесь помочь уже не могут.
Эволюционно эта проблема была решена появлением концепции Bounded Context, на основе которой сформировалась микросервисная архитектура. Ключевое отличие микросервисной архитектуры от сервис-ориентированной заключается в том, что первая отдает предпочтение автономности в ущерб реиспользованию, в то время как вторая - наоборот. Подробней этот вопрос рассматривается в "Microservices Architecture" by The Open Group и в "TOGAF® Series Guide Microservices Architecture (MSA) Prepared by The Open Group MSA Work Group".
Остановимся подробней на том, каким образом концепция Bounded Context может способствовать удешевлению разработки.
Wikipedia
Магическое число семь плюс-минус два
правило и психологическая статья 1956 года
🔥7👍3❤1❤🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Начнем с Solution Space, или почему вносить изменения в проект становится дорого. В начале 2000-х размер средней системы на рынке постоянно возрастал и достиг такого предела, когда создавать системы по-старому было уже затруднительно. Основных сдерживающих…
Представьте, что нужно проложить маршрут из Москвы в Мурманск. Сможет ли это сделать человек по точной копии Земли в масштабе один к одному? Очевидно, что нет, т.к. количество деталей, нерелевантных решаемой проблеме (т.е. паразитная когнитивная нагрузка), превысит когнитивные возможности человека. Чтобы осуществить эту задачу, необходимо абстрагироваться от нерелевантных деталей и снизить уровень единовременно рассматриваемой сложности. Т.е. нужно оставить в модели только те аспекты оригинала моделирования, которые релевантны решаемой проблеме. Именно этим и занимаются навигационные карты.
💬️ “Модель - это упрощение; это такая интерпретация реальности, при которой из явления извлекаются существенные для решения задачи аспекты, а лишние детали игнорируются.
A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.”
—“Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans, перевод В.Л. Бродового
Я затрудняюсь в точном переводе термина problem. И хотя употребление термина "проблема" не совсем корректно, но термин "задача" (task) тесно ассоциируется в SDLC с запросом на системный инкремент (т.е. о том, как нужно изменить конструкцию). Поэтому я предпочитаю придерживаться термина "проблема".
В контексте решения проблемы определения степени загрузки лифта все, что требуется от оригинала (т.е. от человека) - это его масса.
Но если мы посмотрим на оригинал как на сотрудника, то нам его масса станет нерелевантной, зато релевантными станут его должность, отдел, обязанности и т.п. Которые, в свою очередь, будут нерелевантными в контекста определения степени загрузки лифта.
А вот для столовой нам будет релевантно только то, есть ли у человека какая-то предписанная ему диета и имеются ли аллергические реакции.
Если мы посмотрим на оригинал как на плательщика, то нам будут релевантными только его платежные реквизиты.
Если мы посмотрим на оригинал как на получателя товара, то нам будут релевантыми адрес и время вручения груза.
В перечисленных моделях рассматриваются совершенно различные аспекты оригинала.
У @StanislavBolsun есть хороший Long Read по моделированию.
Понимание основ моделирования - это фундамент эффективной разработки. Без этого фундамента не получится создать крупную систему. Поэтому определение контуров моделей и их разделение - это основная (но не единственная) цель антикризисной архитектуры.
💬️ “Модель - это упрощение; это такая интерпретация реальности, при которой из явления извлекаются существенные для решения задачи аспекты, а лишние детали игнорируются.
A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.”
—“Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans, перевод В.Л. Бродового
Я затрудняюсь в точном переводе термина problem. И хотя употребление термина "проблема" не совсем корректно, но термин "задача" (task) тесно ассоциируется в SDLC с запросом на системный инкремент (т.е. о том, как нужно изменить конструкцию). Поэтому я предпочитаю придерживаться термина "проблема".
В контексте решения проблемы определения степени загрузки лифта все, что требуется от оригинала (т.е. от человека) - это его масса.
Но если мы посмотрим на оригинал как на сотрудника, то нам его масса станет нерелевантной, зато релевантными станут его должность, отдел, обязанности и т.п. Которые, в свою очередь, будут нерелевантными в контекста определения степени загрузки лифта.
А вот для столовой нам будет релевантно только то, есть ли у человека какая-то предписанная ему диета и имеются ли аллергические реакции.
Если мы посмотрим на оригинал как на плательщика, то нам будут релевантными только его платежные реквизиты.
Если мы посмотрим на оригинал как на получателя товара, то нам будут релевантыми адрес и время вручения груза.
В перечисленных моделях рассматриваются совершенно различные аспекты оригинала.
У @StanislavBolsun есть хороший Long Read по моделированию.
Понимание основ моделирования - это фундамент эффективной разработки. Без этого фундамента не получится создать крупную систему. Поэтому определение контуров моделей и их разделение - это основная (но не единственная) цель антикризисной архитектуры.
YouTube
Ярослав Лопухин. Введение в прикладной системный анализ: модели и моделирование
Докладом “Модели и моделирование” мы продолжаем цикл лекций по прикладному системному анализу, посвященных памяти замечательного ученого и педагога Ф.П. Тарасенко.
Главный рабочий инструмент системного анализа — модель. Построенная модель становится средством…
Главный рабочий инструмент системного анализа — модель. Построенная модель становится средством…
👍7🔥7❤3
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Представьте, что нужно проложить маршрут из Москвы в Мурманск. Сможет ли это сделать человек по точной копии Земли в масштабе один к одному? Очевидно, что нет, т.к. количество деталей, нерелевантных решаемой проблеме (т.е. паразитная когнитивная нагрузка)…
Чтобы лучше вообразить то, что происходит в мозгу, когда объем единовременно рассматриваемой сложности превышает возможности краткосрочной памяти человека, посмотрите на эту картинку. Сколько точек вы видите?
Ваши глаза не могут увидеть все 12 точек одновременно. Ninio's extinction illusion. Twelve black dots cannot be seen at once. Ninio, J. and Stevens, K. A. (2000) Variations on the Hermann grid: an extinction illusion. Perception, 29, 1209-1217. The image source is "a post" by Akiyoshi Kitaoka.
Вероятное объяснение этого явления:
Природа этого явления отлична от Закона Миллера. Но суть та же - начинается "жонглирование". И чем больше "шариков" сложности загружено в память, тем легче уронить один из них.
Ваши глаза не могут увидеть все 12 точек одновременно. Ninio's extinction illusion. Twelve black dots cannot be seen at once. Ninio, J. and Stevens, K. A. (2000) Variations on the Hermann grid: an extinction illusion. Perception, 29, 1209-1217. The image source is "a post" by Akiyoshi Kitaoka.
Вероятное объяснение этого явления:
💬 "Your eye's receptors are stimulated and influenced by the activity of neighboring receptors. In a complex, repetitive grid like this, one receptor can have trouble perceiving the dots accurately because of stimulation occurring in a nearby receptor."
—источник
Природа этого явления отлична от Закона Миллера. Но суть та же - начинается "жонглирование". И чем больше "шариков" сложности загружено в память, тем легче уронить один из них.
🔥14👍7