Не пробовали переехать в более безопасный район? Внешняя обстановка может сильно давить морально, что всё остальное и самое важное в жизни уходит на второй план. Но стоит сменить и жизнь начинает играть новыми красками.
Конфликты в отношениях это как специи: когда их слишком много, то уже невкусно, а если нет совсем, то - пресно. В целом они помогают понять, что для тебя действительно важно, учат держать свои рамки и уважать чужие. Тогда все остальное воспринимантся лишь как эмоциональные горки, на которых можно весело кататься, абсолютно не рискуя съехать с катушек.
Корпоративные программы вполне могут быть суррогатном самореализации, образования, досугу, друзьям и даже семье. Я имел ввиду лишь то, что в таких исследованиях больше практического смысла чем кажется.
моноиды дают возможность легко объединять множество элементов в один.
Скорее имелось ввиду, что модуль Monoid предоставляет утилиту concatAll(), которая делает сверку последовательности моноидов. Аналогичная функция есть и в модуле Semigroup, но требует дополнительный аргумент с начальным значением на случай если последовательность окажется пустой (Monoid в таком случае использует empty).
В определенном смысле одиночество это скилл. Одинокие люди стараются заполнить эту пустоту. Из тех, кто заполняет, например, работой получаются уникальные сотрудники.
В математике сложение одновременно и ассоциативно (можно расставлять скобки как угодно), и коммутативно (можно менять порядок аргументов местами). Конкатенация только ассоциативна. Поэтому отсылка к перестановке слагаемых для полугруп, по сути, мимо кассы и новичков может лишь сбивать с толку.
В JavaScript есть врождённый порок - здесь "+" используется и как оператор сложения, когда речь идёт о числах, и как оператор конкатенации, когда речь идёт о строках. fp-ts в некоторой степени это исправляет, вводя разные имена для оператора конкатенации (Semigroup.concat) и сложения (Semiring.add).
Ассоциативность можно наглядно показать на примере строк:
concat ("foo", concat ("bar", "baz")) ==
cancat (concat ("foo", "bar"), "baz") ==
"foobarbaz"
Но если переставить аргументы местами, то результат будет другим.
При всей своей полезности второстепенный персонаж Сасмен на этом выходит из сюжета..
Пессимизация заслуг сотрудника является типовым приемом при увольнении, когда персонаж больше не нужен. Это частный случай более общего принципа "ни кто не платит за уже оказанную услугу".
Раньше были популярны сюжеты про супергероев, когда человек просто оказывался в нужное время в нужном месте и повествование завершалось всеобщей вечеринкой. В умах форсировался устойчивый паттерн, что этот хэппи-энд будет длиться вечно.
В эпоху постмодернизма свершения оцениваются через призму контекста и его смена легко меняет плюс на минус. Супергерои дряхлеют и деградируют. А некогда благодарная публика уже ни чего не помнит, давно переключив внимание на новые сюжеты.
Ваши наблюдения выстроены в таком ключе, что давят на самооценку. Для школьников такой прием звучит на грани фола. Для людей постарше - как минимум странным. Поэтому в качестве провокации статья конечно удалась, не оставив никого равнодушным и собрав кучу комментариев.
Есть такой тип учителей, что-то типа снаряда в спортзале. Ну скажем, турника. Его вопросы не оставляют ни кого равнодушными и ученики готовы перерыть полбиблиотеки в поисках аргументов, чтобы показать своё превосходство. Он справляется со своей работой когда ученик выходит с ощущением, что смог превзойти своего учителя, доказав неправоту и разгромив того в пух и прах. Количество минусов с одной стороны, и комментариев к статье с другой, думаю, хороший тому пример).
Виден математический подход. Сперва решать задачу по максимуму в общем виде. Когда же решение становится сложным, начинаем срезать углы, делая подстановки для интересующих нас частных случаев.
Мне кажется преждевременная генерализация играет тут плохую шутку, добавляя по сути не нужные детали и ограничения. Это вынудило потом добавлять в реализацию код, выглядящий там как костыли не соответствуюший основной иде.
Канбан минимизирует время отклика (lead time) по отдельным задачам - как правило самым приоритетным. Поэтому здесь задачи представляют собой какой-то осмысленный кусок, который есть смысл доставлять. Кодревью ни куда не поставляется - это просто операция.
Один из законов управления гласит, что усиление контроля ведёт к снижению теоретической производительности. Можно заводить такси на каждый чих, но накладные расходы на их менеджмент сведут всю пользу на нет.
Видимо data-driven UI это то, что нельзя просто так взять и внедрить со старта - компания до него может только дорасти. Можно использовать как маркер уровня технической зрелости. Сам же подход стар как мир: TCL/TK, UIML, XAML, XUL, BEMJSON, QML..
Версионирование API в заголовке или в пути это давняя дилемма. Интересно, из каких соображений для v3 выбирали заголовки, и из каких потом от них отказались?
Над уровнем архитектуры приложений находится архитектура систем. Но если вы хотите, чтобы системы в вашей организации строились по каким-то общим принципам, то получается нужна архитектура архитектур, модели моделей (метамодели) и все вот это. Довольно абстрактная деятельность, которая находится на три уровня абстракции выше конечной разработки, однако может иметь там самые серьезные последствия - как в плане побед, так и ошибок. Результаты такой деятельности в разработку падают в виде спецификаций, бест практик, запросов на изменения и т.п. Часто проблемы возникают из-за того, что архитекторы коммуницируют это в виде экшен айтемов - что нужно сделать, пропуская предпосылки - для чего. В итоге разработка действительно не понимает для чего все это нужно и потом всячески сопротивляется.
Мне бы тоже хотелось видеть конкретные примеры, чем они занимаются. Хотя фокус статьи на другом, поэтому не вижу смысла критиковать автора, она рассказала про свой кусочек работы.
полезные изменения многим были интересны, некоторым безразлично, но чтобы противиться — то только на задачи типа "дичь".
"Дичь" это субъективная оценка. Во многом она зависит от прошлого опыта и текущих скиллов. Люди совершенно разные. Кто-то понимает и готов с радостью подхватывать изменения, другие наоборот - не понимают, или не видят для себя лично пользы, или видят угрозу и тормозят. Со всем этим приходится работать.
Через сопутствующее мобильное приложение, с кучей разных полезных функций. Например функция помощи при аварии с поиском ближайшего автосервиса предлагает заранее ввести свои данные, такие как ФИО, SSN, Driver license и т.п.
Если у команды есть реальных 25% времени чтобы внедрить хорошую технологию «с понятной ценностью» то никто не будет бодаться, а с радостью за это возьмутся.
Здесь как с уборкой - в теории всем нравится когда удобно и красиво как в пятизвёздочном отеле, но в реальности менять своих привычки бросать носки куда попало и разгребать авгиевы конюшни за другими ни кто не стремится.
У меня по опыту внедрение новых технологий и полезных инженерных практик, по большому счету это всегда боль. Причем менеджмент с их сроками и бюджетами здесь полбеды. Много отрицания идёт от самих же инженеров - людям удобнее и кажется безопаснее работать так, как они привыкли.
Для того, чтобы изменить что-то технически, сперва приходится менять самих людей: либо учить и воспитывать пока новые подходы не войдут в привычку, либо в прямом смысле. Банальный пример - кодстайл. На одном из проектов внедрение заняло больше года, т.к. взрослые дядьки на серьезных щщах ни как не могли договориться относительно отступов: табы или пробелы.
"Жандарм – это порядок, а порядок никто не любит". В разных компаниях реальные функции и полномочия скрам-мастера сильно разнятся, поэтому без знания местных особенностей обсуждение нужен/не нужен это холивар. Кроме того, как у любых руководителей, многое определяется сугубо личными качествами и опытом.
А эта работа связана с реальными стрессовыми ситуациями? Как скорая и или пожарная? Или вы просто просираете сроки из-за плохого менеджмента
Современное айти это командная работа. Командная работа это работа с людьми, а людям свойственно проявлять эмоции. Позитивные, негативые - разные. Умение их контролировать это тоже навык.
Источником раздражения не обязательно будет начальство. Много стресса доставляют новички у которых просто нет ещё таких навыков. Эпизодически коллеги вашего же уровня. Дальше - люди со стороны, заказчики, подрядчики или допустим пользователи вашего продукта.
Стрессовой ситуация может стать и по личным причинам - плохое настроение, кто-то наступил на ногу в метро, проблемы с близкими, политика, погода, усталость. Некоторые болезненно относятся к критике, пусть даже самой конструктивной. Некоторые видят негатив даже в самых нейтральных вещах, как вопрос о стрессоустойчивости.
Если у человек не умеет выключаться из своих эмоций это может протекать в работу и сказываться на результатах. Поэтому вопрос в принципе уместный. Просто не факт, что для получения ответа его нужно задавать вот так в лоб.
Не пробовали переехать в более безопасный район? Внешняя обстановка может сильно давить морально, что всё остальное и самое важное в жизни уходит на второй план. Но стоит сменить и жизнь начинает играть новыми красками.
Конфликты в отношениях это как специи: когда их слишком много, то уже невкусно, а если нет совсем, то - пресно. В целом они помогают понять, что для тебя действительно важно, учат держать свои рамки и уважать чужие. Тогда все остальное воспринимантся лишь как эмоциональные горки, на которых можно весело кататься, абсолютно не рискуя съехать с катушек.
Корпоративные программы вполне могут быть суррогатном самореализации, образования, досугу, друзьям и даже семье. Я имел ввиду лишь то, что в таких исследованиях больше практического смысла чем кажется.
Скорее имелось ввиду, что модуль Monoid предоставляет утилиту concatAll(), которая делает сверку последовательности моноидов. Аналогичная функция есть и в модуле Semigroup, но требует дополнительный аргумент с начальным значением на случай если последовательность окажется пустой (Monoid в таком случае использует empty).
В определенном смысле одиночество это скилл. Одинокие люди стараются заполнить эту пустоту. Из тех, кто заполняет, например, работой получаются уникальные сотрудники.
В математике сложение одновременно и ассоциативно (можно расставлять скобки как угодно), и коммутативно (можно менять порядок аргументов местами). Конкатенация только ассоциативна. Поэтому отсылка к перестановке слагаемых для полугруп, по сути, мимо кассы и новичков может лишь сбивать с толку.
В JavaScript есть врождённый порок - здесь "+" используется и как оператор сложения, когда речь идёт о числах, и как оператор конкатенации, когда речь идёт о строках. fp-ts в некоторой степени это исправляет, вводя разные имена для оператора конкатенации (Semigroup.concat) и сложения (Semiring.add).
Ассоциативность можно наглядно показать на примере строк:
Но если переставить аргументы местами, то результат будет другим.
Пессимизация заслуг сотрудника является типовым приемом при увольнении, когда персонаж больше не нужен. Это частный случай более общего принципа "ни кто не платит за уже оказанную услугу".
Раньше были популярны сюжеты про супергероев, когда человек просто оказывался в нужное время в нужном месте и повествование завершалось всеобщей вечеринкой. В умах форсировался устойчивый паттерн, что этот хэппи-энд будет длиться вечно.
В эпоху постмодернизма свершения оцениваются через призму контекста и его смена легко меняет плюс на минус. Супергерои дряхлеют и деградируют. А некогда благодарная публика уже ни чего не помнит, давно переключив внимание на новые сюжеты.
Ваши наблюдения выстроены в таком ключе, что давят на самооценку. Для школьников такой прием звучит на грани фола. Для людей постарше - как минимум странным. Поэтому в качестве провокации статья конечно удалась, не оставив никого равнодушным и собрав кучу комментариев.
Есть такой тип учителей, что-то типа снаряда в спортзале. Ну скажем, турника. Его вопросы не оставляют ни кого равнодушными и ученики готовы перерыть полбиблиотеки в поисках аргументов, чтобы показать своё превосходство. Он справляется со своей работой когда ученик выходит с ощущением, что смог превзойти своего учителя, доказав неправоту и разгромив того в пух и прах. Количество минусов с одной стороны, и комментариев к статье с другой, думаю, хороший тому пример).
Виден математический подход. Сперва решать задачу по максимуму в общем виде. Когда же решение становится сложным, начинаем срезать углы, делая подстановки для интересующих нас частных случаев.
Мне кажется преждевременная генерализация играет тут плохую шутку, добавляя по сути не нужные детали и ограничения. Это вынудило потом добавлять в реализацию код, выглядящий там как
костылине соответствуюший основной иде.Канбан минимизирует время отклика (lead time) по отдельным задачам - как правило самым приоритетным. Поэтому здесь задачи представляют собой какой-то осмысленный кусок, который есть смысл доставлять. Кодревью ни куда не поставляется - это просто операция.
Один из законов управления гласит, что усиление контроля ведёт к снижению теоретической производительности. Можно заводить такси на каждый чих, но накладные расходы на их менеджмент сведут всю пользу на нет.
Видимо data-driven UI это то, что нельзя просто так взять и внедрить со старта - компания до него может только дорасти. Можно использовать как маркер уровня технической зрелости. Сам же подход стар как мир: TCL/TK, UIML, XAML, XUL, BEMJSON, QML..
Версионирование API в заголовке или в пути это давняя дилемма. Интересно, из каких соображений для v3 выбирали заголовки, и из каких потом от них отказались?
Есть кусок работы, есть достаточно автономная команда и нужен результат. Кажется в советское время это называлось бригадный подряд.
Над уровнем архитектуры приложений находится архитектура систем. Но если вы хотите, чтобы системы в вашей организации строились по каким-то общим принципам, то получается нужна архитектура архитектур, модели моделей (метамодели) и все вот это. Довольно абстрактная деятельность, которая находится на три уровня абстракции выше конечной разработки, однако может иметь там самые серьезные последствия - как в плане побед, так и ошибок. Результаты такой деятельности в разработку падают в виде спецификаций, бест практик, запросов на изменения и т.п. Часто проблемы возникают из-за того, что архитекторы коммуницируют это в виде экшен айтемов - что нужно сделать, пропуская предпосылки - для чего. В итоге разработка действительно не понимает для чего все это нужно и потом всячески сопротивляется.
Мне бы тоже хотелось видеть конкретные примеры, чем они занимаются. Хотя фокус статьи на другом, поэтому не вижу смысла критиковать автора, она рассказала про свой кусочек работы.
"Дичь" это субъективная оценка. Во многом она зависит от прошлого опыта и текущих скиллов. Люди совершенно разные. Кто-то понимает и готов с радостью подхватывать изменения, другие наоборот - не понимают, или не видят для себя лично пользы, или видят угрозу и тормозят. Со всем этим приходится работать.
Через сопутствующее мобильное приложение, с кучей разных полезных функций. Например функция помощи при аварии с поиском ближайшего автосервиса предлагает заранее ввести свои данные, такие как ФИО, SSN, Driver license и т.п.
Здесь как с уборкой - в теории всем нравится когда удобно и красиво как в пятизвёздочном отеле, но в реальности менять своих привычки бросать носки куда попало и разгребать авгиевы конюшни за другими ни кто не стремится.
У меня по опыту внедрение новых технологий и полезных инженерных практик, по большому счету это всегда боль. Причем менеджмент с их сроками и бюджетами здесь полбеды. Много отрицания идёт от самих же инженеров - людям удобнее и кажется безопаснее работать так, как они привыкли.
Для того, чтобы изменить что-то технически, сперва приходится менять самих людей: либо учить и воспитывать пока новые подходы не войдут в привычку, либо в прямом смысле. Банальный пример - кодстайл. На одном из проектов внедрение заняло больше года, т.к. взрослые дядьки на серьезных щщах ни как не могли договориться относительно отступов: табы или пробелы.
"Жандарм – это порядок, а порядок никто не любит". В разных компаниях реальные функции и полномочия скрам-мастера сильно разнятся, поэтому без знания местных особенностей обсуждение нужен/не нужен это холивар. Кроме того, как у любых руководителей, многое определяется сугубо личными качествами и опытом.
Современное айти это командная работа. Командная работа это работа с людьми, а людям свойственно проявлять эмоции. Позитивные, негативые - разные. Умение их контролировать это тоже навык.
Источником раздражения не обязательно будет начальство. Много стресса доставляют новички у которых просто нет ещё таких навыков. Эпизодически коллеги вашего же уровня. Дальше - люди со стороны, заказчики, подрядчики или допустим пользователи вашего продукта.
Стрессовой ситуация может стать и по личным причинам - плохое настроение, кто-то наступил на ногу в метро, проблемы с близкими, политика, погода, усталость. Некоторые болезненно относятся к критике, пусть даже самой конструктивной. Некоторые видят негатив даже в самых нейтральных вещах, как вопрос о стрессоустойчивости.
Если у человек не умеет выключаться из своих эмоций это может протекать в работу и сказываться на результатах. Поэтому вопрос в принципе уместный. Просто не факт, что для получения ответа его нужно задавать вот так в лоб.