Давно не видел сокращения UTP, мозг услужливо подменил системе визуального распознавания UTP на UDP: ткнул ссылку посмотреть как обжимается, UDP :) уже хотел попкорн готовить

Очевидно же, в статье написано что в рейтинге стран с наибольшей занятостью удаленно на полный день первое место занимает Россия — это обобщение не имеющее права на существование. Говоря о стране мы подразумеваем и работодателей и наемных работников. Опрос же был только среди наемных работников. Тут я и возразил.

Охотно верю, но в статье не клеится или с переводом или с математикой :)

Кстати, вероятно, много ответивших из России работает по фрилансу или на дядей Сэмов. Это тогда никак не связано с Российскими работодателями.
Зная, что на Украине полно разрабов, где они в списке? загадка…

31,8% работают всегда из офиса, 35,1% работают из дома несколько дней в месяц( обе цифры из диаграммы). Откуда 68,2% процента работающих хотя бы несколько дней в неделю из дома, согласно тексту?

Кстати, у *nix при всех его субъективных недостатка, которые, на мой взгляд, есть его достоинства есть одна черта, что поднимает его выше windows. От версии к версии парадигма *nix остается одной и той же, от одного уровня абстракции поднимаемся к другому, следуя принципам наследования объектов. Проще говоря, могут меняться частности, названия демонов, команд итд. Но все остается логичным и понятным. Если что-то не знакомо всегда через man можно все выудить и во всем разобраться. С первого знакомства с Unix и до сих пор это работает. Google почти так же хорош для поиска ;) как man для понимания *nix.

Почти 18 лет пользуюсь то HP-UX, то разными linux дистрибутивами, то вот сейчас на MacOS, и по-прежнему на Linux. Это для меня инструменты, можно сравнить их с молотком. Однажды научившись ими пользоваться я все еще хорошо владею ими. Как и молотком:) можно наверно сделать более совершенный инструмент, но не нужно. Он совершенен в своем несовершенстве.

Это частое подстраивание терминологии под цель. Предлагаю шире смотреть на задачу ускорения цепочки создания ценности.
DevOps это подход позволяющий ускорить появление ценности в продуктиве. Т.е. говорим о сокращении времени поставки.
Факт, что без автоматизации полноценного DevOps не будет. Но по многим оценкам автоматизация в DevOps — вершина айсберга. Еще нужно, построить коммуникации и процессы, может быть, сменить/адаптировать архитектуру приложений, и самое главное, DevOps о другом мышлении и другом отношении к работе. Здесь больше всего граблей.

Господи, а cp rm и иже с ними за что? Руками их набивать быстрее, спутать невозможно, сплошной профит.
Или copy и remove что-то исправят?
Ну так пропишите себе алиас и не парьтесь:). Видимо вы в sh скорее гость, чем завсегдатай.

Тогда я бы хотел ее увидеть:)

Ну кстати да, тут разные уровни и виды тестирования в кучу. Боюсь что проблема описанная в статье происходит от слабого понимания темы.

Плюс поставить не могу, но хотел бы.
Статья поначалу затянула, а в конце удивила.
Возникло ощущение, что все в кашу. Обычно регрессионное тестирование и ручное происходят из единого описания сценариев тестирования. Тут нельзя спутать, какой сценарий не прошел. Если подходить системно, то картинка вся должна быть на виду. Автотест не прошел? Повторяем сценарий руками. По контексту ошибки и ручного прогона поймем что делать дальше.
А если как-то появилась толпа автотестов и они с ручным тестированием непонятно как пересекаются, то пора задуматься об управлении тестированием как процессе.

Я не удержался и ответил на статью вполсилы от ее не очень позитивной энергетики и меня минуснули. Делайте выводы

Поясню, было бы интереснее и познавательнее увидеть здесь еще и авторские шаги навстречу продавцам в направление решения этой проблемы, системно, а не рецепт поведения продавца в присутствии высшего существа.

Ну, скажем так, в статье все поголовно продажники плохи, разработчики наши все хороши (кроме бангладешцев), и непогрешимы.
Никакого анализа нет, попытки понять ту сторону нет. Только требования, я бы даже сказал, топанье ножкой.
Я ничего не пропустил?

Злой комментарий, на надменный пост.
Впрочем, с постом не согласен больше, если автор остальных считает идиотами по признаку профессии, то тут явно есть какое-то недоразумение.
А тот факт, что нет сильного представителя со стороны разработчика, кто смог бы настроить взаимодействие с продажами говорит, мне лично, что ситуация устраивает. Ну то есть, мы их, продажников не любим, но как с нами разговаривать, мы не скажем и будем издеваться.
Хотя нет, вот пост написан, но все равно с издевкой, и надменно.
В разработке мы все пришли к тому чтобы UI был прекрасен, и стали на него обращать много внимания. Может быть нужно чтобы наш межличностный интерфейс тоже стал дружелюбнее?

Не логично, что такому сотруднику мешает закончить рабочий день выполнив последний заказ, скажем, в 18:05 и потом поехать к еще одному клиенту и с помощью оборудования компании и её материалов подхалтурить?

Я вижу просто поле для махинаций. Будь я таки типом, как вы описываете в статье, я б нагадил где-то еще. То есть нужен тотальный контроль получается? Не находите?

Один мой коллега точно отметил, что основное в профессии консультанта это слушать и слышать. Сам стараюсь следовать принципу «не навреди».

Вообще, я бы отнес описанное в статье к вопросу профессионализма, часто не хватает именно такого отношения, что в жизни, что на работе, что на Хабре.

Посмотрел чем занимается компания, это еще хуже чем кривые KPI и страшно формальные бизнес процессы.
Это мониторинг экрана и кейлоггер.

Никогда с этим не сталкивался в жизни и дай бог убережет судьба. Понятно что почта и трафик пишутся, но чтоб контролировать открытые окна… какая-то душная атмосфера получается в такой компании.

Так что это не детское отношение, а просто притягивание за уши.