Вечер пятницы, я получил имэйл от моего приятеля, который только что закончил колледж (Рочестерский Технологический Институт) и работает в весьма многообещающем стартапе, занимающемся программированием C++ систем и обучением искуственных интелектов. Ниже небольшой фрагмент его письма.

Чувак, одна вещь на работе не дает мне покоя – хотя мои коллеги по большей части приятные люди, я чувствую, как будто мою работу совершенно не ценят. Я работаю с шестью инженерами (вместе мы составляем команду из семи инженеров). Из шести, один — Platform Architect (Архитектор платформ), двое – Старших Инженеров-Прикладников, еще один – Software Architect (Программный Архитектор), остальные два отвечают за Обеспечение Качества. Если честно, и я не хочу, чтобы это прозвучало надменно, но за исключением одного Старшего Инженера-Прикладника, я понял, что знаю намного больше чем все эти «старшие» парни. Не пойми меня неправильно… они занимаются этим уже много лет, работают над важными системами и все такое, но я более образован чем они. Чаще всего, из-за того, что я Младший Системный Инженер, мои идеи просто отметаются и моя напряженная работа совершенно не ценится… откровенно говоря, это меня ужасно бесит. Иногда я подумываю о том, чтобы вернуться к фрилансу (особенно учитывая, что я уже закончил колледж).

Я был на 80% уверен, что должен написать этот пост после прочтения того имэйла. 15% дало мне прочтение этого, этого и этого. Последние 5% я получил после прочтения этого.

Я являюсь младшим разработчиком. Моя текущая позиция могла быть названа просто «Разработчик ПО», но мне 18 лет (будет 19 в августе), и по этой причине в ПО индустрии я являюсь младшим разработчиком. Итак, что же это такое на самом деле? Я видел слишком много описаний того, какого это, по мнению различных людей, быть «младшим» разработчиком. Я также заметил, что у младших разработчиков (включая и меня, в какой-то момент в прошлом) данный термин ассоциируется с неким позором. На протяжении нескольких последних месяцев у меня была возможность работать в команде блестящих инженеров, которая создает классный и полезный продукт. Не смотря на то, что прошло всего около 6 месяцев, как я работаю в настоящей команде, создающей ПО, я уверен, что могу дать, как я думаю, подходящее определение младшему разработчику.

Вместо того, чтобы давать формальное определение, я представлю несколько примеров, из которых вы сможете извлечь смысл этого значения. Хорошо… погнали.

Дисклеймер для моего приятеля: Я все еще люблю тебя, дружище. [:)].

Всезнайка

Готов поспорить, что 98% из нас, младших разработчиков, так или иначе проходят через эту фазу. Чтобы лучше это объяснить, я использую вымышленного персонажа – Джека.

Будучи молодым, полным энтузиазма и страсти разработчиком, Джек стремиться быть лучшим в своей профессии. Ему все интересно, поэтому он постоянно учится чему-нибудь новому, будь то новый язык программирования, парадигма, паттерн проектирования или технология. На данный момент он знает семь языков программирования. Он знает, как писать императивные, функциональные, управляемые событиями и объектно-ориентированные программы. Джек не только знает, как писать изумительные фабричные методы, сексуальные синглтоны, прелестные декораторы и необыкновенные прототипы, он знает, как их правильно использовать (или по крайней мере он так думает).

Ах да, кстати, Джек также знает кучу всего о различных платформах, таких как Node.js, Java, Haxe, ooc, и даже о той, которую ты добавил в свой частный репозиторий GitHub прошлой ночью. Поверь мне, он все это знает. ОМГ! Как я мог забыть? Джек также программирует на ассемблере.

И благодаря всей этой куче знаний, Джек начинает чувствовать, как я это называю, безрассудное чувство превосходства. Сейчас он знает в сотни раз больше чем обычный Джо, и поэтому он лучше подходит на должность этого Джо. И пожалуйста, сделай себе одолжение, никогда не называй Джека «младшим» разработчиком, или что хуже (ох, ну вот понеслось) «малышом»; если ты все же это сделаешь, то не удивляйся, что позже тем же вечером у тебя будет дикая головная боль, потому что Джек, сидя в своей спальне, дубасит монтировкой по кукле, напоминающей тебя.

