Здравствуйте, Gradient, Вы писали:

G>Это только одна из стратегий. Легче быть формалистом — ну ок, будь им.
G>но ИМХО в случае если начальник нормальный, никого не гнобит и отстаивает интересы команды — немного неформальности не помешает. Это обоюдно полезно. Например, я могу свалить с работы в середине дня по делам безо всяких официальных разрешений. Но и с другой стороны если сроки прижали — могу сверхурочно поработать. И всем хорошо.

У меня график тоже свободный, могу свалить с работы когда хочу, могу вообще не прийти, никто слова не скажет. Неформально очень полезна. Можно неформально обсудить задачу в курилке или за чашкой чая, но вот после этого надо формально все подитожить. Сколько раз было так, что кто-то что-то сделал, а через полгода к нему приходят и спрашивают, какого х.. он это сделал. И потом никто не вспомнит, что там в курилке было сказано. А вот когда есть письмо, все в порядке.

G>Если так мало времени пишешь код — вероятно, совмещаешь роль аналитика и разработчика. Потому что для чистого разработчика — маловато будет.

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

Здравствуйте, зиг, Вы писали:

К слову о багах. Баги — это же хорошо. Чем больше багов исправляешь, тем более ценным сотрудником ты являешься. Если не делать баги, никто о тебе и знать не будет. Ну работает твоя система и работает. А если есть баги, да еще критичные, сразу начинается кипишь, о тебе узнают менеджеры, тестировщики, сотрудники техподдержки, ты становишься очень важным, так как тебе поручено исправить баг, все ждут исправлений, ходят к тебе постоянно, спрашивают сроки.
Это как про сисадминов — хорошие сисадмины ничего не делают.

Я вот в последнем релизе уже 25 багов исправил, я молодец.

Здравствуйте, зиг, Вы писали:

зиг>Постараюсь описать ситуацию кратко и понятно (ясность мыслей — залог здоровья.)
зиг>Итак, Суть такова (я немного нервничаю).

зиг>Возможно, все это бред и чистой воды паранойя. Судите сами.

[...]

зиг>5. Только пожалуйста без набившего оскомину "замуж дура срочно замуж". По делу плиз.

Были у нас пионеры, теперь будут ещё и пионерки... Объясняю для юниоров.

1. Альфасамцов на работе не бывает. Бывают руководители и подчинённые. Приказать тебе может только твой непосредственный руководитель. Остальные могут только попросить, и эти просьбы ты можешь как выполнить, так и отклонить. Да, и не забывай, что ответственность за выполненную просьбу ложится на тебя, а ответственность за невыполненную просьбу — на просящего.

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

3. Пока ты не согласовала свою работу со своим шефом (а он — со смежными руководителями) — никаких своевольничаний. Даже если фикс выглядит тривиальным, простым и тебе всё понятно. Сначала тикет (или любая другая "бумага"), потом согласование, потом выполнение. Ни в коем случае не наоборот.

4. Если ты не знаешь о каких-то нюансах использования программы, об этом нигде не написано и ты не знаешь даже у кого об этом спросить (тем более, если не знаешь и о чём спрашивать) — это не твоя проблема. Это банальная ситуация, в которую часто попадают новички и виноваты в ней кто угодно, только не они. Если ты в неё влетела, то сначала объяви, что тебя никто не проинструктировал. Пусть с этим разбираются те, кому положено.

5. Если понимаешь, что влезаешь в чужую сферу ответственности — три раза спроси и два раза напиши об этом. А лучше — просто сделай тикет в джире, пусть разбираются те, кому положено. Если уж руки зачесались до полного "немогутерпеть", сделай фикс и отправь отдельным письмом с CC на всех, кого это может коснуться.

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

Здравствуйте, Vzhyk, Вы писали:

>> А вот это самое плохое. В первую очередь "дружи" с начальством, старайся
>> вводить его в курс проблем, чтобы он знал о них заранее и в правильном
>> для тебя свете.
V>Жуть. Читаю я здесь, такое впечатление, что программистов уже не
V>осталось, только профессиональные интриганы.

