Мои сожаления за всю мою карьеру программиста

Прежде всего о том, что я называл себя «инженером-программистом»

От переводчика:
We who cut mere stones must always be envisioning cathedrals. Мы, рубящие простые камни, всегда должны видеть за ними соборы. Все мы помним эту замечательную цитату из книги Эндрю Ханта «Программист-прагматик. Путь от подмастерья к мастеру». Пост ниже, на мой взгляд, именно об этом. Его автор – технический лидер и архитектор Дейв Таублер, рассказывает о том, как развивалась его карьера и взгляды на свою работу в целом: от разочарования в маркетинге до того, к чему пришёл сегодня, спустя много лет. Автор делится некоторыми рекомендациями, которые считает полезными для развития карьеры, и, как и написано в заголовке, рассказывает о том, что изменил бы в своей собственной карьере, если бы только мог.

Моя карьера началась не в разработке ПО, а в маркетинге. Я творческий человек и подумал, что искусство слоганов и созвучий мне подойдёт. Но мир маркетинга оказался более механическим, чем я себе представлял. Удивительно (а может и не удивительно), но я понял, что программирование – до того времени хобби – давало мне выход творческой энергии, которого я так жаждал. Так что после пары мест работы в маркетинге я нашёл работу в веб-разработке. Эта работа стала началом моей карьеры инженера-программиста, с тех пор к маркетингу я не возвращался.

Профессия была прекрасной. Она хорошо оплачивалась, конечно, и я удерживался на работе во времена спадов экономики. Веб-разработка позволила мне поработать с разными компаниями и познакомиться с прекрасными людьми. И давайте признаемся себе: программировать – это весело, так что я мало о чём сожалею. Но кое-что, о чём я сожалею, всё же есть. А именно:

Я хотел бы не рассматривать себя как «инженера-программиста».

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

Я думал о себе, как о препятствии, которое нужно устранить

Я привык думать о себе, как о включателе [прим. перев. – конечно же, enabler – это «a person or thing that makes something possible»: человек или вещь, которая делает что-либо возможным. Но в этом случае автор с сожалением говорит о себе как об элементе некоей цепи, а значит, именно здесь уместен такого рода буквализм, он ясно отражает настроение и замысел сказанного], необходимом звене в цепи разработки продукта, которое воплощает концепции в реальность. Для бизнеса это так же важно, как вода для жизни. Но в последнее время я уже не столь уверен в таком самоопределении.

Подумайте о том, как работает разработка продукта. Кому-то в голову приходит великолепная идея. Например, предоставить финансирование людям, которые не могут получить кредит, или помочь мастерам своего дела продавать их труд в сети. Но, чтобы воплотить идею в реальность, автор идеи нуждается в ком-то другом, у кого есть опыт и навыки, чтобы реализовать идею. Именно здесь и появляюсь я как инженер-программист. Просто заплатите мне, и я поспособствую вашей идее. Верно? Да. За исключением того, что до меня дошло: я на самом деле не помощник. Я – помеха. Я – то, что в действительности стоит между идеей и её воплощением. То, что нужно убрать. Другими словами: как вы думаете, хотят ли люди нанимать кого-то ещё, чтобы реализовать идеи? Если бы они могли, скажем, просто нажать кнопку… не выбрали бы они вместо этого кнопку?

Конечно, такой кнопки нет. Ещё нет. Но индустрия медленно движется по направлению к ней. Давным-давно, чтобы сделать простой сайт, нужно было нанимать кого-то вроде меня. А сейчас с инструментами типа Wix почти любой может перетаскиванием проложить себе дорогу к довольно продвинутому сайту… Программист не требуется! Платформы разработки low-code также сокращают необходимость в софтверных инженерах.

