Ответ на предложение по исправлению ошибок, в котором говорилось, что нужно просто сообщать об ошибках (не предлагать решения). Это типично? [закрыто]

Нет, это не обычно. Однако вы столкнулись с довольно распространенным зверем, элитарным разработчиком с суперправами. Он умнее всех в своем уме и имеет право быть грубым по той же причине. У него есть что-то против Морти. По возможности избегайте его и двигайтесь дальше.

Хотя он, безусловно, имеет право самостоятельно исследовать проблему, цивилизованным ответом будет: «Спасибо за предложение, я его изучу». Между ними может быть уже существующая неприязнь, или он может быть просто диким, но в любом случае, хотя такое поведение известно в технике, оно неприемлемо или «обычно».

Как разработчик, я нахожу первый отчет очень полезным. Никаких длинных объяснений, никакой длинной трассировки valgrind для чтения. С этим патчем я мог сразу увидеть, в чем проблема, и если бы я недавно работал над этим кодом, я бы, вероятно, знал, правильное ли это исправление или нет, даже не проверяя код. Так что я бы просто ответил: «Спасибо, что поймали», или «Спасибо, этот указатель не должен быть общим, но я знаю, как следует решить проблему теперь, когда вы обратили на нее внимание» или что-то в этом роде.

Также я не улавливаю никакого чувства превосходства в сообщении.

Теперь CC'ing всех может быть, а может и не быть плохим. Код может быть чем-то, о чем знают и другие, поэтому, если список получателей CC достаточно короткий, это хорошо. Почта достаточно короткая, и по патчу все сразу могут понять, должны они быть заинтересованы или нет, потратив лишь немного времени. Однако, если есть люди, которые не связаны с этой базой исходного кода в CC, то это было неуместно.

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

Чтобы ответить на вопрос заголовка. Тон Морти, представленный в вопросе, на мой взгляд, профессиональный и нормальный. Тон Рика... к сожалению, тоже не такой уж необычный, но к сожалению. Однако у всех бывают плохие дни, поэтому я не буду дальше анализировать ни одно анонимное сообщение. Это может быть плохим признаком (и выглядит так, TBH), или это может быть частью вполне приличной культуры на рабочем месте, к которой вам просто нужно привыкнуть.

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

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

Принцип задачи XY довольно прост:

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

В качестве наглядного примера:

• X = я хочу отсортировать эти данные Excel.
• Y = я могу написать приложение для сортировки данных и сохранения файла.
• Z = Я должен научиться использовать функцию сортировки Excel.

По сути, это то, что произошло в электронном письме Морти. Рик не может обозначить запрос как Y или Z, потому что Морти не объясняет X. Объяснение X важнее, чем предложение решения Y/Z, поскольку Рик способен найти Z, когда он знает X, но он не может. не угадать X из ниоткуда.

Это проблема X:

утечка памяти в некоторых частях кода платформы

Обратите внимание, что это довольно расплывчато. В чем проблема? Где это произошло? Когда это произошло? Был ли это пограничный случай?

Затем Морти предлагает Y-решение. Поскольку мы не знаем специфики X, у нас нет возможности оценить, является ли Y подходящим решением для X.

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

Подумайте об этом так: вы офицер полиции. К вам подходит мужчина и говорит: «Мне нужно, чтобы вы арестовали этого человека» (Y).

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

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

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

Не обращая внимания на скрытую напряженность между ними, общую проблему общения или стандартный тон в вашем доме, я хочу сосредоточиться на вашем вопросе:

Этот тон необычен для технического рабочего места?

Нет , этот тон не совсем необычен.

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

2. Это клише, но да, есть и такие задроты, у которых просто плохие социальные навыки, так что вам лучше научиться иметь с ними дело и не принимать это на свой счет.

3. Для многих программистов «их» код — это их детище. Указание на некоторые неоспоримые ошибки — это одно, а возня с ними может просто запустить некоторые защитные механизмы.

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

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

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

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

Но с тем, как он это выразил... он был полным придурком.

Понятно, что не все с этим согласны, но по ИМО это нормальный ответ, не принимайте это на свой счет .

Это простое для понимания электронное письмо, он мотивирует свои причины, по которым он предпочитает не слышать ваше решение (не потому, что это ваше решение, а потому, что он хочет начать с чистого листа).

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

Я согласен, что это можно было бы сформулировать немного более вежливо, но опять же, программист часто просто говорит то, что он имеет в виду, без всех этих нагруженных интерпретаций (что не оправдание, но может быть объяснением).

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

Здесь виноваты обе стороны.

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

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

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

К сожалению, такая токсичная культура распространена в компаниях-разработчиках программного обеспечения в Соединенных Штатах. Многое было написано [1] [2] [3] и сказано о том, как определенный тип инженеров-программистов относится к другим, особенно к не-программистам и людям, которые не соответствуют их стереотипу инженера-программиста.

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

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

