Привет всем.
Хочу затронуть тонкую тему моббинга на рабочем месте.
Оказался в ситуации, который просто не могу найти логического объяснения, но постараюсь не проявлять эмоций.
И так, однажды уже писал тут о фирме (европейскоая организация с формой работы консультантом), в которую я пришел примерно год назад.
Началось тоже странно — дали читать доку, а источники к ней не давали.
С ужасом сообщаю что воз и ныне там!
За это время пришлось переписать самому кучу кода, но до старой программы, работающей на сервере, так и не подпустили.
Давление, просьбы и жалобы к руководству не помогли. Мантра такая, что человека ответственного за все
в этом отделе руководство поддерживает во всем. Аргумент — человек 15 лет на фирме и знает больше всех.
Спорить с ним по работе не позволяют. Как только рабочие моменты возникают и нужно изменить что-то или получить данные или доступ — начальники бегут разбираться вниз и приговаривают "не тогайте ни в чем не виновного мистера Х!". Вплоть до смешного. Человек Х типичный манипулятор. Оказалось так же, что это уже не первый случай со мной. В общем, шансов сказать такому что то конструктивное по его коду, или просто необходимость в обене информации, вызывает массу волнений, все делается через вышестоящее начальство.
В моем примере все попытки получить код разбивались о предложение почитать доку
еще разок. И ладно бы, прочитали и проверили как-нибудь. Так нет, иди читай, и все!
Аргумент не дать код однако — ловля на мелких деталях реализации в письмах с
СС начальнику. Например, число какое-то не может быть 55, а должно быть только 56.
Все, начальнику достаточно и он удостоверен, что дока не читана. Класс, конечно.
Думаю что со стороны такая ситуация выглядит просто непонятной.
Мне это тоже не понятно. Я извиняюсь.
Как я до сих пор ухитрился продержаться — программировал с нуля, предоставляя результаты.
Но это были лишь приготовления, как например конверторы данных, поиск информации — такие небольшие приложения
для главной задачи. Теперь пришло время когда надо запускать главную прогу.
И все. Дело стало. Результата точно не получится, если не переписать прогу по доке с нуля.
Не успею.
Но вопрос не в этом.
Вопрос в том, как все это время использовалась система в которой мы работаем для нацеленного моббинга.
Это может быть отдельная история, но я попытаюсь собрать это тут вместе с описанием общей ситуации.
И так, система Linux, несколько виртуальных машин, причем все достаточно хаотично разбросанная по виртуалкам, так что даже версия Linux на всех машинах разная, так же как и версииосновных библиотек.
Группы юзеров с ограничением на некоторые ресурсы там и сям. Система состоит из
ПС разработки и операционального процессирования.
Есть SVN, но используется он только для хранения одной последней "хорошей"
версии! Источниками народ обменивается просто положив их в заранее оговоренную директорию.
С неоторых пор я стал делать чексуму на куски моего кода. И что я увидел, я не поверил своим глазам.
Чексумма изменялась несколько раз, оставляя ту же дату изменения файла!
Похожее ожидало меня и с группами. Мое имя в группе с доступом к библиотекам на продакшене было нечаянно некоектно и не совпадало с моим общим linux именем. Что приводило к тому, что мне пришлось завести кастом
установку на многие тулзы. Причем с достаточно ограниченными правами моего юзера в системе в общем.
Надо добавить, что у человека Х права скорее всего административные, что он и демонстрирует посылая периодически обзоры на всю систему нам всем, с указаниями изменений, например. Это не считается однако официальным администрированием, и начальник до сих пор не верит в особые права особым юзерам. Поразительный факт, как мне кажется, ибо скорее всего человек работает таким образом не один, а хорошо организован с другими. Что вполне логично имея 15 летний стаж. Место денежное, и очень нестабильное, с огромной иерархией и международными интригами.
Понимаю, что тикать оттуда нужно.
Но появился спортивный интерес и страх, что такие дела могут быть и в других конторах.
Поэтому нужно бы разобраться что делать в таких ситуациях.
Собственно вопрос:
Народ, подскажите что кроме чексуммы нужно было делать в такой ситуации?
Как защищать себя от неконтролируемого удаления файлов в linuxe.
У меня недельные бакапы, помогает.
Теперь у меня кроме чексуммы имеются еще и истории директорий.
Еще я слышал люди пишут скрипты, которые отправляют письмо автору кода в случае его изменения.
А что еще?
Подскадите, есть ли общие тактики, с которых нужно начинать работу
в Linux, что бы не попадаться на похожую утку.
Спасибо заранее всем за дискуссии и советы.
Пожалуйста, все возмущения отдельно. Все же тема личная, несмотря на технические детали. Спасибо отдельно.
Здравствуйте, Artom, Вы писали:
A>Народ, подскажите что кроме чексуммы нужно было делать в такой ситуации? A>Как защищать себя от неконтролируемого удаления файлов в linuxe. A>У меня недельные бакапы, помогает. A>Теперь у меня кроме чексуммы имеются еще и истории директорий. A>Еще я слышал люди пишут скрипты, которые отправляют письмо автору кода в случае его изменения. A>А что еще? A>Подскадите, есть ли общие тактики, с которых нужно начинать работу A>в Linux, что бы не попадаться на похожую утку.
Для для контроля и защиты от изменений есть tripwire, но он требует установки, прав у вас для этого не хватает. А еще можно в папке, где происходит обмен, создать репозиторий git и засунуть в него все содержимое, или же — копировать содержимое папки к себе, скриптом, и опять же складывать в репоз, автоматически добавляя все новые файлы и делая коммит с именем вроде "изменения от 01.02.2004 16:45:37", если git status показывает, что изменения есть.
Наконец, можно поднять где-нибудь в конторе партизанский линуксовый сервер, git на нем, и перетащить на него коллег, взяв у каждого ключ. Мне в одной конторе полгода на могли дать доступ в SVN, так я сначала поднял TFS у себя, а затем и вовсе — создал аккаунт на visualstudioonline, куда и перетащил всех коллег, кто работал в студии. Потом уже, после моего ухода это сильно помогло, когда в конторе на их доморощенном линуксовом сервере с SVN сгорел БП вместе с винтом и материнкой.
Здравствуйте, Artom, Вы писали:
A>Подскадите, есть ли общие тактики, с которых нужно начинать работу A>в Linux, что бы не попадаться на похожую утку.
A>Спасибо заранее всем за дискуссии и советы. A>Пожалуйста, все возмущения отдельно. Все же тема личная, несмотря на технические детали. Спасибо отдельно.
Настрой там гит и всё. Он никак не помешает тем, кто использует твою директорию, зато покажет что и когда ты делал.
И делай копии гита каждый раз на свой комп.
Здравствуйте, Artom, Вы писали:
A>Есть SVN, но используется он только для хранения одной последней "хорошей" A>версии! Источниками народ обменивается просто положив их в заранее оговоренную директорию.
В принципе можно заранее узнать говноконтора это или нет. Если используют svn или вовсе не используют репозитории, то значит говноконтора. Если git или хотя бы сравнимые аналоги, то есть третье поколение систем управления версиями характеризующиеся децентрализацией, то значит не всё так плохо. Опять же если нужно объединить компоненты, но над ними работают разные люди у которых нет доступа к коду друг друга, то это говноконтора. Даже при децентрализации нужно иметь центральный сервер.
A>Понимаю, что тикать оттуда нужно. A>Но появился спортивный интерес и страх, что такие дела могут быть и в других конторах. A>Поэтому нужно бы разобраться что делать в таких ситуациях.
Может и будут, некоторые так и вовсе считают себя суперпрофи на основании какой-нибудь ерунды. С другой стороны, если их наняли и начальство всё устраивает, то почему бы и нет. Программисты часто меняют место работы. Ключевые сотрудники конечно останутся, они же типа профи. А фразу "Понимаю, что тикать оттуда нужно" можно понимать по-разному, с одной стороны "Понимаю, что меня скоро выживут и уволят", с другой "Понимаю, что мне не нравится работать в таком бардаке".
А вам нужно завести git, и пусть даже у них нет сервера на вроде gitolite, а например, просто расшаренная папка. Рекомендую и в GNU/Linux, и в Windows пользоваться gitk в паре с git-gui. На псевдоним remotes/origin/master настроете расшаренную папку и будете туда сбрасывать стандартными механизмами git, то есть никакого ручного копирование папок. Даже если не удастся сбросить, или на удалённом сервере что-то нахимичат, вам будет по барабану, так как папка с вашим проектом образно говоря и будет вашим локальным сервером содержащим все коммиты. Так можно будет узнать о любом отклонении на удалённом сервере. А если не доверяете даже своему рабочему компьютеру, тогда флешка.
Здравствуйте, Artom, Вы писали:
A>Есть SVN, но используется он только для хранения одной последней "хорошей" A>версии! Источниками народ обменивается просто положив их в заранее оговоренную директорию.
У вас не софтовая фирма что ли? Такой бардак я видел только когда контроллеры на заводе в РФ программировал.
После прочитанного я бы сделал только одно на твоём месте: рассылка резюме -> оффер -> "давай до свидания!" (с разъяснением руководству всего, что ты тут написал. Хотя судя по тому, что они не хотят слышать, только будет мало)
Не понимаю людей, которые приходят в гнилоконторы и ценой собственного времени и нервов пытаются сделать там благое дело. Ваш труд все равно 90% людей не поймут, а оставшиеся 10% не оценят. При этом заведете себе кучу врагов. Саморазвития это Вам тоже не даст — пока Вы год разбираетесь, как сделать чексуммы под линуксом, ваши коллеги из негнилоконторы выучат 3 новых фреймворка, добавят в резюме 5 баззвордов и 2 проекта. В итоге, через 10 лет вырастут до лидов/архитектов/ПМов, а Вы так и останетесь непризнанным админом. После чего, контора-таки развалится и Вы с удивлением обнаружите, что 40-летний джуниор никому нафиг не нужен.
Здравствуйте, velkin, Вы писали:
V>А вам нужно завести git, и пусть даже у них нет сервера на вроде gitolite, а например, просто расшаренная папка. Рекомендую и в GNU/Linux, и в Windows пользоваться gitk в паре с git-gui.
Гуй не нужен.
Работать с гитом через гуй это то же что и програмировать в смирительной рубашке. Командная строка гибче и удобнее, лутше потратить чутчуть времени и изучить основные команды. Плюс git-gui и gitk страшны как пятидесятилетняя тетка без макияжа. Впрочем любой гуй для любой VCS (tortoise, atlasian, gitgui, все остальные) это аналог адского котла с кипящей смолой, ждущего грешников не умеющих в командную строку.
A>Подскадите, есть ли общие тактики, с которых нужно начинать работу
Видел как уверенно себя чувствовал начальник отдела, столкнувшиеся с ситуацией когда жена директора главный сейлз и лично его ненавидит, создавая проблемы не то что по разработке — а проблемы с клиентами, периодически давая обещания от его имени, зарезая оценки, скидывая хреновые проекты, в общем всё что могла. А чел был бодр, весел, и ушёл только тогда когда сам решил что взял с этой конторы не только бабло но и всю закалку которую могли тут дать.
Ты сфокусирован на технических приёмах. Но я бы воспользовался местом и ситуацией (тем более если место денежное) — и начал откладывать каждый месяц энную сумму чтобы быть готовым к неожиданному увольнению. После этого завязал с ключевыми противниками игру на выживание не относясь серьёзно к поражениям (всё таки у них годы опыта), но зато мотая на ус все победы. Это может очень пригодится через десяток лет, когда ты сам будешь уже каким-нибудь боссом и столкнёшься с похожей ситуацией на новом уровне — чем больше денег, тем больше вокруг них будет крутиться интриганов.
На тему выживания в корпоративной среде интересно написал Gaperton, и по тексту даже пробегают ссылки на литературу. Но собственно мне при столкновении с такими вещами (правда с не настолько клиническими) хватало безупречности+итальянской забастовки. Т.е. делать всё что можно, столкнувшись с технической проблемой которая должна быть решена другой стороной — например у тебя пробегала проблема с акаунтом — писать письмо ответственным с CC на начальника и по два раза в день напоминать что ждёшь пока поименуют как надо и дадут права. Не дают доступа к системе — проси и права на чтение, и вдобавок образ виртуалки с установленной прогой — с аргументацией что нужна для тестов а продакшн сломать боюсь — посмотри может удастся что-то снять с HDD виртуалки. Нашёл способ всё свалить с исключением — проверь доки, и если должно работать — не ищи обход, пиши что "Валится, и мог бы найти обход или исправить если дадут доступ, а если доступа не дадут — то будет простой или срыв сроков." Информацию о том как валится подавай в максимально неполном и искажённом виде, лучше устно и без каких-то тестов. В общем заставь их почувствовать что вы теперь одного поля ягоды
Плюс никаких договорённостей или обещаний не брать с противников устно — причём на самых сложных поворотах — с CC буквально всем подряд После каждого собрания или разговора рассылать протокол (о чём договорились, кто чего пообещал), и уведомления типа "второй день жду обещанного XYZ, сообщите если не справляетесь". Каждое письмо с обещанием "завтра" проверяй не удалили ли CC на начальство — и если удалили форварди сам. Но самое главное — на себя это не распространять — самому стараться обещать лично и устно, в протоколы себя не включать, и т.п.
Nemerle — power of metaprogramming, functional, object-oriented and imperative features in a statically-typed .NET language
Здравствуйте, hi_octane, Вы писали:
A>>Подскадите, есть ли общие тактики, с которых нужно начинать работу
_>Но собственно мне при столкновении с такими вещами (правда с не настолько клиническими) хватало безупречности+итальянской забастовки.
Мое почтение! Абажаю Итальянцев!
Но для такого нужны крепкие нервы и желание сделать мир лутше. И, само собой, быть с главным злодеем предельно вежлимым и не позволять себе некрасивых выражений ни очно, ни за глаза, а если обсуждать ситуацию с сослуживцами, то только в ключе "смотрите, вот здесь можно сделать более лутше", без критики кого-либо.
Здравствуйте, hi_octane, Вы писали:
_>На тему выживания в корпоративной среде интересно написал Gaperton, и по тексту даже пробегают ссылки на литературу. Но собственно мне при столкновении с такими вещами (правда с не настолько клиническими) хватало безупречности+итальянской забастовки. Т.е. делать всё что можно, столкнувшись с технической проблемой которая должна быть решена другой стороной — например у тебя пробегала проблема с акаунтом — писать письмо ответственным с CC на начальника и по два раза в день напоминать что ждёшь пока поименуют как надо и дадут права. Не дают доступа к системе — проси и права на чтение, и вдобавок образ виртуалки с установленной прогой — с аргументацией что нужна для тестов а продакшн сломать боюсь — посмотри может удастся что-то снять с HDD виртуалки.
Это, может быть, работает в России, но на Западе подобное поведение тут же повесит на вас ярлык troublemaker-а и после этого ничего хорошего вам светить не будет. Тут надо быть гораздо мягче — находить людей наверху, в чьих интересах вещи, которые хотите сделать Вы, и заручившись их негласной поддержкой, косвенно ссылаться на их авторитет для устранения препятствий со своего пути.
A>Гуй не нужен. A>Работать с гитом через гуй это то же что и програмировать в смирительной рубашке. Командная строка гибче и удобнее, лутше потратить чутчуть времени и изучить основные команды. Плюс git-gui и gitk страшны как пятидесятилетняя тетка без макияжа. Впрочем любой гуй для любой VCS (tortoise, atlasian, gitgui, все остальные) это аналог адского котла с кипящей смолой, ждущего грешников не умеющих в командную строку.
А диффы ты как смотришь? Все-таки есть вещи в которых нормальный гуи рулит.
Здравствуйте, Олег К., Вы писали:
ОК>А диффы ты как смотришь? Все-таки есть вещи в которых нормальный гуи рулит.
Для беглого просмотра — git diff, h/j/k/l, : q!, для вдумчивого просмотра — git difftool, для разрешения конфликтов — git mergetool.
При этом выбор что это за tool остается за мной, а не навязываеца авторами гуя. В самом гуе если и есть встроенный tool, то как правило убогий и сделаный "на отъ*бись".
B>Это, может быть, работает в России, но на Западе подобное поведение тут же повесит на вас ярлык troublemaker-а и после этого ничего хорошего вам светить не будет. Тут надо быть гораздо мягче — находить людей наверху, в чьих интересах вещи, которые хотите сделать Вы, и заручившись их негласной поддержкой, косвенно ссылаться на их авторитет для устранения препятствий со своего пути.
Интриганы повесят на тебя ярлык в любом случае. Главное с профессионалами веди себя профессионально, а с интриганами только так. Ну и собственно я последние лет 10 работаю исключительно напрямую с иностранными заказчиками, и пару раз сохраняя культурное лицо преодолевал (правда не такие эпические как у ТС) препятствия в лице "коллег". Так что xUSSR bias ты мне приписываешь ошибочно.
Nemerle — power of metaprogramming, functional, object-oriented and imperative features in a statically-typed .NET language
Здравствуйте, Annatomy, Вы писали:
A>Работать с гитом через гуй это то же что и програмировать в смирительной рубашке.
Это тоже самое, что программировать в продвинутой IDE вместо vim.
A>Командная строка гибче и удобнее, лутше потратить чутчуть времени и изучить основные команды.
Я их знаю, и тем не менее мне лень каждый раз их набирать. Опять же просмотр веток с коммитами удобнее в списке. Тоже самое касается патчей, быстрее мышкой прощёлкать по файлам и посмотреть изменения, нежели что-то там пытаться набрать.
A>Плюс git-gui и gitk страшны как пятидесятилетняя тетка без макияжа. Впрочем любой гуй для любой VCS (tortoise, atlasian, gitgui, все остальные) это аналог адского котла с кипящей смолой, ждущего грешников не умеющих в командную строку.
Что касает gitk и git-gui, то это не любой GUI, а нативный.
gitk — простая и быстрая программа, написана на Tcl/Tk, распространяется с самим Git.
Установив в той же винде git получишь командную строку, а оттуда можно вызвать эти утилиты. В линуксе в принципе тоже самое, хотя пакеты для установки всё же можно выбирать.
Здравствуйте, bazis1, Вы писали:
B>Здравствуйте, hi_octane, Вы писали:
_>>На тему выживания в корпоративной среде интересно написал Gaperton, и по тексту даже пробегают ссылки на литературу. Но собственно мне при столкновении с такими вещами (правда с не настолько клиническими) хватало безупречности+итальянской забастовки. Т.е. делать всё что можно, столкнувшись с технической проблемой которая должна быть решена другой стороной — например у тебя пробегала проблема с акаунтом — писать письмо ответственным с CC на начальника и по два раза в день напоминать что ждёшь пока поименуют как надо и дадут права. Не дают доступа к системе — проси и права на чтение, и вдобавок образ виртуалки с установленной прогой — с аргументацией что нужна для тестов а продакшн сломать боюсь — посмотри может удастся что-то снять с HDD виртуалки. B>Это, может быть, работает в России, но на Западе подобное поведение тут же повесит на вас ярлык troublemaker-а и после этого ничего хорошего вам светить не будет. Тут надо быть гораздо мягче — находить людей наверху, в чьих интересах вещи, которые хотите сделать Вы, и заручившись их негласной поддержкой, косвенно ссылаться на их авторитет для устранения препятствий со своего пути.
очень правильно замечено!
Спасибо!
Сам я как-то не мог это так хорошо сформулировать, мысли плавали.
Но кожей чуватвовал, что не стоит писать опрометчивые ответы с СС.
Вот, это объясняет мои предчувствия.
И даёт руководство как действовать правильно.
Здравствуйте, Artom, Вы писали:
A>Здравствуйте, bazis1, Вы писали:
B>>Здравствуйте, hi_octane, Вы писали:
_>>>На тему выживания в корпоративной среде _>>> писать письмо ответственным с CC на начальника B>>Это, может быть, работает в России, но на Западе подобное поведение тут же повесит на вас ярлык troublemaker-а A>очень правильно замечено!
На самом деле, ставить в копию начальников заинтересованых сторон в некотором роде must have особенно в крупных американских компаниях. Начальник должен иметь хотя бы поверхностное представление о том, чего хотят от его подчиненых.
Так при общении с чисто техническим специалистом, принимающем код от нас на той стороне было оговорено, что в CC было начальство на три уровня над ним и примерно столько же надо мной. Когда на их стороне поменялся начальник первого уровня, то начальник самого верхнего уровня с их стороны попросила заменить старого на нового во всех новых письмах.
Писать письма другим членам коллектива без включения непосредственных руководителей в СС, можно только если вариант удаления этого письма получателем без чтения его, вас вполне устраивает. Аналогично с устными договоренностями, в случае чего можно считать что вы даже не пытались ни с кем договариваться.
Здравствуйте, ilvi, Вы писали:
I>На самом деле, ставить в копию начальников заинтересованых сторон в некотором роде must have особенно в крупных американских компаниях. Начальник должен иметь хотя бы поверхностное представление о том, чего хотят от его подчиненых. I>Так при общении с чисто техническим специалистом, принимающем код от нас на той стороне было оговорено, что в CC было начальство на три уровня над ним и примерно столько же надо мной. Когда на их стороне поменялся начальник первого уровня, то начальник самого верхнего уровня с их стороны попросила заменить старого на нового во всех новых письмах. I>Писать письма другим членам коллектива без включения непосредственных руководителей в СС, можно только если вариант удаления этого письма получателем без чтения его, вас вполне устраивает. Аналогично с устными договоренностями, в случае чего можно считать что вы даже не пытались ни с кем договариваться.
Это можно делать, но ни в коем случае у адресата ваше письмо не должно создавать впечатление "ты у меня, сцуко, на карандаше". Поэтому сначала устно позитивно настроить людей на "%BossName% очень оценит, если мы сделаем так", а потом уже можно CCить %BossName%.
Здравствуйте, hi_octane, Вы писали:
_>Интриганы повесят на тебя ярлык в любом случае. Главное с профессионалами веди себя профессионально, а с интриганами только так.
Это в СССР был на 10 работающих человек один "интригант". Сейчас на Западе ситуация другая — реально необходимой работы кот наплакал, а людей много. Плюс, культурная черта демонстрировать уважение к человеческим чувствам, даже самым дурацким. В итоге, нет четкого разделения на интригантов и не-интригантов. Скорее, для каждого человека на какой-то % важна работа, на какой-то чувства, на какой-то личные амбиции. И люди, для которых работа была бы важнее чувств, в наемных программистах не задерживаются. Поэтому да, Вы можете представить гениальное решение, но команда его коллегиально зарежет, потому что Джон обиделся, что вы забыли его поздравить с днем рождения дочери, у Майка не поинтересовались, как сыграла любимая команда, а с Тимом не захотели полчаса обсуждать развитие сюжета любимого сериала. _>Ну и собственно я последние лет 10 работаю исключительно напрямую с иностранными заказчиками, и пару раз сохраняя культурное лицо преодолевал (правда не такие эпические как у ТС) препятствия в лице "коллег". Так что xUSSR bias ты мне приписываешь ошибочно.
Это другая тема. Когда тебе аутсорснули за 10% от бюджета 90% работы — тебя действительно никто в интриги вплетать не будет. А хочешь нормальных денег на фуллтайме — держи ведро.