Опытный

«He who would learn to fly one day must first learn to walk and run and climb and dance; one cannot fly into flying» (Идите от простого к сложному) — Фридрих Вильгельм Ницше

Удивительное выражение великого философа и поэта, Фридриха Вильгельма Ницше.

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

Дисклеймер: Я сам все еще учусь и привыкаю ко всему этому. Я ни коим образом не утверждаю, что все это также неприменимо и ко мне.

Эмоции

Более опытный разработчик знает, как сломить менее опытных, чтобы затем придать им форму. Но… но… но что ты этим хочешь сказать, Джонатан? Заканчивай подхалимничать! Я уже начинаю уставать от этого!

Хорошо, тебе реально надо успокоиться и послушать.

Одна вещь тесно связанна с «молодым, полным энтузиазма и страсти», и как я стал ее называть – «специализация» или «крючок». В моем понимании, если ты разработчик и тебе говорят, что у тебя есть «крючок», то это значит, что ты слишком привязан к своим технологиям и продукции. Будучи младшим разработчиком с этими характеристиками, ты тратишь огромное количество времени, совершенствуя свой код, при этом думаешь о всех этих применяемых паттернах проектирования и принципах, пишешь unit-тесты (зачастую довольно бесполезные) и т.д. В какой-то момент ты заканчиваешь и супер-пупер уверенный на счет своей работы идешь прямиком к «старшему» разработчику, конечно же со сверкающей улыбкой на лице. Затем, к твоему удивлению, она говорит, что паттерн проектирования, который ты использовал, был необязателен, что твоя система не масштабируется горизонтально, и что ты поспешил с оптимизацией. Маленький чувак внутри тебя начинает рыдать, но ты держишься мужественно и не показываешь ей этого. Начинаешь размышлять о том, где продаются куклы и монтировки. Затем она начинает объяснять тебе свою точку зрения. Она говорит тебе, что основываясь на предыдущем опыте, одиночный паттерн, который использовал ты, ранее был использован в этих же целях, в то время как внедрение зависимости подошло бы лучше, и, если бы так и случилось, то им (ее предыдущей команде) не пришлось бы барахтаться в болоте рефакторинга. Затем она объясняет тебе, что запись на диск сервера с твоего приложения, приложения, которое должно быть сбалансировано при распределении нагрузки, автоматически дисквалифицирует его как кандидата по оптимизации нагрузки, потому что файл, записанный на диск сервера №1, будет считываемым на серверах №2 и №3. Она также говорит тебе, что преждевременная оптимизация, при которой все твои идентификаторы переменных становятся одним длинным символом, только навредит тебе в будущем, поскольку для этих целей существуют специальные инструменты. Мм… ты скажешь, «возможно мне вовсе и не нужна эта кукла».

Вот, что я имею в виду, говоря про сломить, чтобы затем придать форму. Ты не только получил экспертный критический отзыв на свою работу, ты научился чему-то новому в процессе.

Полезное чтиво: Правило программиста номер один — оставить эмоции за порогом

Проектирование и процесс

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

Одно я могу сказать (пока), что все же есть две вещи, которые младшие разработчики игнорируют, и что, по моему скромному мнению, является необходимым для создания продуктов с отличной архитектурой. Эти две вещи, как я их называю, «проектирование» и «процесс». Мы все, конечно же (надеюсь), знаем, что обычно значит «проектирование», но что я подразумеваю, когда говорю свое «проектирование»? Проектирование — это просто обдумывание чего-либо, что ты хочешь сделать, перед тем как начать это делать.

У нас, как у младших разработчиков, есть привычка строить не подумав, и думать после того как построил. В будни фрилансера, мне давали задания и оставляли в одиночестве (как правило), чтобы я их выполнил. По этой причине, я штамповал [плохого качества] код (минимум 75 Строк кода в час) на протяжении 15-20 часов подряд. Все, о чем мне нужно было позаботиться — это только чтобы клиент был доволен и его требования были учтены. Пока плохого качества код делал то, чего хотел клиент, все было хорошо и все были счастливы.