Нормальность довольно субъективна, тем более что вы понятия не имеете об истории этого рабочего места.

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

Возможно, Морти специально создал «разумное» электронное письмо, надеясь спровоцировать Рика.

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

Что бы ни случилось, просто не позволяйте этому распространиться на вашу личность.

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

это нормально в технологических компаниях?

Это совершенно нормально для любой компании практически в любой отрасли, не только в сфере технологий.

Вообще говоря, электронное письмо, которое было разослано всем членам команды разработчиков, в котором:

• указал на предполагаемый недостаток (« Кажется, я обнаружил утечку памяти...»)
• заявил, что предполагаемое решение было найдено («Я считаю, что нашел источник и проблему ...»)
• представил подробный список исправлений, которые необходимо реализовать

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

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

Организационные отношения Рика и Морти

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

• Рик старше Морти
• Морти старше Рика
• Рик и Морти равны

Рик должен получать указания от Морти?

• Нет? Тогда Рик имеет право сопротивляться
• Да? Тогда нет необходимости копировать всех. Рик все еще имеет право говорить Морти, как он лучше всего выполняет свою работу.

Ситуация ничем не отличалась бы, если бы...

• Медицинский. Доктор Оз говорит доктору Но, что он поставил диагноз пациенту доктора Но и должен сделать X, Y и Z, не сообщая доктору Ноу симптомы.
• Автомобильный. Инженер 1 сообщает инженеру 2, что в конструкции подвески инженера 2 обнаружена проблема, и решение заключается в том, чтобы приварить выступ A к прорези B без предоставления данных испытаний, чтобы показать проблему.
• Техническая поддержка — Технический специалист 1 сообщает Техническому специалисту 2, что есть проблема с системой Технического специалиста 2, и решение заключается в установке исправлений A, B и C без предоставления сообщений об ошибках, указывающих на проблему.

TL;DR

Суть в том, что человек, ответственный за фактическое исправление, говорит человеку, что ему нужно для правильного выполнения работы. Единственный человек, который потенциально «выходит за рамки», — это Морти из-за его пассивно-агрессивного поведения, когда он копирует всех.

Это происходит каждый день в любой отрасли. В этом нет ничего нового или необычного.

--- a/spaceship/DoBattle.cpp  
+++ b/spaceship/DoBattle.cpp  
 vector<part> parts = getSpaceShipParts();  
+shared_ptr<SpaceShip> p = new SpaceShip(parts);  
-SpaceShip * p = new SpaceShip(parts);  
 engageInBattle(p, enemy); 

К сожалению, это изменение действительно исправляет ошибку (притворяется, что тест valgrind является адекватным), но оно вносит нечто нежелательное, борьбу за философию кода. Если вы не являетесь постоянным участником, не ввязывайтесь в споры о философии кода.

Чтобы избежать битвы за философию, вместо этого следовало отправить это. Да, это объективно хуже, но соответствует стилю уже существующего кода:

--- a/spaceship/DoBattle.cpp  
+++ b/spaceship/DoBattle.cpp  
 SpaceShip * p = new SpaceShip(parts);  
 engageInBattle(p, enemy); 
+delete p;

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

1) Коммуникация: OP делает вид, что это стандартная практика - копировать остальную часть команды разработчиков. Я никогда не вижу причин не включать остальную часть команды разработчиков в проблему/решение, которое затрагивает всех.

2) Проблема/Решение: Не вижу здесь ничего плохого. Это должно быть сделано с помощью запроса на вытягивание, но если предположить, что здесь это невозможно, все в порядке.

3) Ответ: С ним столько всего не так, что я даже не знаю, с чего начать.
а) «Я не читаю предлагаемые исправления»: это просто ужасно. Всегда читайте предлагаемый код. Есть неплохой шанс, что это лучше, чем все, что вы можете придумать...
б) «Мне нужно подождать несколько дней, прежде чем я смогу придумать решение»: Позвольте мне перевести это: «Мне нужно подождать несколько дней. прежде чем я смогу полностью проигнорировать проделанную вами работу и отказаться от вашего решения Я не только потрачу время на реализацию решения, но и потрачу больше времени на поиск решения проблемы, которая была решена (с помощью кода, который вы написал, что буду отбрасывать)"
в) "увидеть, в чем реальная проблема, и посмотреть, какое должно быть исправление": протестировать. Протестируйте его, чтобы увидеть, есть ли проблема. Затем проверьте его, чтобы увидеть, была ли проблема решена. Вы ничего не получите, придумав свое собственное решение , которое нужно протестировать , вместо того, чтобы тестировать предложенное решение, чтобы увидеть, все ли оно исправит. Если это не решит проблему , вы можете попытаться найти исправление для предлагаемого решения или решить проблему в целом.

В моей компании я бы отправил ответ своему менеджеру немедленно и без комментариев. Это просто неприемлемо.