Об интригах тут даже речи не шло, с чего ты это взял? Любая интрига (открою тебе страшный секрет) строится на сознательном манипулировании информационными потоками — скрытие какой-то информации от одних и открытие другим, а разделение труда, рассылки с сообщениями об ошибках, тикеты в джире — это никакие не интриги, а так, обычное рабочее взаимодействие. С начальством и в самом деле нужно "дружить", то есть ни в коем случае не стыдиться и не пугаться общения с ним.

Кстати, Зиг сама невольно (?) начала интриговать, когда... Короче, весь топикстарт — сплошное описание того, как можно закрутить интригу на ровном месте.

Здравствуйте, IOnlyWantToSay, Вы писали:

зиг>>... По делу плиз.
IOW>Все это сильно напоминает "кипучую бездеятельность", "бурю в стакане воды" и пр. Работал я однажды с похожей дамой, удручающее впечатление. Ничего личного, кто-то выше писал, что лучше ужасный конец. У тебя просто нет серьезной жизненной мотивации, появится цель жизни — все остальное само собой нормализуется. И не отчаивайся, все в той или иной степени проходят через это.

Чепуха. Всё ровно наоборот — активность так и прёт, не мешало бы поубавить.

Здравствуйте, Пофигист, Вы писали:

П>Который, по идее, тоже должен быть альфа-самцом. Вот пусть и разбираются между собой. А зиг насладится батлой.

Нет, начальник просто занимает соответствующую должностную позицию, больше ничего.

Здравствуйте, Ikemefula, Вы писали:

I>1 научиться брать на себя ответсвенность решая проблемы

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

I>2 вовремя детектить проблем

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

I>3 доносить мнение до тех, кто может решить проблему

Об этих "тех" юниор может и не знать, потому всё, что он должен сделать — громко заорать о найденном баге, т.е. отправить письма по известным ему каналам (джира, внутренняя почта).

I>4 прекратить делить код и баги на свои и чужие

Код является чьим-то просто по факту своего появления, баги — аналогично, поэтому "прекратить делить" их невозможно. Проблема не в этом, а в том, что почему-то считается "плохим тоном" отмечать авторство проблемного кода.

Здравствуйте, зиг, Вы писали:

KP>>1. На виноватых наехать, люлей раздать.
зиг>а как наехать, как раздать, если я тут как бе джуниор, по уставу не положено

"Раздавать" будут те, кто должен этим заниматься. Твоё дело — поставить в известность.

KP>>2. Свои разработки окружать тестами, тех кто ломает бить по голове палкой (или хотя бы тыкать в них пальцем и громко говорить фууу).
зиг>в данных ситуациях #2 & #3 не помогло бы. ну и сломают они юнит тест, и чо. допилят мой тест под свои баги и вперед...

Всё. Изменения кода автоматически задокументируются системой контроля версий. Если дело дойдёт до выяснений, кто что сломал — авторство будет установлено мгновенно.

KP>>3. Расслабиться и забить на мелкие недоразумения.
зиг>меня волнует что этих мелочей накопилось выше крыши. меня этак из джуниоров не переведут, так и будут считать тупой багоделательницей. как быть?

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

Здравствуйте, мыщъх, Вы писали:

М>если тестеры тестируют криво это значит, что права на ошибку у вас действительно нет.

Нет, это означает, что тестеры криво тестируют, больше ничего. Вполне вероятно, что у них не хватает ресурсов: людей, времени, плана, инфраструктуры. Это не означает, что можно писать заведомо багнутый код, просто не надо валить проблемы с больной головы на здоровую.

Здравствуйте, Геннадий Васильев, Вы писали:

I>>1 научиться брать на себя ответсвенность решая проблемы

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

Решения проблем не всегда в коде, я уже говорил про это.
"я не осмелилась ему заметить " — не взяла на себя ответсвенность, а надо было

I>>2 вовремя детектить проблем

ГВ>Совет ни о чём. Проблема детектится тогда, когда она детектится, ни раньше, ни позже. Просто о найденных проблемах нужно письменно ставить в известность коллег, включая начальство.

Если проблемы у тебя детектятся сами, то так и есть. А если ты их детектишь, то все от тебя зависит. Для того что бы детектить проблемы, нужно прикладывать определенные усилия и о результатах репортать куда следует.

