Comments 33
«Сотрудник может быть отличным разработчиком Java и лучшим в мире архитектором масштабируемых систем, но если он демотивирует или мешает остальной части команды, от него нужно избавляться как от сорняка. „
Интересно, как именно демотивирует. Просто так, без причины? Люди бывают недовольны из-за косяков в менеджменте, например.
Интересно, как именно демотивирует. Просто так, без причины? Люди бывают недовольны из-за косяков в менеджменте, например.
Бывают люди, разговор с которыми — как боксерский поединок: поговорил минут двадцать и часа полтора потом нужно отлеживаться. Бывает, что лучше весь день по стаковерфлоу луркать, чем просто подойти к соседнему столу и спросить. И часто такие персонажи довольно сильны в своих компетенциях, но команду они замедляют в итоге, сидят эдакими буками, загородившись от всего мира кучей мониторов, и тучи с молниями над ними. Сталкивался не раз, и каждый раз, увольнение такого сотрудника — почти единственный выход, не смотря на все его регалии и скилы.
Интересно. А вы не пробовали у них спрашивать о причинах? Я вот сам такой иногда бываю, достают вопросами, на которые можно в гугле ответ найти.
Не, не пробовали. Сразу увольняли и все. Конечно, в гугле ведь можно найти все ответы, особенно на вопросы, касающиеся кода, написанного этим конкретным индивидом. Сарказм.
Если серьезно, то расставание с толковым инженером — всегда стресс для команды и менеджеров (которые понимают, насколько тяжело этого человека будет заменить), и конечно, такой ситуации стараются избежать, но воспитывать взрослых людей — дело совсем неблагодарное. Есть люди, которые в принципе органически не способны работать в команде. И если вы «таким бываете» — это повод задуматься о.
Если серьезно, то расставание с толковым инженером — всегда стресс для команды и менеджеров (которые понимают, насколько тяжело этого человека будет заменить), и конечно, такой ситуации стараются избежать, но воспитывать взрослых людей — дело совсем неблагодарное. Есть люди, которые в принципе органически не способны работать в команде. И если вы «таким бываете» — это повод задуматься о.
Люди бывают по-природе токсичны. Токсин отравляет всю компанию. Единственный выход – нейтрализовать токсин. Иногда удаётся это сделать, правильно перекалибровав источник токсина. В 80% случаев увольнение есть единый выход.
Хреновый из вас боксер. Всегда считал, что стрессоустойчивость необходимое качество для руководителя.
Причины такого поведения нужно обязательно исследовать, а не рубить с плеча. Проблема может быть не в индивиде, а в организации.
Причины такого поведения нужно обязательно исследовать, а не рубить с плеча. Проблема может быть не в индивиде, а в организации.
У нас была точно такая же ситуация, и я рад сейчас что тот человек ушел, спасибо руководителю что его уволили. Задача руководителя это не нянчится с людьми а наладить процесс работы.
Что там в вики про организационное поведение написано:
Это соответствует первому комментарию relgames.
Все планируемые и осуществляемые действия индивида, их результаты, также выражают суть организации.
Это соответствует первому комментарию relgames.
Знаете, я вообще не боксер. Мне больше нравится быть эльфом из страны радуги и розовых пони. И про эту вашу ярлычную «стрессоустойчивость» вы лучше расскажите на тренинге для менеджеров в Макдональдс, а я продолжу искренне и сильно переживать за то, что происходит в команде и с проектом. А реально хороших инженеров, работа с которыми приносит удовольствие, мне (слава Глобу!) попадалось больше, чем неисправимых бук (хотя конечно их также очень мало в общей массе). Вот с ними я и предпочитаю работать.
И часто такие персонажи довольно сильны в своих компетенциях, но команду они замедляют в итогеЯ бы попробовал такого изолировать на отдельный проект — команда не будет ему мешать, а он не будет замедлять команду.
del
Коллектив вообще любит середнячков, а слишком глупых и слишком умных отторгает. Но лично я, как разработчик, предпочел бы действовать иначе. Если у меня случается батхерт от того, что кто-то разбирается в моем предмете лучше меня (и нагло указывает на это), то я предпочту воспринять это как вызов и поднять свою квалификацию. Можно, конечно, устранить «обидчика» и расслабиться, но тогда пропадает хороший пинок к собственному развитию.
Подчеркну, что это мнение разработчика. Менеджеру, наверное, больше по душе набор покладистых середняков.
Подчеркну, что это мнение разработчика. Менеджеру, наверное, больше по душе набор покладистых середняков.
Ага, это как в первой части фильма герой огребает от злодея, потом долго и упорно изучает кунг-фу, и в конце с блеском всем мстит! Но жизнь — это не кино, и простое человеческое общение — немаловажная часть командной работы. Если этот скил не прокачан (причем не нужно для этого посещать курсы красноречия, достаточно не огрызаться злобно на любой раздражитель) — это чаще оказывается вашей проблемой.
Коллектив отторгает того, кто не хочет считаться с правилами коллектива. Не имеет значения, глупый они или умный, в этом контексте.
Менеджеру по душе команда высококлассных специалистов своего дела.
Но главное — именно команда. Т.е. когда недостатки одного умело прикрыты достоинствами другого.
Это как кластер серверов: есть несколько нод, хотя можно было бы поставить одну помощнее.
Не нужно же объяснять, какое решение надежнее и масштабируемее.
Менеджеру по душе команда высококлассных специалистов своего дела.
Но главное — именно команда. Т.е. когда недостатки одного умело прикрыты достоинствами другого.
Это как кластер серверов: есть несколько нод, хотя можно было бы поставить одну помощнее.
Не нужно же объяснять, какое решение надежнее и масштабируемее.
Речь вроде шла немножко не о том. Работает со мной такой кадр, которого спросишь «не встречался ли ты с такой проблемой», он не просто ответит «загугли», он встанет за спиной и будет давать рекомендации в стиле капитана Очевидность, и попробуй от него отвязаться! При том, что не сказать даже, что он такой прямо высококлассный специалист.
Немного оффтоп. :-)
Если такой скилл — «гуглить».
Некоторые люди находят таким способом то, что другие найти почему-то не могут.
Потому что чтобы правильно написать поисковый запрос, нужно немного понимать принципы, по которым строится поисковая выборка.
И это скилл также нужно прокачивать, объясняя, почему один запрос лучше другого.
Если такой скилл — «гуглить».
Некоторые люди находят таким способом то, что другие найти почему-то не могут.
Потому что чтобы правильно написать поисковый запрос, нужно немного понимать принципы, по которым строится поисковая выборка.
И это скилл также нужно прокачивать, объясняя, почему один запрос лучше другого.
А иногда есть сотрудники, которые по тысячу раз задают один и тот же вопрос и не учатся на своих ошибках.
Если человек тупой, то возникает вопрос: как он вообще попал в вашу команду? Для отсева некомпетентных тугодумов и существуют всякие технические интервью и тестовые задания. А иногда, даже умнейшие люди начинают тупить в каких-то смежных областях, просто потому, что не успели подстроиться под задачу. И к этому тоже стоит уметь относиться с пониманием.
Вероятно, речь идет о «диве» — спецу со «звездной болезнью», не способным работать с коллективом. Хотя и косяк менеджмента (он платит зарплату, между прочим) не является оправданием саботажа. То, что тут мягко названо демотивацией и помехой команде.
Довольно сильно. Говорю с позиции как раз такого сотрудника. Скорее всего, это часто эмоционально неуравновешенные люди с определенной долей инфантилизма. Легко раздражаются в случае активного согласия или малейшего несогласия и начинают саркастически перебивать, унижать собеседника. Исправление зависит от степени испорченности и на мой взгляд достигается чтением книг про переговоры. Как-то так )
Например, путём постоянной критики унаследованных, созданных и создаваемых решений. Скажем, в плане отказоустойчивости. Бизнес взвесил риски и стоимости разных альтернатив, принял решение о внедрении одной из них, о такой человек постоянно публично напоминает о том, что считает принятое решение ошибкой. Может он и прав, но способ донести своё мнение выбрал неудачный.
UFO just landed and posted this here
Так, если у вас есть данные формата JSON, то хранилище документов будет лучшим решением.
Слишком категорично, чтобы быть правдой. Смотреть надо не на формат, а на роль данных, на типовые операции с ними. Преобразование из формата в формат как правило дешево при записи и окончательном выводе, а сама работа с данными может быть очень дорогой при миллионах и миллиардах итераций при неудачном выборе формата хранения.
Посоветуйте, пожалуйста, какую-нибудь хорошую книгу по масштабируемости и высоким нагрузкам?
Многие продукты все еще полагаются на реляционную базу данных… Подобное «решение» в конечном итоге приведет к увеличению расходов на транзакции и большему урону в случае сбоя по мере роста компании.
А ничего так, что в не реалицонных БД с этими транзакциями всё совсем плохо? Как вы будете сохранять консистентность? А CAP теорема?
Короче trade-off. Чудес не бывает, либо вам надёжно (с гарантиями) и медленно или вам быстро и ненадёжно (без гарантий). И да масштабирование в ширь оно так же происходит с потерями т.е. это не silver bullet.
3. Вертикальное масштабирование вместо распределения нагрузки
Scaling Up Instead of Out
сегментирования клиентов по множеству небольших баз данных — шардирование же, горизонтальное масштабирование
Зря так про Титаник. Он специально был так спроектирован. Так как если бы переборки были закрыты он бы очень быстро перевернулся на нос и затонул. Куда быстрее, чем в реальности. Подобные случаи, с другими кораблями, упоминались в литературе.
Sign up to leave a comment.
10 главных ошибок масштабирования систем