Как сохранить мотивацию, когда кажется, что старших коллег нет?

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

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

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

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

1. Во-первых, осознайте, что вы не одиноки. Посмотрите вокруг этого форума. На самом деле есть много вопросов, похожих на ваши , хотя большинство из них менее прямые. На самом деле у меня был опыт найма, потому что я знал лучшие практики, но мне вообще не разрешали применять лучшие практики.
   Я думаю, что легко сформировать мировоззрение, в котором вы представляете, что ваше представление о совершенстве важно для всех. В конце концов, в школе вас учат определенным вещам как лучшим практикам, а блоггеры, на которых вы смотрите, воспринимают эти идеи как прочитанные. Но этот мир невидим для многих «средних» разработчиков, и даже те, кто знает о нем, могут не считать его таким важным, как вы. Однако простое знание того, что вы не сумасшедший, что другие люди сталкиваются с кирпичными стенами, когда хотят реализовать все эти хорошие вещи, поможет вам сохранить рассудок.
   Это не означает, что вы должны потерять драйв: не делайте этого. Моя полностью выдуманная оценка состоит в том, что она действительно есть у 25% разработчиков. В конце концов, вы будетенайдите место в жизни, где стремление работает на вас, а не расстраивает вас, и когда вы это сделаете, оно будет вознаграждено так, как никогда не испытают эти 75% разработчиков (это может быть или не быть финансовым вознаграждением).

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

3. Рассмотрите проблему с других точек зрения . Одна вещь, которую мой босс часто говорит мне, это то, что его даже не волнует, быстрее ли делать что-то одним способом, а не другим. Чего он действительно хочет, так это иметь точное представление о том, сколько времени это займет. Если вы всегда делаете что-то одним и тем же образом, это достигает цели для большинства людей.
   Глядя на вещи с другой стороны, пробуя радикально иной подход, даже если это лучшая практика, влечет за собой значительный риск того, что вы можете не уложиться в срок. С этой точки зрения пробовать подходы, отличные от проверенных и верных, на самом деле немного неэтично — вы делаете что-то для своего психического здоровья, что может быть не очень хорошо для здоровья бизнеса.
   Многие разработчики и менеджеры не осознают, что хороший код на самом деле позволяетделать более надежные оценки . Однако, поскольку вы закончили школу всего два года назад, рассмотрите возможность того, что вы, возможно, еще не готовы писать такой код, и если вы потратите время на его изучение, это может привести к тому, что компания не уложится в некоторые ключевые сроки, даже если это здорово. для тебя.

4. Работайте на перемены . Добавьте немного скина в игру и потратьте немного своего личного времени, чтобы собрать демонстрацию методов, которые, по вашему мнению, должны быть реализованы. Когда вы делаете презентацию, будьте очень осторожны, чтобы не сказать ничего, что звучит как критика кого-либо, и постарайтесь не говорить «эта техника плоха». Вместо этого скажите: «Я думаю, что если бы мы сделали X, это сэкономило бы нам на 30% или больше времени, затрачиваемого на выполнение задачи Y, по сравнению с тем, что мы делаем сейчас». Придерживайтесь этой некритичной, не обвиняющей стратегии, даже если вам задают наводящие вопросы вроде: «Но я думал, что мы уже используем передовой опыт. Почему мы этого не делаем?» Я следовал этой стратегии и получил зеленый свет на переписывание всей нашей кодовой базы.
   Сделав это, вы сможете создать достаточное количество прототипов, чтобы продемонстрировать, что то, что вы не самый опытный член команды, не означает, что вы не можете писать надежный код. И вы можете узнать из этого достаточно, что даже если вам скажут «нет», вы сможете лучше писать код такого типа в будущем (на этой или другой работе).
   Вам могут сказать «нет», но люди запомнят, что вы отстаивали свою позицию. Это может немного сдвинуть иглу, поскольку вы сказали, что не все немотивированы. Если ты действительноверьте, что это лучший способ сделать что-то, не отпускайте его, но будьте мудры в том, как вы настаиваете на проблеме. Например, когда я вернулся из отпуска и меня попросили внести изменение, которое я не мог сделать, потому что сайт был изменен таким образом, о котором я не мог знать, я указал своему начальнику, что если сайт находился под контролем версий, я мог заглянуть в журнал и просто увидеть, что произошло. Но я бы не стал делать такой комментарий в присутствии других сотрудников. Комментарии такого типа могут показаться язвительными, поэтому используйте их с осторожностью и только в разговоре один на один. Вероятность того, что кто-то посчитает его язвительным, возрастает в геометрической прогрессии в зависимости от размера аудитории.

5. Стройте поддержку . Сознательно взращивайте своих «опытных и действительно умных» коллег. Сходите вместе на обед и обсудите, что вас беспокоит (в позитивном ключе, например: «У меня была эта идея…»). Если они знают, что вы думаете, и вы знаете, что они думают, то, когда вы находитесь на собрании, весьма вероятно, что они естественным образом присоединятся к вашему мнению, или наоборот. На самом деле, вы должны искать возможности поддержать любого, кто делает что-то вроде предложения передового опыта, независимо от того, знали ли вы ранее, что этот человек заинтересован в передовом опыте или нет.
   После того, как вы создали хорошую базу среди разработчиков-единомышленников, посмотрите, сможете ли вы развивать тех, кто, по вашему мнению, не мотивирован. Во-первых, они могут вас удивить. Во-вторых, они'

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

7. Это займет время. Однажды у меня был босс (который был на грани ухода на пенсию), который сказал мне: «Эми, тебе не нужно так злиться. Просто делай то, что делаешь, и в конце концов люди начнут понимать, что ты во многом права». Чтобы завоевать доверие, требуется время, и команды не меняются в одночасье только потому, что вы указываете, что они должны это делать. Дайте своим идеям время впитаться и продолжайте их внедрять, и, может быть, со временем вы оглянетесь и поймете, что многое изменилось к лучшему за меньшее время, чем вы боялись. Это случилось со мной :).

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

........

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

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

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

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

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

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

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

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

Удовлетворенность клиентов также является чрезвычайно важным фактором. Если выбирать между лучшим кодом и лучшим пользовательским интерфейсом, UX всегда побеждает, и так и должно быть. Опять же, самый большой решающий фактор — это когда лучший код приводит к лучшему UX в будущем — будет ли влияние лучшего кода достаточным, чтобы в конце концов сделать его дешевле? Хороший код часто является инвестицией, а не чем-то ценным из коробки; редко вы найдете возможность, когда хороший код дает лучшую эффективность при выполнении исходной задачи (обратите внимание, что я говорю о «плохом» коде, созданном хорошими программистами — если ваши программисты просто плохие и неряшливые, вам не повезло); окупаемость обычно приходит позже, если вообще приходит.

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

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

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

Обычно я думаю о времени или деньгах. Перевод вещей в деньги очень помогает в расчетах затрат и выгод. Это заняло у меня немного больше времени, и я получил некоторый опыт. Сколько бы я заплатил за эти знания, стоило ли оно того? Это сэкономит мне время в будущем — этого достаточно? Сколько будет стоить, если я этого не сделаю, и это окажется плохим решением в будущем? Крайне важно знать, сколько времени было потрачено на исправление ошибок в исходной задаче, иначе восприятие будет крайне искаженным. Если что-то заняло у меня 4 часа, как и предполагалось, но затем я потратил 20 часов на исправление ошибок, должно быть видно, что моя оценка была далекой.

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