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

I>>Да ну? Программист выходит какой то джуниористый, ни за что не отвечает.
C>Он отвечает за качество написанного кода: быстродействие алгоритмов, отсутствие исключительных ситуаций, корректность обработки пользовательских данных.

Этого мало.

I>>Это если программист — джуниор. Ты несешь ответственность за всё, что делаешь — коммуникация, координация, следование плану и тд.
I>>Твоё работу не вмергали — а чего ты молчал? Ждал, что менеджер будет тебе должен?
I>>Почему не в курсе, что ты чего то делал? Снова менеджер должен?
I>>Уткнулся полировать минорный компонент — ты не в курсе, где у вас приоритеты и весь объём работ?
C>Конечно в курсе — есть руководитель проекта или отдела, который всегда держит в курсе приоритетов. Если работу не вроверили и не влили в основную ветку, то можно, конечно, спустя время поинтересоваться, почему так вышло, но это точно не моя задача. У меня в свою очередь своих проверок хватает, которые нужно проверить и или одобрить, или отклонить.

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

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

4>Я не пойму чего сказать пытаетесь, что не надо делать хорошо, когда вокруг все делают плохо?

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

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

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

I>>Классика — ты д'Артаньян, они — канальи. Тему можно закрывать — здесь ты внятно описываешь откуда берется токсичность.
I>>д'Артаньяны всегда токсичные и вносят разлад в команду.

C>А по-мойму, я задел какие-то твои чувства.

В твоей картине мира сотрудники, кроме тебя работают спустя рукава, читай сам:

Но в современной разработке я вижу совсем другую картину — сотрудники, спустя рукава, одобряют код друг друга, а ответственность размывается.

