Советы по карьере, данные техническим директором

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

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

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

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

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

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

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

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

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

Делайте вещи, которые оказывают влияние на вашу компанию.

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

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

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

Сосредоточьтесь на изучении лучших практик по структуре кода и написанию тестов.

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

Не гонитесь за «отсутствием баланса между работой и жизнью». Он относителен.

Когда мы видим, что кто-то работает с 9 до 8, мы можем подумать: «О, это ужасно. Неужели компания не знает, что такое баланс между работой и личной жизнью?». Однако если в компанию придут инженеры с типичной культурой работы «996», они могут почувствовать, что у них самый лучший «баланс между работой и жизнью». Что еще более важно, мы всегда должны фокусироваться на том, чему я могу научиться в этой компании. Как я могу повлиять на работу или повлиять на других? Если баланс между работой и личной жизнью — это единственное, на что вы обращаете внимание в 20 лет, то, возможно, вы прохлаждаетесь у Netflix в самый пиковый период роста вашей жизни. Если вы хотите быть здоровым, то в 20 и 30 лет упорно тренируйтесь, чтобы потом не жалеть об этом.

Он также передал мне это послание:

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

Реальность такова, что инженерия — это больше размышления, тестирование, попытки, чем написание/делание.

Наконец, он также поделился схемой карьерного роста менеджера по разработке программного обеспечения с этого сайта: A framework for Engineering Managers.

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

Следите за мной на Medium

Оцените статью
devanswers.ru
Добавить комментарий