"было очень глючным и содержало один архитектурный изъян"..."на изъян забила" — проблему не задетектила

I>>3 доносить мнение до тех, кто может решить проблему

ГВ>Об этих "тех" юниор может и не знать, потому всё, что он должен сделать — громко заорать о найденном баге, т.е. отправить письма по известным ему каналам (джира, внутренняя почта).

Не знать начальства ? Не знать коллег ? Не знать подчиненных ? Жги дальше.

I>>4 прекратить делить код и баги на свои и чужие

ГВ>Код является чьим-то просто по факту своего появления, баги — аналогично, поэтому "прекратить делить" их невозможно. Проблема не в этом, а в том, что почему-то считается "плохим тоном" отмечать авторство проблемного кода.

Потому что это перекладывание ответсвенности примерно в 90% случаев.

Здравствуйте, Vzhyk, Вы писали:

>> Проверено мною лично в активной борьбе с индусами — работает на ура!
V>Но не с русским . Индусы тупые, как грит Задорнов. Самый действенный
V>вариант сказать: "Ой у меня девичья память, ты так много умного и
V>правильного сказал, я все сделаю, но я все забыла. Пришли мне, дуре
V>(дураку), это все в письменном виде."
V>Действует абсолютно.
Не, с русскими тоже нормально работает, ибо против документов не попрешь.

>> 3) Сейчас нужно взять вот этот текст с форума, переписать его без эмоций
>> и с указанием точных проблем и действующих лиц, пойти к своему
>> начальнику и обсудить (БЕЗ ЭМОЦИЙ!)
V>Ни в коем случае. Во-первых наша "глупая" еще не в курсе особенностей
V>начальства и традиций интриг на конторе. Во-вторых, мы не знаем
V>насколько она опытна в ведении интриг. Фактически, предлагаемый тобой
V>путь — это путь интриг.
На мой взгляд, это не путь интриг, а путь заблаговременного прикрывания своей пятой точки, до того, как на нее обрушится всеобщий гнев.

>> Ну и наконец ЗЗИ: у меня седые волосы появились в 22
V>Вообще-то в таком возрасте — это сильно рано. Ты бы к врачам сходила,
V>что-ли.
Спасибо за беспокойство, но не волнуйтесь, все нормально. Во-первых, это наследственность — у мамы было почти также, во-вторых, мне щас уже 29, седины стало больше, но со здоровьем все отлично, никакой корреляции замечено не было. Вон некоторые мужчины лысеть начинают в 20 лет, хотя ничем не больны.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, мыщъх, Вы писали:

М>> если тестеры тестируют криво это значит, что права на ошибку у вас действительно нет.
ГВ> Нет, это означает, что тестеры криво тестируют, больше ничего.
ответ не по существу вопроса. мы не в дет. саду. и даже не в школе. "это они виноваты, что не обнаружили мой баг" -- очень слабый аргумент, если баг действительно ваш.

> Вполне вероятно, что у них не хватает ресурсов:
> людей, времени, плана, инфраструктуры.
фирма (даже маленькая) это сложная система, находящаяся в состоянии динамического равновесия. это значит, что глубина тестирования напрямую определяется качеством кода. если с приходом нового сотрудника качество кода неожиданно падает, то тестеры банально не успевают на это отреагировать. во всяком случае, если это реальные тестеры, а не эльфы из детских сказок.

> Это не означает, что можно писать заведомо багнутый код,
> просто не надо валить проблемы с больной головы на здоровую.
писать _заведомо_ багнутый код это тянет на как минимум на выговор, а как максимум на УК. в здравом уме такого делать никто не будет.

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

опять-таки, что за тестеры, по какой схеме они работают? пишут ли девы документацию для тестеров, объясняя им что и как тестировать? вы же понимаете, что "черный ящик" тестировать сложно. а "белым ящиком" чужой исходный код не является. а потому необходим отлаженный механизм взаимодейстия между девами и тестарами. подозреваю, что на фирме такой механизм есть (возможно, в туателе или курилке), но ТС о нем не знает. не знаю как у вас, а мне дали доступ к чужим исходникам только после двх лет удаленки и трех лет фуллтайма (итого пять), а до этого даже к своим собственным исходникам доступа не было. и это как бы логично. если я могу править свои исходники когда хочу и как хочу -- это бардак и ужос. и прежде чем мне доверить такое ответственное дело нужно быть во мне уверенным. а для этого нужно время.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Чепуха. Всё ровно наоборот — активность так и прёт, не мешало бы поубавить.
Об этом и речь

