Мягкие навыки для инженеров-программистов

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

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

Не бойтесь говорить

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

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

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

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

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

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

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

Шаг первый - выяснить, в чем проблема. Так что вы скажете что-то вроде «Извините, я не думаю, что мы сможем уложиться в этот срок. Чего вы хотели достичь на тот момент? Возможно, мы найдем другой способ ». И та-да, теперь ты решаешь с ним проблему. Возможно, вы можете предложить ему другую, более простую функцию, или, возможно, будет достаточно нефункционального макета.

Дело в том, что вы превратили потенциально раздражающую ситуацию в головоломку, и если нам есть чем заняться, то это решать головоломки, не так ли? И в довершение всего, они вас за это полюбят!

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

Не соглашайтесь со своим интеллектом, а не со своими эмоциями

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

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

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

Начните с рассмотрения другого человека. Он идиот? Если да, то почему он работает с вами (или почему вы работаете с ним)? Если нет, то, вероятно, у него есть основания для своей точки зрения. Он старше вас? Тогда вы, вероятно, ошибаетесь, поэтому поставьте себя на место ученика и начните учиться.

Тщательно выясните, о чем он думает. Каково его собственное мнение? Чем он отличается от твоего? Где он похож или такой же? Как он пришел к такому мнению? Есть ли у него информация, которой нет у вас, или наоборот?

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

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

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

Не будь ослом

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

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

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

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

Так что распознавайте, когда вы осел, и не делайте этого. Это так просто.

Заключить

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

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

Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсуждать рекламные и спонсорские возможности.

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