Даже сами языки программирования постепенно (хотя и медленно) упрощаются; писать становится проще. В конце концов, в чём смысл языка программирования, если не в том, чтобы преодолеть разрыв между человеческими инструкциями и тем, как инструкции выполняет компьютер? Не поймите меня неправильно. Я не думаю, что спрос на инженеров-программистов вскоре исчезнет. Но… обеспечивать себя навыками, ценность которых постепенно снижается? Такая карьера стала казаться мне ненадёжной. И это привело меня ко второй проблеме:

У меня развился неоправданный цинизм

Когда я только начинал, Java была горячей новинкой. Поэтому я нырнул в неё с головой. И я помню некоторых твердолобых программистов на C и C++, которые совершенно ненавидели Java. Конечно, у них были причины. Но мне казалось, что эти причины во многих случаях просто маскировали экзистенциальную угрозу, которую чувствовали программисты. Умение программировать достались им большими трудом. Затем появилась Java, которая абстрагировала многие трудности С и C++. Вдруг оказалось, что их работу может сделать целый поток новых программистов.

Быстро промотаем несколько лет вперёд, когда я начал чувствовать, что оказался на месте этих программистов. Рефлекторно я находил и акцентировал недостатки в любом языке или технологии, которые якобы были проще, чем те, что знал я. Конечно, у меня были и мои причины делать это. Но зачастую они были больше похожи на рационализацию, которая создаётся позже. Так что же со мной случилось? Прошло очень много времени, я пустил корни в свой любимый набор инструментов программирования и не хотел отказываться от него. Я видел свою цель не в применении технологий для того, чтобы решать проблемы, а в применении конкретных навыков разработки программного обеспечения, которые уже отточил. «Если эти навыки станут ненужными, не нужны будут и мои цели», – так я думал. И вот, я построил оборонительное заграждение из цинизма. То самое, над которым в других программистах, много лет назад, я недоумевал.

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

Я ограничил профессиональный кругозор

За всю карьеру я работал во многих отраслях. Социальные сети, стриминг музыки, финансовые технологии (финтех) и даже редактирование фотографий. Хотя у меня есть опыт работы во многих отраслях, я не всегда хорошо разбираюсь в какой-то конкретной сфере. В то же время я заметил, что некоторые мои коллеги-инженеры оставались в одной отрасли всю свою карьеру. Один коллега, например, питал страсть к фотографии, так что специализировался на ПО редактирования фотографий. Другие коллеги всю карьеру посвятили финансовым технологиям.

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

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

Карьерный рост

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

Но, чтобы выйти за рамки роли старшего инженера, мы должны понимать бизнес. Независимо от того, идём ли мы по маршруту Менеджер/Директор или Главный инженер/Архитектор, мы начнём принимать решения на высоком уровне от имени компании. Понятно, что, когда я впервые занял руководящую должность, мне было некомфортно сосредоточиться на проблемах бизнеса. Но, когда я привык думать от имени бизнеса, я почувствовал свободу. Как будто открыл для себя совершенно новый набор навыков. Если вы нацелились ещё выше, внимание ещё более сосредотачивается на бизнесе. Опыт инженеров в отрасли становится жизненно важным. А что те мои коллеги, о которых я рассказал? Многие из них полностью покинули мир инженерии и получили повышение в сфере бизнеса. Некоторые позже ушли, чтобы основать свои стартапы в финансовых технологиях

Карьерное счастье

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

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

Как уйти за пределы программной инженерии

Эта история может не вызвать отклика у всех, кто пишет программы, чтобы зарабатывать на жизнь. Есть много читателей, которые любят свою отрасль больше, чем свой язык программирования. Кто достаточно комфортно прыгает с C# на JavaScript и оттуда на Go. Кто без проблем отказывается от того, чему уже научился, когда появляется решение проще. Но если этот рассказ резонирует с вами, читайте дальше. Со временем я изменил отношение к своей карьере, и нет причин, по которым вы не можете сделать то же самое. Ниже я привожу советы, которые нахожу полезными.

Погружайтесь в другие технологии

