Три архетипа профессионала в области программной инженерии

Мой коллега недавно поделился со мной метафорой о двух архетипах программистов: «Фокусник» и «Писец»:

Писец прилежен и методичен; ее код чист и организован; она может описать цель каждой строки с полной ясностью; она прочитала руководство от корки до корки.

Писцы имеют тенденцию к подробным исследованиям и не будут ничего реализовывать, пока не будут уверены, что понимают код, который они собираются написать. Представьте себе историка из библиотеки первоисточников, говорящего: «Мне нужно всего еще 20 подтверждающих первоисточников, чтобы быть уверенным, что Артур был королем бриттов». Писцу нужны доказательства, чтобы продолжить.

С другой стороны, Conjurer, похоже, может вытащить работающее приложение из воздуха; вырезать блоки кода из трех сообщений Stack Overflow и вставить их в свой код. Магия крови - это не запретная территория, произнесите запрещенные слова «Обезьяний патч» и shazam:

«В приложении есть видеочат». объявляет фокусник. «Да и… кстати, что такое« рабочий сервер »?»

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

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

«Писец в сетях, девочка!»

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

Результатом этого различия стало то, что я построил ряд вещей, которые никогда не перестраивал в своей повседневной работе веб-разработчиком: я написал несколько программ на языке ассемблера, я построил компилятор, я изучил мелочи различных двоичных кодировок, я реализовал разновидность malloc. В Advanced Algorithms я не написал ни строчки кода. Задания и экзамены были формальными доказательствами; созданные нами алгоритмы были на уровне псевдокода. Несмотря на то, что я не писал никакого реального кода, продвинутые алгоритмы были, безусловно, моим самым сложным курсом в колледже и одним из самых интеллектуально полезных.

Писец лучше всего проявляет сильное любопытство; постоянная потребность в понимании вещей еще больше досконально. Визуализация чего-то вроде стека вызовов - это всего лишь шаг на пути к языку ассемблера. Хеш-функции - это всего лишь шаг к атакам столкновения или фильтрам Блума. Линейная алгебра - это только начало таких удивительных алгоритмов, как нейронные сети, линейная регрессия и другие тактики машинного обучения.

Каждый навык, который изучает писец, - это просто шаг к чему-то более глубокому.

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

«Призови еще одну интеграцию OAuth, чувак!»

С тех пор, как я получил высшее образование, я попробовал несколько вкусов в индустрии программирования. Я освоил ряд различных технических областей (разработка интерфейсных приложений, проектирование веб-серверов, согласование записей, обработка изображений и кластеризация, администрирование баз данных) в различных отраслях (издание медицинских учебников, организация питания B2B, бытовая и коммерческое электричество и техническое образование). Под давлением необходимости быстро предоставлять результаты в системах, намного больших, чем я когда-либо видел, я научился вызывать в воображении «минимально жизнеспособный продукт» через огонь и пламя необходимости.

На второй работе я работал в команде инженеров из трех человек. За все отвечал каждый. Мы все создали сервер Python / Django. Мы все внесли свой вклад в базу данных. Мы все по очереди развертывали код. Все мы писали функции на Angular. Все это было моей обязанностью, и хотя я раньше работал с Python и Postgres, у меня практически не было опыта работы с нашими веб-фреймворками: Angular и Django. Тем не менее, всегда были функции, которые нужно было отправить, и мне все равно приходилось оправдывать свою зарплату моему боссу!

В колледже моим приоритетом было глубокое понимание каждого компонента и процесса; Чтобы достичь такого уровня понимания в Chewse, потребовались бы месяцы или годы. Мне пришлось научиться доверять работающим системам. Создание чего-то нового означало собрать ровно столько, чтобы понять ввод и вывод каждого компонента, чтобы быстро создавать новые функции или исправлять ошибки. Мне пришлось намеренно отказаться от уровня понимания, на котором я был хорошим учеником, чтобы идти в ногу с темпами бизнеса.

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

С быстро меняющимися бизнес-требованиями и относительно ограниченным пониманием всего объема разработки программного обеспечения мне пришлось принять тот факт, что я не знаю, как делать все, что меня попросят. Я также научился прекращать попытки сделать все правильным; иногда мое решение было чем-то вроде взлома, и это нормально. Что важно, я также научился просить о помощи.

Наставничество имеет значение при колдовстве, возможно, больше, чем для писанины: когда вы играете на незнакомой территории, наличие кого-то, кто поймает ваши ошибки и установит передовой опыт, является невероятным преимуществом. Я всегда буду помнить, как паниковал, когда случайно удалил несколько записей из нашей производственной базы данных в Amirsys. Мои тогдашние начальники и наставники Брайан и Стив помогли мне восстановить записи из автоматической резервной копии. Моя работа в Amirsys не была прекращена, и я получил очень ценные уроки о транзакциях с базами данных и средах развертывания. Без присмотра мое заклинание могло иметь очень серьезные последствия как для Амирсис, так и для меня.

Учить учиться

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

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

"Это почему?"

Чтобы дать удовлетворительные ответы ученику, который постоянно спрашивает «почему», требуется писец, глубоко разбирающийся в данной теме. Чтобы перейти к любому студенческому проекту и отладить его, инструктор должен облегчить использование пакетов, API и SDK, которые они, возможно, никогда не использовали лично, - хлеб с маслом фокусника. Работа учителем помогает вам динамически переключаться между этими двумя навыками.

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

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