Здравствуйте, Ikemefula, Вы писали:

I>>>1 научиться брать на себя ответсвенность решая проблемы
ГВ>>Самое страшное в таком "взятии" — это то, что нередко "берущие" попросту не представляют себе всей сферы ответственности, но уже хватаются. Так что, с этим пунктом совершенно не согласен. Необходимую долю ответственности сотруднику делегирует руководство, отдавая ему соответствующие указания, больше никто.
I>Решения проблем не всегда в коде, я уже говорил про это.
I>"я не осмелилась ему заметить " — не взяла на себя ответсвенность, а надо было

Не-а, это не ответственность, а выдвижение процедурных требований, которые без поддержки "сверху", скорее всего, никто бы удовлетворять не стал. Если уж приводить пример ответственности, которую можно было бы взять на себя, то здесь ближе ситуация, когда ТС не стала разъяснять ситуацию руководству, потому что "так не принято". А в остальном у ТС, можно сказать, даже гиперответственность.

I>>>2 вовремя детектить проблем
ГВ>>Совет ни о чём. Проблема детектится тогда, когда она детектится, ни раньше, ни позже. Просто о найденных проблемах нужно письменно ставить в известность коллег, включая начальство.
I>Если проблемы у тебя детектятся сами, то так и есть. А если ты их детектишь, то все от тебя зависит. Для того что бы детектить проблемы, нужно прикладывать определенные усилия и о результатах репортать куда следует.

А в обязанности ТС разве входит поиск проблем на соседнем участке работы?

I>"было очень глючным и содержало один архитектурный изъян"..."на изъян забила" — проблему не задетектила

Проблему она вполне задетектила, только, действительно, не сообщила куда следует. Однако, никаких особых усилий для определения проблемы, как видишь, не понадобилось. "Шамо приполжло" (c).

I>>>3 доносить мнение до тех, кто может решить проблему

ГВ>>Об этих "тех" юниор может и не знать, потому всё, что он должен сделать — громко заорать о найденном баге, т.е. отправить письма по известным ему каналам (джира, внутренняя почта).

I>Не знать начальства ? Не знать коллег ? Не знать подчиненных ? Жги дальше.

Ага-ага, и он сходу будет знать о том, к кому по каким мелким вопросам надо обращаться. Жги дальше.

I>>>4 прекратить делить код и баги на свои и чужие
ГВ>>Код является чьим-то просто по факту своего появления, баги — аналогично, поэтому "прекратить делить" их невозможно. Проблема не в этом, а в том, что почему-то считается "плохим тоном" отмечать авторство проблемного кода.
I>Потому что это перекладывание ответсвенности примерно в 90% случаев.

Перекладывание с кого на кого?

Здравствуйте, мыщъх, Вы писали:

М>>> если тестеры тестируют криво это значит, что права на ошибку у вас действительно нет.
ГВ>> Нет, это означает, что тестеры криво тестируют, больше ничего.
М>ответ не по существу вопроса. мы не в дет. саду. и даже не в школе. "это они виноваты, что не обнаружили мой баг" -- очень слабый аргумент, если баг действительно ваш.

Хе-хе. Всё очень сильно зависит от условий. Бесспорно, непосредственно виноват в появлении бага тот, кто его допустил, но с тестеров их долю ответственности снимать ну никак нельзя. На кой чёрт они тогда вообще нужны? И с руководства, которое поспособствовало созданию соответствующих условий тоже нельзя снимать их долю ответственности. То есть да, мы действительно, не в детском саду и не в школе, поэтому единственного виноватого может запросто и не оказаться (сюрприз!). Отсюда "не нужны" ни герои, тянущие всё за всех, ни козлы отпущения, на которых валят все шишки.

