Предыстория: Я недавний выпускник и разработчик программного обеспечения. В компании, в которой я работаю, относительно небольшая команда из 8 человек. Я новичок в команде и работаю здесь 10 месяцев.
Я хорошо лажу с одним из старших разработчиков, когда говорю о чем-то, кроме специфики кода. Мне нужно часто обращаться к нему за поддержкой, так как он довольно хорошо знает .NET. Когда мы говорим о разных способах решения технической проблемы, с которой у меня возникают проблемы, возникает заметный конфликт и напряжение. Это потому, что у нас обоих разные способы ведения дел и разный фундаментальный мыслительный процесс. Только один пример (из многих), где мы думаем по-разному, это то, что я был обучен с большим вниманием к объектно-ориентированному дизайну, используя наследование, в то время как он видит данные так, как они вписываются в таблицу, и даже задается вопросом, почему вы должны использовать наследование, а не просто простая ссылка на родительский объект.
Всякий раз, когда я пытаюсь вежливо сказать что-то вроде «Я понимаю вашу точку зрения, но я все еще думаю, что это лучший подход, потому что xy z», он не понимает мою точку зрения и даже становится немного более настойчивым в том, что метод он рекомендует лучше, и это вызывает повышенное напряжение. Я понимаю, откуда он взялся, и я вижу преимущества того, чтобы делать это по-своему, однако я вижу больше преимуществ в решении проблемы по-своему.
Итак, мой вопрос заключается в том, как мне поступить с ним таким образом, чтобы мои отношения с ним улучшились, или это лучший подход, чтобы просто установить некоторое пространство между ним и мной, когда дело доходит до технических разговоров, и в результате препятствовать тому, чтобы он стал ценный наставник?
ПРИМЕЧАНИЕ. Как уменьшить разрывы в общении с коллегой, у которого другой стиль работы? <-- Аналогичный вопрос, но больше об общении, которое не является проблемой.
РЕДАКТИРОВАТЬ: Этот человек не является моим начальником, он просто более опытный коллега, мой начальник (у меня их 2...), который отвечает за мою работу, работает и думает так же, как я, когда дело доходит до решения проблем. . Это означает, что реализация решения так, как предлагает этот другой разработчик, приведет к тому, что мне придется вести ту же дискуссию с моим боссом, но я буду отстаивать реализацию, в которую я на самом деле не верю. Мой босс не очень хорошо знает .NET. хорошо, однако, поэтому он не может помочь с техническими вопросами/вопросами реализации, которые у меня есть.
РЕДАКТИРОВАТЬ 2: я изменил вопрос и удалил много технических деталей в соответствии с предложением в комментариях.
Ваша решимость использовать ООП там, где это может не иметь значения, и его решимость использовать настоящую базу данных там, где это может не иметь значения, — две стороны одной медали. Вы лучше поладите с ним, если будете помнить, что это ремесло, а не наука, и два разработчика часто подходят к одной и той же проблеме с разных сторон, и ни один из них не ошибается. Выбор наилучшего решения зависит от того, как оно будет использоваться, и от того, сколько усилий потребуется, так или иначе... и последнее зависит от человека к человеку. И иногда правильный ответ — это не тот, который лучше технически ИЛИ тот, который вы предпочитаете, а тот, который будет легче поддерживать.
Вместо того, чтобы зацикливаться на том, кто прав, сосредоточьтесь на том, чтобы узнать, почему делается предложение и каковы компромиссы.
И, если возможно, не ссорьтесь из-за того, что не имеет значения. Кто прав, имеет меньшее значение, чем выполнение работы.
Я понимаю вашу точку зрения, но я все еще думаю, что это лучший подход
«Лучше» в этом предложении — чисто вымышленное измерение, по крайней мере, для него. Вы (оба как команда) никогда не устанавливали стандарты «хорошо», поэтому предположение о том, что что-то «лучше», не имеет общей основы.
Вас учили, что ООП «лучше». Но если это было хорошее образование, вас также научили, почему . Так что делай дело. Что бы предложило ваше решение, чего бы не предложило его. Что можно было сделать с вашим программным обеспечением, чего нельзя было сделать с его?
Если вы представите ему вероятное экономическое обоснование того, что ваше решение будет реализовано за меньшее время или за меньшие деньги, то он увидит, что оно действительно «лучше». Если вы не можете привести пример, почему ваш подход «лучше», возможно, это не так. ООП и наследование — это инструменты для решения проблем. Может быть, это не правильная проблема для вашего набора инструментов? С тем же успехом вам может понадобиться второй (и третий, и четвертый...) набор инструментов.
Я хотел бы предложить вам начать разговор с ним в позитивном настрое — например, я могу многому научиться у этого старшего разработчика и т. д. Почему бы вам не узнать, почему его метод лучше вашего, задав несколько вопросов? по его методу.
Я думаю, что было бы неплохо вспомнить некоторые соответствующие «правила Дейла Карнеги» здесь:
1) Не критикуйте, не осуждайте и не жалуйтесь (не пробуя правильный подход — я считаю, что вышеупомянутый подход — один из них);
2) Вызвать в другом человеке страстное желание (заставить его думать, что он тоже вносит свой вклад в ваш проект/решение).
Если ваш подход ООП лучше, представьте пару вариантов использования в вашей ситуации, когда подход ООП работает лучше, чем подход базы данных/таблицы (который выглядит как делегирование). Если варианты использования достаточно важны, это может помочь вашему наставнику прийти к вашему выводу.
Поскольку он наставник, возможно, вам также следует попробовать его подход от начала до конца. Вы можете узнать, что его способ лучше, или ваш способ лучше, или что оба пути — это просто два разных способа решения одной и той же проблемы. Но ваши знания будут основаны на опыте. И если вы научитесь обоим способам, то в следующий раз, когда вы попросите его о помощи, вы сможете без труда перевести его предпочтительный подход в свой предпочтительный подход.
У меня была ситуация, когда я написал кусок кода, используя библиотеку Ruby Enumerable с каскадными блоками map/reduce, чтобы выполнить мучительную работу по обработке данных в наборе данных. Мой босс не оценил преимущества использования каскадной карты/уменьшения (более функциональный стиль программирования) и пожаловался, что код трудно читать. Я возразил, сказав, что если бы он мог написать код более лаконично, используя более императивный стиль кодирования, то я бы переключился. (Я сказал это только потому, что знал, что предыдущие попытки решения подобных задач имели утроенный объем кода, и он был хрупким). Мой подход до сих пор стоял, потому что он работает, и потому что он еще не написал код для решения той же проблемы в императивном стиле программирования. В этом случае я попробовал два разных метода, поэтому смог сформулировать различия и написать код.
Майлз
Брандин
Another one of the conflicts was where he was suggesting creating a database to store data on disk for an ad-hoc solution that would only be used by me<-- Я не понимаю этого конфликта. Если решение предназначено только для вас, то какое значение имеет мнение старшего? OTOH, если продукт предназначался для использования другими, то вклад вашего старшего нельзя игнорировать, даже если он «неправильный».Адриан773
Адриан773
Брандин
You: I was thinking of using X for this. What do you think? Him: Hmm... I would definitely use Y for this.. Это не «конфликт», если вы не пытаетесь аргументировать свою точку зрения (без причины). Это просто два разных мнения. Если вы хотите сделать X, просто сделайте это. Вам даже не нужно говорить ему об этом.Адриан773
Me: I was thinking of using X for this. Have you already done X and if so, what library did you use? Him: I haven't done X, what is this for? Me: Its for Y. Him: Oh, Z would be a better solution to Y. Me: Really? That wouldn't have A or B and X has C and D. Wouldn't that make X a much better solution? Him: Nah, A and B are negligible.я мог бы продолжить отсюда, но это было бы почти то же самое, пока мне не стало бы напряженно и трудно просто игнорировать его и уйти, не будучи грубым.Брандин