Я влюбился в программирование в раннем возрасте. После того, как мой папа купил нам Commodore 16, к нам приехал из Лос-Анджелеса мой дядя-технарь. Он принес с собой книгу по основам программирования, и я начал копировать код и с удовольствием его выполнял. Я не был одним из тех вундеркиндов, которые действительно могли программировать в раннем возрасте. Но что-то щелкнуло внутри меня, и я понял, в чем хочу сделать карьеру. С годами я понял, что я больше склонен к логическому мышлению, и поставленные логические задачи, связанные с программированием, были хорошим испытанием.
На протяжении всей своей карьеры я проводил значительное количество времени, заключая контракты. Быть вовлеченным в различные команды, проекты и отрасли. Постоянные изменения позволили мне пройти через технические роли разработчиков, архитекторов и ведущих команд. Затем я начал знакомиться с механикой вещей, которые должны произойти, прежде чем проект будет одобрен для строительства. Я мог наблюдать за принимаемыми коммерческими решениями и их влиянием на бизнес еще до начала проекта. Я начал получать удовольствие от управления и бизнеса, и мне посчастливилось иметь несколько замечательных менеджеров, которые увидели мой потенциал. Они были готовы возложить на меня ответственность и научить меня моим пробелам.
Это было очень важно для меня. С тех пор до этого момента я слышал замечания или комментарии вроде «вы слишком техничны для руководства» или «вы слишком техничны». Услышать это и увидеть, что большинство менеджерских должностей достаются людям без технического образования, было обескураживающе. Так что наличие поддерживающего менеджера, инвестирующего в меня, — это то, за что я всегда буду благодарен.
Я хотел написать эту статью и поделиться десятью советами для технарей, которые хотят делать больше, чем кодирование. Ваши технические знания могут быть вашей величайшей силой и вашим величайшим проклятием. Все зависит от того, как вы его используете. Я использую принципы кодирования и применяю их к нетехническим ситуациям в управлении. Ниже я представил несколько карт, которые, я надеюсь, будут вам полезны и помогут двигаться в том направлении, в котором вы хотите двигаться.
«Ваши технические знания могут быть вашей величайшей силой и вашим величайшим проклятием».
Нуль. Код комментария. Давайте сначала обратимся к вашему мышлению неуверенности в себе. К сожалению, всегда найдутся люди, которые будут комментировать ваши навыки. Или, что еще хуже, комментарии наносятся сами себе и привязывают вас к себе. Думайте об этом как о запуске анализатора производительности над вашим кодом. Линии, которые появляются красным цветом, указывая на узкое место в производительности, — это ваша неуверенность в себе. Как вы можете ожидать, что возьмете на себя новую роль с мышлением, которое замедляет вашу работу? Все, что вам нужно сделать, это поместить сомнительные методы в отдельный класс. Затем просмотрите и закомментируйте строки кода, создающие экземпляр класса или вызывающие методы. Это может быть постепенный процесс. Одна строка кода за раз. Я бы порекомендовал прочитать или послушать краткие версии книги Тонкое искусство пофигизма (ссылка), чтобы начать правильно мыслить.
Линии, которые появляются красным цветом, указывая на узкое место в производительности, — это ваша неуверенность в себе.
Один. Большая фиксация. Ошибки должны быть самой разочаровывающей и самой полезной вещью в кодировании. Бизнес-проблемы похожи на ошибку кодирования. Основное отличие заключается в вовлеченных людях, которые говорят вам, по какому пути идти и в чем, по их мнению, заключается настоящая проблема. В менеджменте вы просто должны следовать тому же прагматичному подходу, что и в программировании. Задавайте вопросы, которые начинаются в верхней части проблемы, а затем вопросы на следующем уровне. Как будто вы отлаживаете методы и их подметоды. Вы пытаетесь разобраться во множестве фактов и мнений, чтобы найти первопричину проблемы. Как только вы ее увидите, вам нужно потратить время, чтобы понять ее, прежде чем работать над ее решением. Если вы перейдете к исправлению взлома, вы не знаете, каков будет волновой эффект. Не торопитесь, задавайте вопросы, которые хотите задать, и избегайте попадания в случайные кроличьи норы. Если и есть кто-то более устойчивый к преодолению стресса, чтобы найти первопричину проблемы, так это программист.
Если и есть кто-то более устойчивый к преодолению стресса, чтобы найти первопричину проблемы, так это программист.
Два. Взаимная аутентификация. Понятие аутентификации основано на доверии. Люди ничем не отличаются. Вам нужно работать над построением доверительных отношений с людьми в вашей команде и межфункциональными командами. Это временные инвестиции, которые необходимы. Поход на кофе, чтобы узнать кого-то получше, облегчит проблемную дискуссию в будущем. Время, потраченное на построение доверия, имеет очень высокую отдачу. Рекомендую прочитать Скорость доверия Стивена Р. Кови (ссылка) или краткую версию. Он разбивает доверие на 13 логических шагов, которые легко применить в реальной жизни. Как только вы установите доверенное соединение, общение станет более эффективным.
Три. Управления источником. Существует константа в том, что нужно вашей команде. Константа заключается в том, что они хотят чувствовать себя ценными. Они хотят чувствовать, что их работа что-то значит, и хотят работать с замечательными людьми, которые открыты для обмена. Ваша задача — создать среду, в которой это будет процветать. Одинокие волки сделают эту среду очень сложной для создания. Вы должны поговорить с хранителями знаний, чтобы понять, является ли это преднамеренным поведением. Затем помогите научить их преимуществам совместной работы и совместного использования. Как только вы улучшите проверку кода. Вы должны быть преднамеренными, связывая работу, которую они производят, с бизнес-результатами. Например, проверка кода, связанного с пользовательской историей. Иногда они сами не видят соединения, поэтому вам нужно помочь им его отобразить.
Четыре. Переменные. Больше всего мне понравилось то, что люди изменчивы. Когда вы программируете, останавливаетесь на полпути к методу, идете домой и возвращаетесь на следующий день. Код будет ждать вас. За эти 24 часа человек мог пережить все взлеты и падения. У них может быть новая информация, которая изменила их мнение и теперь они менее согласованы. Теперь вы обсуждаете то же самое под другим углом. Код изменился, и это нормально. Это нормально и то, что не собирается меняться. Вы должны использовать свое любопытство и слушать. Задавайте вопросы и обсуждайте различные подходы к решению.
Пять. Методы. Коммуникация является ключом к вашей новой роли. Но в отличие от метода, одни и те же входные данные не будут возвращать одинаковые выходные данные для людей. Вам нужно познакомиться с некоторыми основами профилирования и поработать над адаптацией своего подхода при работе с разными типами людей. Рассмотрим людей с необязательным параметром для их профиля. Параметр профиля может быть одной из четырех основных групп. Любезный, Выразительный, Драйверный или Аналитический. Не заблуждайтесь, думая, что все программисты аналитичны. Кроме того, не делайте ошибку, что вы можете все время подходить к нетехническим специалистам с аналитическим подходом. Вы хотите повысить эффективность своих коммуникационных сообщений. Попробуйте просмотреть эти профили и подумать о том, с кем вы взаимодействуете, и какой подход лучше всего подходит для получения желаемого результата.
Шесть. Разделение забот. Когда вы пытаетесь донести идею или пытаетесь повлиять на людей. Это сложно, когда вы находитесь в комнате с разными людьми. Разные личностные профили и разные конечные цели. Вы бы не добавили несколько элементов логики в один класс, не так ли? Так зачем тебе делать это с людьми? Когда у вас есть идея, не заходите в темный угол, не детализируйте все детали и не назначайте встречу для всех. Начните с создания 1 пейджера и проведите время с отдельными людьми, у которых разные цели или подходы. Получайте информацию и отзывы и повторяйте свой план, имея в виду общую цель. Разделение разговора с 1: M на 1: 1 позволяет вам вести разговоры, которые не будут разбавляться или отвлекаться на кроличьи норы. Старайтесь не усложнять и добейтесь консенсуса на раннем этапе, а затем назначьте встречу.
Семь. Микро API. Ваш успех в новой роли не может быть определен одним монолитным методом кодирования. Мы живем в новую эру микро-API, где у каждого API есть отдельная функция. Совокупность API-интерфейсов, работающих вместе, делает их успешными. Ваш успех ничем не отличается. Не ищите большой выигрыш, чтобы определить ваш успех. Ваш успех — это совокупность маленьких побед, которые работают вместе.
8. КИ/CD. Не ожидайте, что в первый раз, когда вы зарегистрируете свой код, он будет скомпилирован для ствола. Или, что еще хуже, дефект развертывается в производственной среде. В управлении вы будете совершать ошибки. Главное быстро восстановиться. Сосредоточьтесь на том, что не так, и примите меры для решения. Будьте уязвимы и признайте, что допустили ошибку, и в следующий раз вы поступите лучше. Речь идет о постоянном обучении, особенно на ошибках, которые сделают вас лучше в любой роли. Подробнее читайте в моей статье 5 советов по постоянному совершенствованию через неудачи (ссылка)
Девять. Компромисс. Требования изменились, и теперь вы столкнулись с дилеммой. Сосредоточьтесь на скорости, пожертвовав лучшими практиками, или Сосредоточьтесь на лучших практиках и пожертвуйте функциональностью. Компромисс возникает все время во многих формах. В управлении ничем не отличается. Легко рассматривать чужой код вне контекста и критиковать его, говоря, что вы бы разработали его по-другому. Реальность такова, что серая зона — это компромисс. Принятие решения за вашу команду, так или иначе, означает, что оно дорого обходится. Хотя мы думаем, что кодеры бинарны. Таким же образом осуществляется и подход к управленческим/деловым решениям. Вы учитываете окружающую среду, результат, плюсы и минусы решения. Затем выберите направление и двигайтесь вперед.
Я надеюсь, что вы нашли эту статью полезной на пути к своей следующей руководящей должности. Если у вас есть какие-либо другие принципы кодирования, которые будут применяться. Не стесняйтесь обращаться к нам, так как я хотел бы услышать о них.
Для тех, кто не технари дочитал до конца. Когда я обсуждал эту тему статьи. Также было предложено написать реверсивный артикль. Для нетехнических людей, желающих перейти на более технологичную должность. Я возьму это на себя и начну думать об основных препятствиях и о том, как их преодолеть.