>> Вполне вероятно, что у них не хватает ресурсов:
>> людей, времени, плана, инфраструктуры.
М>фирма (даже маленькая) это сложная система, находящаяся в состоянии динамического равновесия. это значит, что глубина тестирования напрямую определяется качеством кода.

Мыщъх, осторожней, второе предложение следует из первого с очень большой натяжкой.

М>если с приходом нового сотрудника качество кода неожиданно падает, то тестеры банально не успевают на это отреагировать. во всяком случае, если это реальные тестеры, а не эльфы из детских сказок.

Э нет, дружище. Порядок тестирования (в норме) определяется сложностью кода, а не уверенностью в том, что "Вася всегда пишет без ошибок, его можно не проверять". Хотя не буду спорить, из желания сэкономить могут и плюнуть на соответствие между тестированием и сложностью продукта. Как раз такая практика хорошо поддерживается рассуждениями о "системе, находящейся в состоянии динамического равновесия".

>> Это не означает, что можно писать заведомо багнутый код,
>> просто не надо валить проблемы с больной головы на здоровую.
М>писать _заведомо_ багнутый код это тянет на как минимум на выговор, а как максимум на УК. в здравом уме такого делать никто не будет.

Да, верно, здесь я несколько утрировал.

М>получается, что вы вроде бы и согласны со мной, а вроде бы и нет.

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

М>хорошо, спрошу прямо. что произойдет, если ТС всобачит еще один баг и тестеры его снова не обнаружат?

Откуда мне знать? Я ничего не знаю ни о системе тестирования, ни о способе взаимодействия девов и тестеров которые приняты на фирме ТС. Но если ТС в предложенной ситуации придёт жаловаться на форум, я буду изначально предполагать, что у неё есть некоторые основания считать, что ошибка могла быть выявлена на этапе тестирования.

М>вы не согласны с тем, что ТС следует сначала изучить систему, а только потом вносить правку? и не только вносить, но и просчитывать все возможные последствия, не надеясь на тестеров?

А вот тут надо подумать прежде всего о том, как именно изучается система. Изучать систему по коду — занятие неблагодарное. Изучать систему по постановочным документам — гораздо более простое и продуктивное. Насколько я понимаю, ТС вынуждена в немалой степени изучать систему по коду, а это может оказаться совсем не простым занятием (как реверс-инженер, ты должен знать это гораздо лучше меня). Отсюда мораль: ТС запросто могла попасть в положение, когда правку вносить нужно, а времени на полное изучение системы у неё попросту нет и следовательно, она со значительной вероятностью понаделает багов.

М>опять-таки, что за тестеры, по какой схеме они работают? пишут ли девы документацию для тестеров, объясняя им что и как тестировать? вы же понимаете, что "черный ящик" тестировать сложно. а "белым ящиком" чужой исходный код не является. а потому необходим отлаженный механизм взаимодейстия между девами и тестарами. подозреваю, что на фирме такой механизм есть (возможно, в туателе или курилке), но ТС о нем не знает.

"В курилке" никакого механизма быть не может, не строй иллюзий. Там может быть только "смазка" для существующего механизма, не более того. Смазка весьма ненадёжная, хотя подчас ускоряющая все процессы в разы.

М>не знаю как у вас, а мне дали доступ к чужим исходникам только после двх лет удаленки и трех лет фуллтайма (итого пять), а до этого даже к своим собственным исходникам доступа не было. и это как бы логично. если я могу править свои исходники когда хочу и как хочу -- это бардак и ужос. и прежде чем мне доверить такое ответственное дело нужно быть во мне уверенным. а для этого нужно время.

Интересно. И что из этого следует по отношению к ТС и её ситуации?

Здравствуйте, зиг, Вы писали:

зиг>Возможно, все это бред и чистой воды паранойя. Судите сами.
зиг>1. Где-то в апреле...

В проекте был обнаружен баг, был пофикшен.

зиг>2. Следующий релиз через месяца полтора-два...

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

зиг>3. И вот недавно выпустили новый релиз.

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

зиг>4. мой непосредственный начальник ничего этого не знает.

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

зиг>5. Только пожалуйста без набившего оскомину "замуж дура срочно замуж". По делу плиз.

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

Как перестать беспокоиться и начать жить:

Неважно кто внёс баг, важно, что баг фиксится.
Неважно кто испортил релиз, важно, что всё вовремя было исправлено.
Неважно кто портит код, важно вовремя заявить, что с кодом есть проблемы.
Неважно у кого авторитет большой, значимость проекта и авторитет команды всегда выше. Если замечена проблема (не с человеком, всегда в проекте/коде), она выносится на совместное обсуждение.

Твоя задача не искать оправданий, а решать проблемы. В команде ценится тот, кто умеет решать проблемы, а не тот у кого есть оправдания. Если ты считаешь, что уж больно много ты делаешь за других, то ты идёшь к начальнику и говоришь волшебные слова, что команда работает не в полную силу и предлагаешь своё решение — перестать строчить код, почистить репозиторий и тому подобное.

Заявляй о проблемах — это твоя реклама (проблемы и баги не твои или чьи-то, они принадлежат проекту и ты первая их увидела) — и решай их по мере сил — это твой путь к завоеванию авторитета и продвижению по карьерной лестнице.

По-моему, это очевидные вещи. Работа не продолжение твоей личности, она влияет на тебя, даёт опыт, но не определяет кто ты есть. Если код кривой, это не значит что ты кривая. Исключи свою личность и личности других из работы и всё встанет на свои места.

Здравствуйте, зиг, Вы писали:

Если работаете по JIRA или другой системе отслеживания изменений, то никаких устных распоряжений чего-то там изменить, тем более не от начальства. Если будет настаивать начальство, начать задавать вопросы, для чего нам тогда джира. Начальство, конечно, все равно заставит, но точно запомнит этот момент и будет понимать, что менять правила будет сложно.
Зачем правила не свои баги? От кого задача поступила? При появлении баг должен быть назначен на автора. Автор болен — через начальство на того, кто свободен. При этом всем по истории будет ясно, что правит не создатель бага.
Паранойя это или реальность по этому посту не сказать, надо смотреть по ситуации в коллективе. Но тебя это точно напрягает, значит надо что-то делать. Дойди до начальства, поговори, что беспокоишься за свою репутацию разработчика в коллективе вот по таким причинам и объясни, что к чему. Только не в ключе "я не виновата, это все они". А что-то в духе "Не могли бы уточнить некоторые рабочие моменты, например, что делать, если я вижу крупное сомнительное неучтенное изменение, которое затрагивает и мою задачу?", "Как поступать, если не от начальства приходит баг не по моей задаче, а то боюсь попасть, как в прошлый релиз?" и так далее.
Слезы убрать. Ничто так не бесит, когда кто-то начинает давить на эмоции и гнуть линию "пожалейте меня". Если хочешь, чтобы воспринимали как равную, никаких слез и истерик. Иначе будут воспринимать как плаксивую истеричку.

01.08.2012 19:55, Геннадий Васильев пишет:

> Были у нас пионеры, теперь будут ещё и пионерки... Объясняю для юниоров.
Вот теперь у меня возникли сомнения в твоем практическом опыте. В теории
ты прав, конечно, но...

01.08.2012 20:13, Геннадий Васильев пишет:

> Об интригах тут даже речи не шло, с чего ты это взял? Любая интрига
> (открою тебе страшный секрет) строится на сознательном манипулировании
> информационными потоками — скрытие какой-то информации от одних и
> открытие другим,
Что? Ну и фантазии. Любая интрига строится только на одном, приобрести
себе определенные плюшки за счет других.

> С начальством и в самом деле нужно "дружить", то есть ни
> в коем случае не стыдиться и не пугаться общения с ним.
Прикольная трактовка дружбы.

> Кстати, Зиг сама невольно (?) начала интриговать, когда...
Чего? Пока там только слезы ребенка о том что окружающий мир
несправедлив и к ней в частности.

01.08.2012 20:49, Геннадий Васильев пишет:

> Всё. Изменения кода автоматически задокументируются системой контроля
> версий. Если дело дойдёт до выяснений, кто что сломал — авторство будет
> установлено мгновенно.
Это вообще никому не интересно, кроме пионеров-программистов.
Начальство, при подобных разборках либо наваляет обоим разборщикам, либо
просто назначит виновного, исходя, исключительно из личных предпочтений.

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