Хорошо, но что тогда ты подразумеваешь под словом «процесс»? Процесс — это четко сформулированный маршрут по которому нужно пойти, чтобы выполнить задание. Вот где вам пригодятся проектный менеджмент, его инструменты и планирование. И снова, до попадания в настоящую команду по разработке ПО, я знал о различных инструментах проектного менеджмента, таких как Trello, Redmine и Sprint.ly. Я даже некоторыми из них пользовался, включая Trello и Redmine. Однако процесса у меня все равно не было, поэтому я использовал эти мощные инструменты проектного менеджмента как список дел (разбивал все задания на выполненные и невыполненные). Теоретически я знал, что такое Обеспечение Качества, но все равно не понимал сам процесс.

Сейчас у меня есть возможность научиться создавать процесс правильно.

В общем и целом, déjà vu специалист и в общем и целом, jamais vu эксперт.

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

Но Джонатан… название твоего поста! Хорошо, хорошо, позволь мне объяснить.
Известное выражение «déjà vu» это французское выражение, буквально означающее «уже видел». Почти что антоним к этому выражению – «jamais vu», буквально означающее «никогда не видел».

Многие младшие разработчики (конечно же, включая меня) знают людей с приставкой «Старший» или окончанием «Архитектор» в названиях их должности, которых они считают менее образованными (по отношению к навыкам программирования) чем они сами. Однако, одна занимательная черта присуща многим из таких людей, это то, что они были в деле на протяжении долгого времени, работали в разных компаниях (не обязательно), совершили много ошибок, учились на них и т.д. Не смотря на это, они, в отличие от нас, могут не знать каждый язык, платформу и/или технологию. Вместо этого они совершенствуют свои навыки в нескольких областях (насколько мне известно, обычно одной или двух). И вместо того, чтобы изучать каждый язык, платформу и/или технологию они выбирают один или два языка, платформы и/или технологии и становятся истинными экспертами в этих областях.

Что значит быть истинным экспертом по отношению к какому-либо языку, платформе и/или технологии? Для меня истинный эксперт в чем-либо, это просто кто-то, кто не только знает или понимает свою область на уровне эксперта (как все устроено внутри и снаружи), но и имеющий многолетний опыт в данной области. Другими словами, по моему скромному мнению, каждый разработчик, приложив усилия, где-то через год может стать экспертом, скажем, в языке С# (при этом постоянно читая), но чтобы стать истинным экспертом, таким как многоуважаемый Джон Скит, нужно потратить годы.

Так что же ты имеешь в виду, Джонатан, говоря «в общем и целом, déjà vu специалист». Я говорю об истинных экспертах. Их компетентность может распространяться только на одну или две области, но они «уже повидали» много чего в данных областях. Они могут создавать масштабируемые системы, у них глубокое понимание экосистемы, они знают шорткаты, которые ведут к катастрофе, знают года нужно применять оптимизацию и т.д. Вау! «масштабируемые системы» … это что за штука такая? Видите ли, к счастью, в данный момент, мы (младшие разработчики) подпадаем под категорию «в общем и целом, jamais vu эксперт». Мы можем быть экспертами (заметь, не хватает «истинными») в различных вещах, можем знать, как создавать системы, можем иметь понятие об экосистеме, можем знать множество шорткатов, но мы (по сути) не имеем представления как масштабировать системы, которые мы создаем, наше понимание экосистем весьма поверхностное, шорткаты, которые мы выбираем по сути не нужны, и мы тратим много времени на преждевременную оптимизацию.

Народ, зачем торопиться?

В спешке нет необходимости.

Одну статью я никогда не уберу из свих закладок, «Научи себя программировать за 10 лет», написанную потрясающим Питером Норвигом.

Если ты еще не читал ее, то налей себе бокал Натурального 100% Яблочного Сока компании Mott’s (поскольку это будет тебе полезно и так как это то, что я сам сейчас пью… [;p]), выключи телевизор, Тресни по Голове Своего Брата™ (ок… я этого никогда не говорил), пройди по ссылке, расположенной выше и внимательно прочти все.

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

Хорошо… на этом все. Конец.

Перевод выполнен в рамках летней школы стартапов Tolstoy Summer Camp и MetaBeta.

Автор: tomshinsky

Источник