Что вылечит от нежелания расставаться с технологиями, к которым мы привыкли и на которые полагаемся? Погружение в другие технологии. Проще всего совершить такое погружение в сайд-проекте: программном обеспечении, которое мы создаём самостоятельно, когда закончились рабочие часы. Главное – глубоко погрузиться в незнакомый нам язык. Я говорю о двух вещах:

• О выборе совершенно другого языка за пределами нашей зоны комфорта. Например, если вам удобно работать с Java, не переключайтесь просто на Kotlin; попробуйте вместо этого Go, Python, Rust или NodeJS.
• Об определении сложного в смысле завершения проекта. Не просто работайте с туториалом. Поставьте перед собой высокую цель, которая заставит вас по-настоящему изучить язык, чтобы достичь её.

В самом деле, поставьте перед собой цель выучить новый язык так хорошо, чтобы вы могли получить работу с этим языком за деньги. Много лет назад я так и сделал. Я был архитектором программного обеспечения, сосредоточенным на бэкэнде Java. Но в качестве сайд-проекта я помог другу создать приложение для iOS и настольное приложение для Mac. Это дало мне навыки, чтобы позже присоединиться к известной компании, которая занималась стримингом музыки, чтобы помочь им создать приложение для iOS.

Нужно больше, чем просто разные языки программирования: нужно погрузиться в инструменты, которые не зависят от языка. Например, я по максимуму запачкал руки в Docker и Kubernetes. По мере того как я лучше и лучше разбирался в развёртывании и оркестровке образов, я стал меньше беспокоиться о том, что содержится в этих образах.

Или возьмём облачные технологии. Раньше я преуменьшал роль «бессерверных» технологий, потому что не имел опыта работы с ними. Но за последнее я объял и их. Например, в одной из недавних работ я попытался внедрить AWS Lambda в нашу архитектуру микросервисов. И работал над сторонним проектом, где широко используются GCP Cloud Functions.

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

Сосредоточьтесь на общей картине дизайна

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

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

Станьте человеком идеи

Ранее я представил упрощённый взгляд на то, как рождаются продукты. У кого-то есть идея, а кто-то другой реализует её. Поэтому я подумал: чем быть разработчиком, почему бы не стать автором идеи?

Сторонние проекты

До сих пор целью моих побочных проектов было либо не отставать от моих существующих инженерных навыков, либо изучать новые технологии. По сути, эти проекты составили прославленные упражнения Hello World.

Сейчас я начинаю с самой идеи. Я придумываю что-то, что, как мне кажется, будет полезно, а в идеале окажется чем-то новым. Иногда это идея, которая может превратиться в продукт. В других случаях эта идея полезна только мне. Дело в том, что я сосредотачиваюсь прежде всего на идее.

Затем я ставлю перед собой задачу найти лучший способ воплотить эту идею в жизнь. Возможно, реализация связана с написанием монолитного приложения на Java. Или, может быть, это интерфейс JavaScript/React, поддерживаемый в основном облачными сервисами и сшитый воедино с помощью небольшого количества кода на Go. Может быть, речь идёт о задачах, которые вообще не относятся к программированию.

На работе

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

Такое легче сказать, чем сделать? Может быть. Безусловно, это зависит от желания нашего работодателя отказаться от программирования в очень быстром темпе. Но я обнаружил, что многие компании более чем счастливы, когда инженеры хотят проявить инициативу, чтобы решить проблемы, которые выходят за пределы области написания программного обеспечения. А если наша компания не поддерживает инициативу? Тогда помните, что мы инженеры-программисты… Мы можем позволить себе быть немного разборчивыми в том, на кого работаем.

Если вы хотите погрузиться в другие технологии, как советует автор поста, то мы со своей стороны готовы в этом помочь нашими знаниями, опытными менторами и поддержкой. Будет сложно, но интересно. Ну и не забывайте про всегда активный промокод HABR — который приплюсует 10% к скидке на баннере.

• Профессия Data Scientist
• Профессия Data Analyst