С первым пунктом я скорее не согласен. Спрос на IT никуда не денется в ближайшем будущем. И пандемия — точно не причина, которая этот спрос сильно сократит. Обанкротятся одни компании, на их месте вырастут другие. И надо быть совсем балластом, чтобы не найти работу в течение пары месяцев — это показатель что с вашими компетенциями что-то не так и это надо исправлять.
А вот со вторым — вполне допускаю что может быть. Даже учитывая что ваш единичный случай ничего не доказывает. Возможно вас было дешевле лечить чем искать замену, возможно был специальный фонд под это дело, возможны варианты, короче… И тем не менее, бывают компании, которые ценят работников. Потому что это дешевле, чем нанимать каждый раз новых. И они предлагают компромисс, даже если это не их вина в этом факапе.
Совсем просто: Почему работника должна волновать бухгалтерия работодателя? Есть деньги — работаем, нет денег — идём к следующему. Его офис находится прямо через дорогу, а все работодатели примерно одинаковы. Рынок довольно конкурентный, недостатка на спрос в IT нет.
Я, например, ни разу не видел, когда работнику начинают платить больше только потому что например "жкх выкатили долг, жена отсудила алименты и теперь надо больше денег". Обычно для повышения зарплаты имеются причины не связанные с личной бухгалтерией работника.
Немного сложнее: Работники отдают часть своих заработанных денег не просто так. В примере выше работодатель получает с каждого 20% хотя по факту — гораздо больше. Работники "платят" каждый месяц по 20 рублей за то, что работодатель принимает на себя риски. Иначе они не работали бы на работодателя, а основали бы свои собственные компании и оставили бы этого работодателя без клиентов и без штанов.
Поэтому ситуация, когда реализованные риски компания пытается переложить обратно на работников — очень нехорошая прежде всего для работодателя. Это "сигнал" работникам — "страховую премию" работодатель берет, но от рисков работников так и не защищает. А если при этом компания и правда может развалиться — то это тем более плохой знак. Совет директоров, выходит, вместо хеджирования рисков, деньги просто растратил. Что будет когда тряхнет посильнее? Так, что нельзя будет переложить ответственность на работников?
Это не равнозначная ситуация. Равнозначной она будет, если бригада окажется запертой в квартире, например в результате обрушения лестничного пролёта. Достать оттуда вы их не можете.
Вот в такой ситуации можно рассмотреть, стоит ли им в таких условиях ещё и работать.
Когда на компанию внезапно сваливается прибыль, то они как-то не спешат делиться ею с работниками. Я имею в виду действительно делиться, а не выдавать подачки. А теперь, когда возникли неиллюзорные риски убытков, они вдруг вспомнили что "все в одной лодке".
Возникни у компании, в которой я работаю просьбы выйти бесплатно, я, пожалуй бы начал рассылать резюме в тот же день. Потому что вывода тут напрашивается два:
у компании нет денег, чтобы заплатить мне
меня держат за идиота
Возможно я неправ, тут каждый сделает свой вывод исходя из своей личной ситуации. Кто-то выйдет за обещание возмещения и получит премию/повышение/отпускные в итоге. А кто-то — не получит. Кого-то, я, уверен, даже согкратят не смотря на работу в поте лица за бесплатно. А кто-то найдёт новую работу.
Скорее всего, они неплохо маскируются под обычный сид, наверняка даже раздают пиратский контент, поэтому, рассуждая теоретически, скорее всего не удастся отличить шпионов от обычных сидов. Поэтому более жизнеспособная стратегия — маскироваться самому.
Но разве классическая модель с $40 за установку и абонентской платой в $20/мес с патчами раз в полгода лучше? Тут хотя бы есть возможность попробовать...
Да какие тут оскорбления, просто метафора очень уж в кассу пришлась.
По правде говоря, эта фраза не столько про "героя" (т.е. того кто спас положение), сколько про его руководство. Или про ситуацию в целом. А для "героя" подобная ситуация, с точки зрения его карьеры — только на пользу. Ведь это — лишнее достижение, за которую премию дадут. Или станет ярким пунктом годового ревью и основанием для повышения. Или даже отличной строчкой в резюме.
С точки зрения же бизнеса как процесса, ситуаций, которые требуют "героизма" всё же лучше избегать. Ведь они увеличивают неопределенность, что ведёт к убыткам.
Как правило, сотрудник тупит на контексте. Он не понимает, с чего начать. Не знает, что в окружении задачи вообще есть, будь то фреймворк или предметная область.
Мой опыт это утверждение не подтверждает. Если сотрудник (здесь и далее имею ввиду исключительно разработчика) "тупит" из-за того что не может (не знает как) начать, то он потеряет пару дней в самом худшем случае. Достаточно просто ежедневно отслеживать прогресс по каждой задаче. Да, тот самый пресловутый скрам дейли митинг сэкономит вам кучу человеко-часов/дней/недель "тупки", потому что если человеку уже второй день нечего объективно сказать по задаче, которая в прогрессе, то у него там затык, надо звать более квалифицированного на помощь.
Гораздо хуже, если он начал кое-как. Использовал неэффективный дизайн, требующий большого количества костылей, или если он (или кто-то другой в цепочке) истолковал постановку задачи неверно. Тогда дневные отчёты выглядят великолепно, код добавляется, документация пишется, даже уточняются мелкие детали. Всё это очень усыпляет внимание контроля. И чаще всего только на завершающих шагах вдруг внезапно выясняется, что делалось совсем не то, что было нужно!.. Поэтому большая часть в лучшем случае летит в помойку, а в худшем — её следы остаются жить в проекте навсегда и конфузят исполнителей следующих задач.
Вообще-то я имел в виду, что иногда даже просто проапгрейдить мажорную версию драйвера монги может стать той ещё занозой в…
Впрочем, даже рассматривая ваш тезис — нам тут пару месяцев назад топы спустили сверху резолюцию, что саппорт монги стоит слишком дорого, поэтому ее заменяют на более дешевое решение. С монгой не совместимое от слова совсем.
Думаю, мы не первые, кому решение спускают сверху. Всего несколько лет назад проприеритарные реляционные базы (читай оракл) массово меняли на открытые и NoSql решения.
Ну и какое решение будет перевести проще — с выделеным слоем доступа к данным или то где каждый класс очень по креативному работает с хранилищем?
Коробочные решения, например, часто расширяют требования до поддержки ещё одной базы данных. А всякие кеши и очереди сообщений и вовсе меняются как перчатки. Мне сложно представить, как это всё отслеживать без слоя доступа к данным в модели ActiveRecord
Так в примере выше, rsync и говорил про high-coupling. Якобы метод который и меняет бизнес-состояние и сам себя в базу пишет (вполне конкретную) — это хороший дизайн.
То есть это не просто Active-Record, а ещё и прибитая гвоздями к конкретной схеме конкретной базе конкретного драйвера.
С первым пунктом я скорее не согласен. Спрос на IT никуда не денется в ближайшем будущем. И пандемия — точно не причина, которая этот спрос сильно сократит. Обанкротятся одни компании, на их месте вырастут другие. И надо быть совсем балластом, чтобы не найти работу в течение пары месяцев — это показатель что с вашими компетенциями что-то не так и это надо исправлять.
А вот со вторым — вполне допускаю что может быть. Даже учитывая что ваш единичный случай ничего не доказывает. Возможно вас было дешевле лечить чем искать замену, возможно был специальный фонд под это дело, возможны варианты, короче… И тем не менее, бывают компании, которые ценят работников. Потому что это дешевле, чем нанимать каждый раз новых. И они предлагают компромисс, даже если это не их вина в этом факапе.
Совсем просто: Почему работника должна волновать бухгалтерия работодателя? Есть деньги — работаем, нет денег — идём к следующему. Его офис находится прямо через дорогу, а все работодатели примерно одинаковы. Рынок довольно конкурентный, недостатка на спрос в IT нет.
Я, например, ни разу не видел, когда работнику начинают платить больше только потому что например "жкх выкатили долг, жена отсудила алименты и теперь надо больше денег". Обычно для повышения зарплаты имеются причины не связанные с личной бухгалтерией работника.
Немного сложнее: Работники отдают часть своих заработанных денег не просто так. В примере выше работодатель получает с каждого 20% хотя по факту — гораздо больше. Работники "платят" каждый месяц по 20 рублей за то, что работодатель принимает на себя риски. Иначе они не работали бы на работодателя, а основали бы свои собственные компании и оставили бы этого работодателя без клиентов и без штанов.
Поэтому ситуация, когда реализованные риски компания пытается переложить обратно на работников — очень нехорошая прежде всего для работодателя. Это "сигнал" работникам — "страховую премию" работодатель берет, но от рисков работников так и не защищает. А если при этом компания и правда может развалиться — то это тем более плохой знак. Совет директоров, выходит, вместо хеджирования рисков, деньги просто растратил. Что будет когда тряхнет посильнее? Так, что нельзя будет переложить ответственность на работников?
В сша тоже самое. Всех перевели на удалёнку. У кого нет оборудованного рабочего места выдали рабочее оборудование — доп.дисплеи или десктоп целиком
Это не равнозначная ситуация. Равнозначной она будет, если бригада окажется запертой в квартире, например в результате обрушения лестничного пролёта. Достать оттуда вы их не можете.
Вот в такой ситуации можно рассмотреть, стоит ли им в таких условиях ещё и работать.
Какой-то странный призыв.
Когда на компанию внезапно сваливается прибыль, то они как-то не спешат делиться ею с работниками. Я имею в виду действительно делиться, а не выдавать подачки. А теперь, когда возникли неиллюзорные риски убытков, они вдруг вспомнили что "все в одной лодке".
Возникни у компании, в которой я работаю просьбы выйти бесплатно, я, пожалуй бы начал рассылать резюме в тот же день. Потому что вывода тут напрашивается два:
Возможно я неправ, тут каждый сделает свой вывод исходя из своей личной ситуации. Кто-то выйдет за обещание возмещения и получит премию/повышение/отпускные в итоге. А кто-то — не получит. Кого-то, я, уверен, даже согкратят не смотря на работу в поте лица за бесплатно. А кто-то найдёт новую работу.
Статья наглядно показывает что получается, когда вместо квалифицированного постановщика задач программистом командуют бухгалтера
Скорее всего, они неплохо маскируются под обычный сид, наверняка даже раздают пиратский контент, поэтому, рассуждая теоретически, скорее всего не удастся отличить шпионов от обычных сидов. Поэтому более жизнеспособная стратегия — маскироваться самому.
Выходит, что антиабузные только если абуза вне российского правового поля
Но разве классическая модель с $40 за установку и абонентской платой в $20/мес с патчами раз в полгода лучше? Тут хотя бы есть возможность попробовать...
А шутка в том, что пользователи, которые не готовы делиться личной информацией, отказались от участия в опросе
Да какие тут оскорбления, просто метафора очень уж в кассу пришлась.
По правде говоря, эта фраза не столько про "героя" (т.е. того кто спас положение), сколько про его руководство. Или про ситуацию в целом. А для "героя" подобная ситуация, с точки зрения его карьеры — только на пользу. Ведь это — лишнее достижение, за которую премию дадут. Или станет ярким пунктом годового ревью и основанием для повышения. Или даже отличной строчкой в резюме.
С точки зрения же бизнеса как процесса, ситуаций, которые требуют "героизма" всё же лучше избегать. Ведь они увеличивают неопределенность, что ведёт к убыткам.
Звучит прямо как слабоумие и отвага.
Мой опыт это утверждение не подтверждает. Если сотрудник (здесь и далее имею ввиду исключительно разработчика) "тупит" из-за того что не может (не знает как) начать, то он потеряет пару дней в самом худшем случае. Достаточно просто ежедневно отслеживать прогресс по каждой задаче. Да, тот самый пресловутый скрам дейли митинг сэкономит вам кучу человеко-часов/дней/недель "тупки", потому что если человеку уже второй день нечего объективно сказать по задаче, которая в прогрессе, то у него там затык, надо звать более квалифицированного на помощь.
Гораздо хуже, если он начал кое-как. Использовал неэффективный дизайн, требующий большого количества костылей, или если он (или кто-то другой в цепочке) истолковал постановку задачи неверно. Тогда дневные отчёты выглядят великолепно, код добавляется, документация пишется, даже уточняются мелкие детали. Всё это очень усыпляет внимание контроля. И чаще всего только на завершающих шагах вдруг внезапно выясняется, что делалось совсем не то, что было нужно!.. Поэтому большая часть в лучшем случае летит в помойку, а в худшем — её следы остаются жить в проекте навсегда и конфузят исполнителей следующих задач.
А я вот понял, что мы просто из разных вселенных.
Вообще-то я имел в виду, что иногда даже просто проапгрейдить мажорную версию драйвера монги может стать той ещё занозой в…
Впрочем, даже рассматривая ваш тезис — нам тут пару месяцев назад топы спустили сверху резолюцию, что саппорт монги стоит слишком дорого, поэтому ее заменяют на более дешевое решение. С монгой не совместимое от слова совсем.
Думаю, мы не первые, кому решение спускают сверху. Всего несколько лет назад проприеритарные реляционные базы (читай оракл) массово меняли на открытые и NoSql решения.
Ну и какое решение будет перевести проще — с выделеным слоем доступа к данным или то где каждый класс очень по креативному работает с хранилищем?
Коробочные решения, например, часто расширяют требования до поддержки ещё одной базы данных. А всякие кеши и очереди сообщений и вовсе меняются как перчатки. Мне сложно представить, как это всё отслеживать без слоя доступа к данным в модели ActiveRecord
Слишком много интеграционных тестов вот и гоняются по 2 часа.
QA "пишет" тесты используя свой инструментарий. Ну например SOA Test.
А в коде разработчика QA делать нечего. Как можно аудировать код, в котором ничего не понимаешь?
Нафиг тогда в такой вселенной нужен тогда QA вообще?
В реальном мире QA не верит разработчику и покрывает требования (а не код) независимо.
Так в примере выше, rsync и говорил про high-coupling. Якобы метод который и меняет бизнес-состояние и сам себя в базу пишет (вполне конкретную) — это хороший дизайн.
То есть это не просто Active-Record, а ещё и прибитая гвоздями к конкретной схеме конкретной базе конкретного драйвера.
Если там в цикле перебирается все строки таблицы вместо запроса с группировкой и/или аггрегацией, то DBA не спасёт.