Вот и выходит — один д`Артаньян, а остальные работают спустя рукава, т.е. канальи.

> Но если у вас на работе нормально, что код с потенциальными ошибками принимается, и ответственность никто не несёт — ок, просто не во всём мире так, и дартаньянства я тут не вижу.

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

Выглядит так, будто ты сам придумал требования, про которые никому не сказал, и ждёшь, что их будут соблюдать. А потом обвиняешь: 'Ага — вы спустя рукава работаете, апруваете абы что!!!!1111'

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

I>>Это одно и то же. Ты сделал вид, что не в курсе, что значит эта идиома

4>Это какой-то неуместный жест, я бы даже сказал токсичный

Не надо притворяться — идиома означает вполне конкретную вещь

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

"болеть за дело" — относиться ответсвенно и тащить.

I>>Ога. Болеть за дело — значит, что дело в приоритете, имеет важность для сотрудника, что проявляется в соответсвующем отношении — ответственный подход, старательное, тщательное исполнение и тд.

4>Вот ТС и болел, в отличие от его коллег, но в том окружении это смысла не имело, там у людей были совершенно другие цели ...

У ТС только с его слов вполне понятная картина — д'Артаньян и канальи. Что там с коллегами — мы про них ничего не знаем.
На самом деле может быть всё что угодно.

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

C>И вот вопрос сообществу: что я делал не так? Ведь я:
C>1. Никоим образом не пытался казаться высокомерным. Даже несмотря на то, что кроме меня ни у кого в компании не было профильного формального образования (были mechanical engineers, electrical engineers).
C>2. Постоянно откликался на вопросы "как сделать это", даже если "это" никак меня не касалось.
C>3. В свобоное время делал что-нибудь с кодом, чтобы улучшить его качество.
C>4. Постоянно прибирался в невероятно пыльном и грязном ангаре, чтобы там было просто приятно находиться. Приходил для этого в выходные.

C>А самое главное, я всем сердцем был за проект. Я верил, что если не бежать вперёд, а сконцентрироваться на качестве, то потом можно рвануть очень и очень быстро. Компания не была очередной соцсетью для кошек, не было нужды выходить на рынок первыми, потому что они уже были не первые, а робот, которые не делает то, что должен, никому не нужен. К тому же один из двух конкурентов недавно вышел из гонки, а другой был обычным распильным стартапом из Долины.

C>После этой работы я то ли подгорел, то ли утратил интерес к работе программистом и пытаюсь разобраться в себе. Что делать — искать нормальную работу, где люди компетентные и несут ответственность за код, который пишут, или смириться с тем, что soft skills захватили мир, и теперь кукушка хвалит петуха за то, что хвалит он кукушку?

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

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

O>Всегда надо делать хорошо. Просто понятия хорошо и плохо нужно сначала определить.

Хорошо:
— Работа сделана в срок с надлежащем качеством.

Нормально:
— Работа сделана в срок с НЕ надлежащим качеством, требует адекватное время на доработку (например потрачено 5 месяцев, гарантировано нужно еще 1-2).

Плохо:
— Работа сделана в срок с НЕ надлежащим качеством, но её "выбрасывают" на эксплуатацию
— Работа не сделана в срок, требует НЕадекватное время на доработку (например потрачено 5 месяцев, нужно еще 3+).

O>Например если долго проектировать начать делать "правильно" но проект закроют — не смотря на то что все делали "хорошо", это плохо для судьбы проекта.

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

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

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

O>>Всегда надо делать хорошо. Просто понятия хорошо и плохо нужно сначала определить.

4>Хорошо:
4>- Работа сделана в срок с надлежащем качеством.

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

O>>Например если долго проектировать начать делать "правильно" но проект закроют — не смотря на то что все делали "хорошо", это плохо для судьбы проекта.

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

У тебя в начале особо нет выбора — или нацелится на дорогой продукт который будет качественный, но останется только в твоих фантазиях = т.к. на фантазии много денег никто не даст.
Либо сделать "фуфло", но которое будет востребовано, например за счет какой-то фичи или привлекательной цены, получить прибыль и сделать следюущую версию лучше.
После того как ты выпускаещь "фуфло" но которое находит своего покупателя , привлечь деньги становится уже проще. Венчурные фонды гораздо легче дают денег на развитие уже как-то работающего бизнеса, чем на обещания сделать очень круто и качественно — совсем не дают, говорят приходите когда продадите хотя бы 1000 штук например.

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

4>Хорошо:
4>- Работа сделана в срок с надлежащем качеством.

А что такое "надлежащее качество" и кто его определяет ?

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

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

4>>Хорошо:
4>>- Работа сделана в срок с надлежащем качеством.

I>А что такое "надлежащее качество" ...

Как минимум программа делает, то что требуется её потребителю, с минимальным количеством "побочных эффектов". В общем обладает хорошими эксплуатационными характеристиками.
Дополнительным и очевидным плюсом является удобство сопровождения/обслуживания.

I>... и кто его определяет ?

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

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

4>Как минимум программа делает, то что требуется её потребителю, с минимальным количеством "побочных эффектов". В общем обладает хорошими эксплуатационными характеристиками.
4>Дополнительным и очевидным плюсом является удобство сопровождения/обслуживания.

В сумме такое называют "низкое качество". Удивительно, да?

Что бы качество стало высоким, нужно гораздо больше требований, чем эти три строчики.

I>>... и кто его определяет ?

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

Разработчик как раз ничего не определяет. Ему необходимо достигать заданного уровня качества. Задают уровень и контролируют совсем другие люди.
Потребитель тоже не определяет — у него всего лишь свои ожидания.
Уровень задает сама контора, или берет стандарт по индустрии, если есть, или от себя, ориентируясь на рыно. Контролируют качество обычно QA.
А если всё это повесить на разработчиков, получится гарантированая ахинея.

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

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

VC>>Ну я видел таких людей с такой лексикой в одной российской конторе, видел также как приличные люди оттуда из-за этого уходили, и в результате (частично по этой причине, хотя конечно не только) конторе настал таки 3.14здец

4>Скорее не только по этой причине, или даже совсем не по этой, не стоит путать типовое быдло, и хороших инженеров, которые не терпят откровенной лажи в своем окружении.

Э...Полагаете вам виднее по какой причине? Иногда "инженеры не терпящие откровенной лажи" ведут себя как быдло. Хотя там быдло в основном было в менеджменте, инженеры по большей части вели себя адекватно. Правда главный быдлан вырос из инженеров.

4>Также интересно услышать, что такое — "приличные люди", это которые в обморок падают от слов на 3.14?

В обморок не падают, но когда с тобой регулярно общаются таким образом, желание работать там пропадает. Я тоже отчасти из-за этого оттуда ушел, как оказалось не зря.

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

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

4>>Как минимум программа делает, то что требуется её потребителю, с минимальным количеством "побочных эффектов". В общем обладает хорошими эксплуатационными характеристиками.
4>>Дополнительным и очевидным плюсом является удобство сопровождения/обслуживания.

I>В сумме такое называют "низкое качество". Удивительно, да?

т.е. низкое качество, это когда продукт делает, то что нужно, доставляет минимум проблем потребителю и целом хорошо эксплуатируется?

I>Что бы качество стало высоким, нужно гораздо больше требований, чем эти три строчики.

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

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

VC>Э...Полагаете вам виднее по какой причине?

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

VC>В обморок не падают, но когда с тобой регулярно общаются таким образом, желание работать там пропадает. Я тоже отчасти из-за этого оттуда ушел, как оказалось не зря.

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

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

I>>В сумме такое называют "низкое качество". Удивительно, да?

4> т.е. низкое качество, это когда продукт делает, то что нужно, доставляет минимум проблем потребителю и целом хорошо эксплуатируется?

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

I>>Что бы качество стало высоким, нужно гораздо больше требований, чем эти три строчики.

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

Все что ты перечислил к качеству никак не относится, нисколечко.

Качество это степень соответствия требованиям. Нет требований — нет качества.

Что бы остудить особо хитрых, есть качество требований, т.е. степень соответствия требований некоему стандарту индустрии.

Поскольку всё подряд проверить просто невозможно, накладываются доп. требования, косвенные
1. на процесс разработки — степень соответствия требованиям к процессу, например, если нет возможности вкомитать прямо в прод, это повышает качество
2. на процесс тестирования — степень соответствия требованиям индустрии
3. на команду — принятие решений и тд. Вместо "я так хачю, у тебя говно, иди переписывай" спользуется понятная схема взаимодействия, понятно кто за что отвечает
4. на специалистов — требования к квалификации
5. итд

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

Например, количество багов само по себе нисколько не говорит о качестве. Количество пофикшеных тоже. Парадокс, да? Нам нужны определенные испытания и проверяемое условие "успешно"
Соответсвенно, если есть испытания, есть динамика выявления багов, динамика исправления, нету шарахания вида "тут тестим, тут не тестим", все это может говорить о качестве.

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

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

VC>>Э...Полагаете вам виднее по какой причине?

4>В основном конторы разваливаются по причине корявого менеджмента. то что, кто-то там не следит за речью, это скорее последствия, чем причина развала горе-конторки.

VC>>В обморок не падают, но когда с тобой регулярно общаются таким образом, желание работать там пропадает. Я тоже отчасти из-за этого оттуда ушел, как оказалось не зря.

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

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

I>Разработка это давно уже хоккей или футбол, а не блистание личной доблестью. Нет команды — нет результата.

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

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

4>> т.е. низкое качество, это когда продукт делает, то что нужно, доставляет минимум проблем потребителю и целом хорошо эксплуатируется?

I>Низкое качество, это когда требования к качеству мутные, непроверяемые — ровно как в твоей формулировке.
I>Хорошесть никак не валидируется, это чистая субъективщина.
I>Один разраб считает, что надо вот так, другой — что надо вот эдак.

Что считает конкретный программист особого значения не имеет, т.к. в конечном счете качество ПРОДУКТА определяется на уровне его потребителей. Например если продукт тормозит, глючит, и падает (плохие эксплуатационные характеристики) то очевидно, что качество низкое. Если всех этих проблем нет — высокое.

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

I>Все что ты перечислил к качеству никак не относится, нисколечко.

Допустим у меня есть сервис, разработанный в срок (даже чуть раньше), который обрабатывает несколько 100K транзакций в сутки, в процессе обработки ничего нигде не теряет, аппаратных ресурсов потребляет мало и хлопот в его обслуживании/сопровождении никому не доставляет — качество высокое. Не стоит на ровном месте "квантовую механику" устраиваить.

Другой пример, помню лет может 20 назад было модным в интернетах полоскать Джона Кармака, типа мегатекстура плохая идея, и то не так, и это не эдак, да и вообще пишет на C, хотя давно пора на C++ ...
По факту его наиболее популярные продукты (wolf, doom 1-2, quake 1-3), легко портировались на множество аппаратных платформ (как раз благодаря "чистому" C и архитектуре без лишних премудростей), ресурсов потреблял не много, багов особо нет. По мне качество высокое, даже не "залезая под капот", чисто как для потребителя.

Полагаю тема окончательно исчерпала себя, еще несколько сообщения назад.

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

4>Допустим у меня есть сервис, разработанный в срок (даже чуть раньше), который обрабатывает несколько 100K транзакций в сутки, в процессе обработки ничего нигде не теряет, аппаратных ресурсов потребляет мало и хлопот в его обслуживании/сопровождении никому не доставляет — качество высокое. Не стоит на ровном месте "квантовую механику" устраиваить.

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

I>Что бы дать гарантию, что сервис ничего нигде не теряет, замерить ресурсы, посмотреть насколько он хлопотен в обслуживании и сопровождении — для этого нужен четко выстроеный процесс. Гарантия сама себя не даст

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

Более-менее гарантии можно дать только научными методами и прочим rocket science. Но наука и "мягкие навыки" живут в перпендикулярных измерениях.

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

I>Это если программист — джуниор. Ты несешь ответственность за всё, что делаешь — коммуникация, координация, следование плану и тд.
I>Твоё работу не вмергали — а чего ты молчал? Ждал, что менеджер будет тебе должен?
I>Почему не в курсе, что ты чего то делал? Снова менеджер должен?
I>Уткнулся полировать минорный компонент — ты не в курсе, где у вас приоритеты и весь объём работ?

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