Мой взгляд на то, почему я люблю разработку программного обеспечения, что делает меня отличным инженером-программистом и какой выбор карьеры я сделал.
Быть инженером-программистом — лучшая карьера. Период. Сочетание инженерных аспектов с использованием проверенных передовых практик, подходов и фреймворков с красотой искусства для создания чего-то уникального. Добавьте к этому постоянно развивающийся набор инструментов и бесконечные возможности для изучения чего-то нового, и… ну… я не могу представить, чтобы я занимался чем-то другим.
Это давно назревшее любовное письмо к разработке программного обеспечения. Любовное письмо, в котором я делюсь своим взглядом на то, что делает великого инженера-программиста, и рассказываю о своей карьере и выборе, который я сделал. Я надеюсь, что это может быть полезно для других инженеров, но, по крайней мере, это интересное чтение.
Стать великим инженером-программистом
У меня всегда была страсть к технологиям, компьютерам и созданию сетей с использованием старых компьютеров, которые мой отец принес домой. Моя любовь к разработке программного обеспечения по-настоящему проснулась чуть позже, и я начал работать полный рабочий день инженером-программистом сразу после получения степени бакалавра в области высшего профессионального образования (HBO). Это было около тринадцати лет назад.
Тринадцать лет напряженной работы, практики и обучения с целью стать великим инженером-программистом. За это время, по мере того как я рос как личность и профессионал, менялось мое понимание того, что значит быть великим инженером-программистом. Я считаю, что есть четыре основных навыка, которые составляют основу: решение проблем, страсть, любознательность и работа в команде.
Искусство решать проблемы
Ключевой навык — решение проблем. Что требует двух вещей. Во-первых, это возможность разложить очень сложную большую проблему на более мелкие проблемы, с которыми легче справиться и которые легче понять. Второй — возможность решать эти проблемы с помощью языков программирования, библиотек, шаблонов проектирования, принципов проектирования, таких как solid и grasp, и других существующих методов и структур, которые обычно понимают.
Требуются годы и годы напряженной работы, практики, множества разговоров и обучения на ошибках, чтобы выработать сильный набор навыков решения. Лучшее решение проблемы — это то, которое легко понять другим. Код пишется не для компилятора, а для других людей. Возможность открыть приложение и понять назначение, структуру и философию дизайна позволяет быстро повысить производительность и использовать существующий код чистым и удобным для сопровождения образом.
Важность страсти и любопытства
Хороший инженер-программист будет иметь сильную страсть к программированию и естественное любопытство, чтобы постоянно подталкивать себя к обучению. Истинное чувство мастерства. Определенный перфекционизм и гордость за код, который они пишут. Их код должен быть чистым, элегантным и простым для понимания, чтобы его можно было поддерживать и расширять, а не «просто работать». Они применяют правило бойскаутов «всегда оставляйте код немного лучше, чем вы его нашли» и считают рефакторинг основной частью своей работы. Это звучит как романтическая версия правды, и профессиональная среда не лишена компромиссов. Всегда существует некоторая степень технического долга в существующих кодовых базах, и существует давление, связанное с доставкой. Но хороший инженер-программист всегда стремится к качеству и уравновешивает его коммерческими интересами, а не позволяет неуклонно ухудшаться кодовой базе.
Естественное любопытство инженеров-программистов будет определяющим фактором их роста. Помимо очевидного обучения в блогах, видеоблогах, встречах, конференциях и просмотре баз кода с открытым исходным кодом на Github, вы учитесь и вдохновляетесь людьми вокруг вас.
Даже в концепциях, которые, как вам кажется, вы хорошо понимаете, никогда не закрывайтесь от мнений и точек зрения окружающих. Позвольте мне проиллюстрировать это личным примером модульного тестирования и рефакторинга.
Я работал со старшим инженером-программистом, который даже больше, чем я, был чрезвычайно увлечен чистым кодом и часто проводил рефакторинг, чтобы обеспечить работоспособность кодовой базы. Сначала я был удивлен, узнав, что он не был большим поклонником традиционного модульного тестирования. Итак, у нас состоялся разговор об этом. Его точка зрения заключалась в том, что модульные тесты часто тесно связаны с внутренней структурой программного модуля, поскольку вы ищете наименьший фрагмент кода, который можно логически изолировать. В результате рефакторинг часто требует переписывания или корректировки модульных тестов. Это означает, что рефакторинг требует больше времени и, следовательно, выполняется реже, что негативно влияет на работоспособность кодовой базы.
Вместо этого он предпочитал писать автоматические тесты, ориентированные на общедоступный интерфейс программного модуля, а не на его внутреннюю часть. При таком подходе у него было больше свободы для рефакторинга внутреннего кода модуля, не влияющего на тесты. И, в конце концов, он решил, что стабильность общедоступного интерфейса должна быть главной заботой.
Мне лично нравится позиционировать этот подход между традиционным модульным тестированием, которое фокусируется на наименьшем фрагменте кода, который может быть логически изолирован, и интеграционным тестированием, в котором программные модули объединяются и тестируются как группа. Он знал, что точное определение причины неработающего теста происходит чуть менее мгновенно, поскольку в рамках одного теста выполняется больше кода. Он считал, что это очень приемлемый компромисс для большей свободы рефакторинга.
Это был отличный разговор; Это дало мне новую перспективу, и я люблю общаться с другими людьми, у которых есть такая же страсть и стремление к созданию наилучшего программного обеспечения.
Некоторым этот раздел может показаться слишком романтичным взглядом на инженеров-программистов. Учитывая высокий спрос на инженеров-программистов на рынке сегодня, я, безусловно, считаю, что есть процент людей, которые не отдают приоритет чистому коду, рефакторингу или изучению как можно большего количества шаблонов проектирования. Я не могу это контролировать. Все, что я могу сделать, это поделиться тем, что я считаю невероятно полезным и стоящим стремлением к совершенству в том, что вы любите.
Командная работа
Программное обеспечение создается и поддерживается командами. Важна способность хорошо работать в команде. Потенциал инженера-программиста основан не только на технических способностях, но и на эмоциональных и межличностных навыках.
Умение работать в команде, вдохновлять и воспитывать окружающих — явный признак отличного инженера-программиста. Это также знакомит их с различными подходами и точками зрения, как в примере с модульным тестированием, которым я поделился ранее. Таким образом, преимущества двусторонние.
Глядя на мои собственные обязанности и приоритеты сейчас, я делаю большой упор на командную работу, где я руковожу инженерными командами, обучаю инженеров и разрабатываю архитектуры решений вместе с этими командами.
Сожалею ли я о сделанном выборе?
Меня регулярно спрашивают, сожалею ли я о том, что «отошел» от кодирования. Это справедливый вопрос, и честный ответ — нет. Ну, иногда. Немного.
Выбор во многом обусловлен тем, как рабочая среда сформировала меня как личность. Я вырос на проектах с небольшой командой, несущей сквозную ответственность. В этом контексте всесторонне развитые инженеры, как правило, способны принести больше пользы, чем если бы они решили посвятить себя стремлению действительно преуспеть в чем-то одном.
Это также дало мне представление о том, что качество — это нечто большее, чем код, написанный мной лично. Качество достигается за счет максимально возможного контроля всего процесса доставки, а также за счет налаживания хорошей командной работы и формирования правильной культуры. Поэтому вместо того, чтобы стать лучшим программистом, я решил оказать максимально возможное влияние на качество, создав сильный Т-образный профиль знаний. Это означает, что я приобрел несколько хорошо развитых основных навыков (глубоких навыков), таких как кодирование, но дополненных сильным набором вспомогательных навыков за пределами этой основной области (общие навыки), которые охватывают процесс доставки программного обеспечения.
И хотя я не начинал свою карьеру с амбиций стать наставником или лидером, с годами я очень ценю это благодаря поддержке замечательных людей, которые позволили мне влюбиться в разработку программного обеспечения и поддержали мое развитие в качестве профессионал и человек. Со временем я начал чувствовать, что с моей страстью к разработке программного обеспечения я мог бы поддерживать других инженеров в развитии их страсти к ремеслу, а также создавать правильную атмосферу и культуру для процветания инженеров. Недавно я прочитал цитату, в которой говорилось: «Будь тем старшим инженером, в котором ты нуждался, будучи младшим», и это то, что я стараюсь делать каждый день.
Так почему же я сказал, что иногда немного скучаю по программированию? Ну, потому что я делаю. Большая часть кода, который я делаю, — это быстрые всплески для понимания важных вещей, выходящих за рамки концептуального уровня. Хотя это, безусловно, очень весело, честно говоря, это совсем другое. Эти кодовые базы не требуют постоянного внимания к чистому коду, рефакторингу или управлению техническим долгом. Это не требует такого же внимания, любви и заботы, которые действительно утоляют мой зуд ремесленника.
Однако я обнаружил, что могу утолить этот зуд с помощью архитектуры решения. Код и архитектура связаны и развиваются вместе, чтобы соответствовать дополнительным (не)функциональным требованиям. Оба, на своем уровне абстракции, стремятся разложить сложность и получить слабо связанные, очень связанные компоненты. Оба они нацелены на то, чтобы сообщить о намерениях другим, используя узнаваемые структуры, шаблоны и имена. Таким образом, поставленные задачи более похожи, чем многие думают.
Для меня и программирование, и архитектура решения относятся к своей собственной ранговой группе с тройным ромбом s-уровня. Как равные, как братья. Для меня буквально нет ничего близкого, и я чувствую себя счастливым, имея такую страсть к своей профессии. Я по-прежнему так же люблю разработку программного обеспечения, как и десять лет назад. И я сомневаюсь, что это когда-либо изменится.
