На этой неделе пришло время поговорить с одним из немногих британцев на восточном побережье в офисах Thinkbot. Джордж Броклхерст - директор по разработке, и в этом выпуске Crossroads мы говорили о различных способах стать старшим разработчиком. Этот эпизод представляет вам Upcase. Мы говорим с опытными разработчиками о том, как эволюционировал их опыт, мы спрашиваем их о поворотных моментах в их карьере и о том, что помогло им избавиться от титула младший. Upcase поможет вам сделать следующий шаг. Upcase покажет вам, как лучшие разработчики решают проблемы программирования, каковы их опыт и как они достигли своей цели.
Что вы делаете?
Натали: Сегодня я очень рада, что к нам присоединился Джордж, разработчик в thinkbot. И мы в офисах в Бостоне. Мне бы очень хотелось услышать от вас вступительное слово и немного рассказать, что вы делаете и чем занимаетесь.
Джордж: Конечно. Привет, Натали, приятно быть здесь. Итак, я занимаюсь разработкой примерно с 2005 года, а до этого я получил степень по информатике, так что это был очень традиционный академический путь к разработке программного обеспечения. После университета почти случайно занялся веб-фрилансом, и в итоге занимался этим около четырех лет. А потом изучил Ruby, поработал в нескольких стартапах, немного выучил Python, переехал в Швецию, работал с другими стартапами, а затем присоединился к Thinkbot около пяти лет назад.
N: Итак, у вас был разный опыт. Очень хочется рассказать о том, как вы попали в фриланс, потому что я думаю, что это то, в чем многие люди находят много загадок. И от фрилансеров, с которыми я разговаривал в прошлом, это обычно делится на несколько категорий. Некоторые люди становятся фрилансерами, потому что не хотят работать в корпоративной среде. Некоторым из-за того, что они не нашли работу, которая им действительно нужна. Другим потому, что они нашли проблему, которая им достаточно интересна, чтобы выделить достаточно времени и создать компанию для ее решения. Какой у вас был опыт?
G: Честно говоря, это было гораздо менее умышленно, чем все это. Я заканчивал университет, и у меня был друг, дизайнер, и они сказали, что у них есть проект, над которым они работают, и будет ли мне интересно заниматься его разработкой. И я сказал: «Конечно, это звучит очень интересно летом». И просто как бы пошло оттуда. И я думаю, что этот проект прошел достаточно хорошо, и после этого, казалось, имело смысл искать другой проект. Итак, я просто продолжал идти.
Итак, я явно не пытался создать компанию-фрилансера или построить карьеру таким образом.
Мне просто предложили одну работу, и, поскольку она прошла хорошо, я стал искать следующую и еще одну.
Ваша степень подготовила вас к фрилансу?
N: Отлично. И какой опыт или опыт были у вас до этой работы, которые были вам полезны? Помимо степени информатики, потому что ... Как вы думаете, степень информатики дает вам возможность сразу стать фрилансером?
G: В то время я абсолютно так думал. И, оглядываясь на это, я был очень неподготовлен. Есть действительно интересный пост на Medium, который недавно стал популярным. Заголовок гласит: Что, если бы мы проводили собеседование с переводчиками так же, как мы проводим собеседование с разработчиками программного обеспечения?. Центральная посылка поста заключается в том, что если кому-то, собирающемуся на должность переводчика, задать кучу вопросов по лингвистике, а не переводить вопросы. Именно так проходят собеседования с некоторыми работниками по разработке программного обеспечения. Есть много вопросов по информатике, а не по разработке программного обеспечения. И здесь есть разрыв между теоретической информатикой и повседневной практикой разработки программного обеспечения. И они определенно пересекаются, и я не пытаюсь сказать, что информатика бесполезна, но я думаю, что у меня было гораздо более теоретическое понимание того, что я должен делать, а не практическое понимание того, как сделайте это в реальном мире.
N: Это своего рода перезвон со многими другими выпускниками факультетов информатики, с которыми я разговаривал. Есть ли что-то, что вы хотели бы сделать, или если бы вы вернулись и сделали это снова и, в рамках вашей степени информатики, или совет, который вы дали бы тому, кто идет по этому пути, о том, что они могут сделать для усовершенствовать свои навыки и полностью подготовиться к следующему шагу, что бы они ни предприняли, будь то работа на фрилансе или переход к разработке программного обеспечения?
G: Хотел бы я уделять больше внимания инструментам. Я выучил несколько языков программирования, когда учился в университете, но особо не обращал внимания на такие вещи, как текстовые редакторы. Так что у меня было намного больше свободного времени, чем я думал. Я думал, что очень занят, но на самом деле, сравнивая университет с ...
N: реальный мир?
G: В реальном мире у меня было намного больше времени. Итак, кривая обучения чего-то вроде Vim, скажем, может быть… Сначала это может немного замедлить вас. Может быть немного сложно добраться с нуля до: «О, я так же быстр, как если бы был в Sublime или TextMate, или… Но после этого вы можете пойти гораздо дальше. И мне жаль, что я не потратил какое-то время и прошел через эту кривую обучения тогда.
Кроме того, существует множество инструментов, связанных с такими вещами, как контроль версий и управление проектами. Я не использовал Git. Я начал использовать Subversion в какой-то момент, когда был фрилансером, но я определенно не делал этого сразу же. Это не было: «Ну, я пишу новую программу. Первое, что мне нужно сделать, это создать репозиторий управления версиями, где я должен хранить это ». И, оглядываясь назад, я заметил, что были ошибки, от которых я бы меня точно спас. Были времена, когда я сотрудничал с людьми, когда было бы намного проще, если бы я использовал контроль версий и тому подобное.
Но это не совсем то, что нужно изучать в области компьютерных наук, потому что это больше о практической реализации в реальном мире, чем о теории и основных причинах. Так что это просто никогда не подходило к моему курсу на получение степени.
Я наивно полагал, что эта степень охватывает практические вопросы, а не только теорию.
На что был похож фриланс?
N: В первом проекте, который вы сделали, делайте любые выдающиеся моменты, которые вы можете определить, где вы думаете: «Вот дерьмо. Я не знаю, как это сделать ». И: «Вот дерьмо. На самом деле я совсем не был к этому готов. Мне нужно очень быстро изучить X, чтобы реализовать этот проект ».
G: В том самом первом проекте я много разрабатывал интерфейс, поэтому писал много HTML и CSS. А это был 2005 год, так что я думаю, что макеты CSS были чем-то важным, но макеты таблиц все еще существовали, и люди все еще занимались этим. И мы сделали все это с помощью макета CSS, и нам это очень понравилось. А потом мы довольно поздно в ходе проекта узнали, что все сотрудники компании, которую мы создавали, использовали для использования Internet Explorer для Mac.
N: Oh no.
G: Которые даже тогда Microsoft больше не поддерживала. Люди, которые его сделали, уже считали его устаревшим браузером. Но мы не знали, что с этим делать, потому что он не поддерживал большую часть CSS. Он был слишком стар, чтобы обладать такими возможностями. Если я правильно помню, я думаю, что в конечном итоге мы переделали макет веб-сайта с помощью табличного макета, что было действительно печально. И это было много дублированных усилий, много работы, которую можно было бы сэкономить, если бы вы узнали больше о нашем клиенте ранее, но также, возможно, имел бы сложный разговор вокруг: «Эй, вы думаете, что вам нужно, чтобы это выглядело правильно в этом браузере что вы используете, но есть много причин, почему вам это не нужно, и почему то, над чем мы работаем, будет лучше для вас в будущем ». Вместо этого мы просто переделали целую кучу работы.
N: В какой момент своей карьеры вы чувствовали себя достаточно уверенно, чтобы вести подобный разговор с клиентами?
G: Я не уверен, что действительно справился с этой первой работой на фрилансе. Я думаю, что именно когда я начал работать в стартапах и продуктовых компаниях, я получил больше информации о большем количестве целей в бизнесе, в котором я работал, и о вещах, не связанных с разработкой, что затем дало мне уверенность сказать: «О, это развитие вещь применима », или:« Это не так », или« Мы могли бы решить эту проблему проще и эффективнее ». Но да, я думаю, это произошло благодаря работе со стартапами, а не фрилансу.
N: Итак, вы бы сказали, что после того, как вы немного поработали фрилансером и вошли на сцену стартапа, вы все еще считали бы себя младшим разработчиком или сказали бы: «Я был средним» или более опытным? Мне действительно интересно узнать, в какой момент люди считают, что этот переход произошел, и какие триггеры привели к этому переходу.
G: Я думаю, что есть много параметров, по которым вы можете измерить эти вещи. Итак, я бы сказал, например, что моя способность писать семантический HTML и хороший CSS, который работал во многих браузерах, была, вероятно, среднего уровня, может быть, даже для старшего. Но зная, сколько из этого нужно применить и когда, и мои навыки внутреннего кода, которые ... Как ни странно, внутренний код был, вероятно, больше связан с тем, что я изучал в университете, но ... Моя способность структурировать вещи ну, и написать код, который нужно было сопровождать, к которому я вернулся бы через шесть месяцев и подумал: «О да, я знаю, что здесь происходит, и я могу снова поработать с этим». Я бы все же сказал, что был довольно молодым в этом деле, когда попал в мир стартапов.
Насколько важно было парное программирование для вашего карьерного роста?
N: Вы много занимались парным программированием, когда были в мире стартапов?
G: Да. Да, мы ... На самом деле, команда, с которой я работал, в компании под названием Revu, они пытались заниматься 100% парным программированием и решили, как раз перед тем, как я присоединился, не делать 100% парное программирование. Но в культуре по-прежнему считалось, что спаривание - это хорошо. Таким образом, обычно в каждый момент времени работают три пары разработчиков и пара человек. Так что это было спаривание большинства.
И в той среде это сработало для меня очень хорошо. Потому что я много узнал о Ruby и много о бэкэнд-разработке от этой команды, и мне нужно научить их многому о фронтенд-разработке и HTML и CSS. Так что это показалось мне прекрасным способом быстро освоить технологии, которые я не очень хорошо знал, но также и способ поделиться знаниями, которые у меня были, внутри команды, которая не была так сильна в этих областях. .
N: Определенно. И какой процент, если подумать, вы бы назвали компаниями, которые объединяют программы, с компаниями, у которых это не является основной частью своей культуры?
G: Я думаю, что это довольно редко, когда он занимает центральное место в культуре. Я бы не сказал, что существует так много компаний, которые сопротивляются этому. Многие компании готовы хранить его в сумке с инструментами и иногда брать с собой, но я встречал очень мало людей, которые думали, что это важный навык или неотъемлемая часть рабочего процесса.
N: Определенно. Одна вещь, которую я часто вижу в заявлениях о приеме на работу и, точнее, в описаниях должностей, - это идея о том, что вы должны быть ниндзя и рок-звездой, и все те классические образы, которые вы видите в технологической индустрии. И я часто думаю, что парное программирование, по мнению всех людей, с которыми я разговаривал, изменило правила игры в карьере многих людей и фактически превратило вас из юниоров в юниоры. Это один из ключевых рычагов, который я постоянно вижу. Но если компании заявляют, что им нужны рок-звезды, ниндзя и люди, которые на самом деле не кажутся хорошими партнерами в парном программировании, похоже, возникает конфликт интересов в том, чего хотят компании и что на самом деле работает.
G: Да, я определенно согласен с этим. Я считаю, что программное обеспечение, даже если вы не занимаетесь парным программированием, в своей основе предполагает совместную работу. Все лучшее, над чем я работал, - это то, над чем я работал в команде, где были люди с разными навыками, дополняющими друг друга. Даже люди с очень похожими навыками, с которыми я мог бы просто поделиться идеями, поговорить с ними, получить от них рецензию и дать рецензию кода, доставляет больше удовольствия, и, по крайней мере, для меня это произвело лучшие результаты, чем когда-либо, когда я сидел сам и писал кое-что. Когда термин рок-звезда действительно набирал популярность, мы говорили об этом с друзьями и всегда говорили: «Я бы предпочел быть бас-гитаристом». Знаешь? "Я скорее-"
N: Барабанщик.
G: Да, в группе, и часть чего-то, и вносит свой вклад, но не эффектный яркий соло. Потому что это менее увлекательно, менее интересно и не дает таких хороших результатов. По крайней мере, для меня это не так. Может быть, есть люди, которые в одиночку создают потрясающие вещи, но я не из их числа.
Что вы ищете в младших разработчиках?
N: Что вы ищете, когда проводите собеседование с младшими разработчиками?
G: Я думаю, что это действительно хорошо в ситуации собеседования, когда люди знают, что они делают, и не знают. Если я беру интервью у кого-то, кто младше, и он пытается найти ответ на вопрос, на который они не знают ответа, или что-то, с чем они не сталкивались раньше, это обычно довольно очевидно, и этого не происходит. поперек хорошо. А когда кто-то говорит: «О, я не знаю, но первое, что я попробую, это вот что». Или: «Я бы сначала прочел эту документацию и посмотрел, смогу ли я разобраться в этом». Или: «Я бы спросил коллегу». Или даже: «Не могли бы вы меня начать, потому что я не знаю, как к этому подойти». Обычно это приводит к более плодотворному разговору, и я знаю, что этот человек честен, он знает свои сильные и слабые стороны, хочет учиться, расти и делать что-то новое, а не хорошо выглядеть.
N: Ага. Я слегка съеживаюсь здесь, потому что думаю, что могу оглянуться назад на начало моей карьеры в сфере технологий и сказать, что определенно ошибся, но не потому, что я ... я думаю, что я не ужасный человек, а потому, что я чувствовал, что был давление, чтобы что-то знать, из головы, а если вы не знали, то вас полностью списали. И я думаю, что это результат того, о чем мы говорили раньше. Это желание нанять рок-звезд, эта культура, которая не ценит парное программирование, это движение к индивидуальности, а не к совместному подходу. И поэтому, когда у вас есть все эти рычаги, работающие в том виде, в котором представлены технологии, мы видим суперзвезд-основателей, мы видим, что этот очень индивидуалистический, очень всезнайкий образ - тот, который поддерживается. Трудно пойти туда и показать, что вы чего-то не знаете, потому что у вас есть определенное представление о том, какими должны быть технологии и какими вы должны быть, чтобы войти в эту отрасль.
И только однажды, я был здесь уже пару лет, что на самом деле лучшая работа, которую я сделал, или лучшие клиенты, которые у меня были, или лучшая работа, которую я сделал, я получил в результате я очень открыто говорил: «Вот все, чего я не знаю, но я действительно хорошо умею это выяснять». Или: «Мне действительно интересно, мне любопытно X, и мне любопытно Y, и вот как я могу найти эту информацию». Но мне потребовалось много времени, чтобы добраться до этого момента.
G: Ага. И я думаю, что индустрия развивается так быстро и постоянно появляется так много нового, что никто никогда не знает всего этого, независимо от того, сколько времени они работают, и какой у них опыт. Когда вы разговариваете с потенциальными клиентами интеллектуального робота, часто возникает одна проблема. Кто-то скажет: «О, вы использовали этот один очень специфический API или этот очень специфический инструмент?» И обычно ответ таков: «Нет, но мы использовали так много API и инструментов, что этот не будет другим». И это будет несложно понять ».
Но я думаю, что для людей, которые продвинулись дальше в своей карьере, важно также быть готовыми сказать: «Я не знаю».
Потому что, если мы представим старшего разработчика или как вы хотите называть людей, которые потеряли младшего из своего титула ... Если мы представим этого человека как человека, который никогда не задает вопросов, то мы не представляем реальность этого, а именно: всегда есть чему поучиться. Всегда есть что-то новое, или что-то более глубокое, или другой слой в стопке, помимо того, что вы уже знаете. И никто не будет держать все это в голове все время.
N: 100%. Какие проекты пугают вас и заставляют думать: «Вау. Я думал, что стал старше, но снова чувствую себя младшим ».
G: Это действительно хороший вопрос. Я думаю, что не обязательно сказать, что это меня пугает, но в незнании того, как подойти к проблеме, есть определенное волнение. Увидеть что-то и подумать: «Я никогда раньше не строил ничего подобного и не уверен, каким будет подход». Так что они определенно вызывают у меня чувство: «Ох, это будет сложно. Мне нужно кое-что узнать ". Я думаю, что это чувство, вероятно, было бы более пугающим несколько лет назад, но я испытал это достаточно раз, и это хорошо сработало, и теперь мне достаточно удобно сказать: «О, я не совсем понимаю, как я» Я собираюсь подойти к этому, но будет весело узнать, так что в конце концов мы доберемся до цели ».
N: Итак, Thinkbot довольно известен своей программой для учеников. И я часто обнаруживал, что, гуляя по офисам, требуется просто много терпения, чего я не вижу во многих отраслях. Такое ощущение, что все действительно торопятся продвигать продукт, привлекать больше пользователей, расти и так далее. Как вы, как старший разработчик, сохраняете терпение, когда существует большое давление как со стороны отрасли, так и иногда со стороны клиента, чтобы обеспечить доставку, доставку и доставку? Конечно, если вы не будете терпеливы к персоналу, коллегам или клиентам, качество продукта может пострадать. Как вы поддерживаете это, а затем как вы создаете пространство для процветания этого терпения?
G: Думаю, есть хороший деловой аргумент в пользу того, чтобы немного притормозить. Вы упомянули, что качество продукта страдает. Есть определенная скорость, за которой все будет ломаться, будут совершаться ошибки, все будет небрежно. Это относится как к тому, чтобы не тратить время на то, чтобы что-то сделать хорошо, но и к тому, что вы просто пытаетесь работать абсурдное количество часов в день. Там, где краткосрочная выгода выглядит действительно хорошо, но чем дольше вы это делаете, тем больше вы вносите ошибок и проблем и вам приходится тратить больше времени на рефакторинг, тем сложнее понять код, поэтому его сложнее изменить. И поэтому я думаю, что здесь есть коммуникационный аспект, когда мы говорим: «Ну, может быть, мы могли бы ускорить выпуск этой большой функции за день, но если мы сделаем это, то следующая функция может занять вдвое больше времени, а следующая функция может займет в четыре раза больше времени, а следующий может занять в восемь раз больше ». И прежде чем мы узнаем об этом, весь проект остановится.
Итак, я думаю, что команды интеллектуальных роботов действуют достаточно быстро, но не до той точки, куда мы спешим. И я думаю, что это помогает укрепить атмосферу терпения. Потому что, если мы говорим: «Что ж, мы хотим сделать это правильно, и мы хотим иметь возможность это изменить». И мы знаем, что бизнес-цели, приоритеты и все остальное будут меняться шесть раз в следующем году, потому что мы часто работаем со стартапами, и это природа зверя. Тогда стоит потратить немного больше времени прямо сейчас, чтобы сделать что-то, что будет легко изменить через год, вместо того, чтобы торопиться с делом сегодня, торопиться с другим завтра, а затем не иметь возможности выполнить какую-либо работу на следующей неделе.
Как вы управляете ожиданиями молодых разработчиков, у которых есть определенные представления о технологической индустрии?
N: Итак, одна вещь, которая волнует многих молодых людей в сфере высоких технологий, - это то, насколько быстро она развивается и насколько захватывающими являются новые технологии, с которыми вы можете поиграть. что вы можете раскручивать и тестировать в разных средах, что вы можете делать то же самое в Ruby, что и в Python, и вы можете посмотреть на тонкости того, почему он отличается и почему он может масштабироваться по-разному, в зависимости от инструментов, которые вы использовать. Как вы справляетесь с ожиданиями скорости от младших разработчиков, которые продали мечту стартапа, пришли в такое пространство, как Thinkbot, или попали в среду, где басистов больше, чем рок-звезд? Как вы сопоставите это ожидание с реальностью?
G: Что касается скорости предоставления отдельных функций, вы можете говорить о том, о чем я только что говорил, с качеством. Что касается темпов изменений, я думаю, что часто есть инструменты, которые используются для решения неправильных проблем, или проблемы, которые решаются с использованием неправильных инструментов, потому что инструмент новый, захватывающий и блестящий, и есть ощущение, что успевать. Сервис-ориентированная архитектура - хороший тому пример. Есть проблемы, которые он решает, и большинство из них связано либо с очень сложными приложениями, либо с очень большим количеством разработчиков. И у большинства стартапов нет ни того, ни другого. Поэтому большинству стартапов не нужна сервис-ориентированная архитектура. Но есть такое: «О, я хочу идти в ногу с индустрией. Я хочу идти в ногу с темпами перемен. Сейчас все занимаются SOA, я должен заняться SOA ». Или: «Сейчас все занимаются микросервисами, я должен сделать еще более сложную SOA».
P Я считаю, что искусство перехода от младшего разработчика к старшему - это не просто понимание инструмента и того, как его использовать, но понимание того, какую проблему он решает и где это применимо. Итак, если кто-то хочет бежать, чтобы быть в курсе новейших вещей, но у него нет проблемы, которую это решает, я бы хотел сделать шаг назад и сказать: «Ну, почему это хорошо?" И если ответ: «Ой, потому что он новый», продолжайте задавать вопросы.
Одна вещь, которую помогает в этом thinkbot, - это время вложения. Так что есть возможность пойти и поиграть с этой крутой обновкой, не обязательно использовать ее в клиентском проекте. Итак, вы можете узнать, что «ну, это отвертка, а это молоток, и они делают немного другие вещи». А в следующий раз, когда вы будете работать над клиентским проектом, вы узнаете, какой из них вам нужен, потому что у вас была возможность их увидеть.
Сколько времени нужно, чтобы стать старшим разработчиком?
N: возможность поместить объекты в песочницу, прежде чем помещать их в живую среду. Люди часто говорят, судя по ответам, которые я получил после ответа на этот вопрос, что для того, чтобы стать старшим разработчиком, вам просто нужно время. И это время, судя по ответам, на которые я смотрел, колеблется от двух до шести и восьми лет. И я не уверен, откуда люди берут эти числа, или где это… Я не знаю, миф ли это, может быть реальность, контекстная реальность. Может быть, в одной компании на это уходит два года, в другой - восемь лет. Но я немного волнуюсь, когда вижу конкретное число, которое не подтверждено никем в отрасли, фактически говоря, чтобы стать опытным разработчиком нужно четыре года. И мне интересно, как вы относитесь к этой идее о том, сколько времени на это нужно. Как вы думаете, пора ли это, или вы думаете, что это строки кода? Как вы думаете, это время, проводимое с клиентами по телефону? Что должно заполнить это время, чтобы оно привело к опыту?
G: Я считаю, что практика - это действительно хорошо, но я думаю, это немного отличается от времени. Но мне также неудобно указывать конкретные цифры на подобные вещи. Отчасти потому, что все очень разные, и, как я упоминал ранее, есть много способов измерить это и много способов взглянуть на это. Так что тот, кто проработал в отрасли всего два года, может быть намного лучше меня в чем-то конкретном. Это могло быть использование какого-то инструмента или техники. Это может быть стиль программирования. Даже по прошествии примерно 12 лет я все еще не написал ничего значительного, используя функциональный язык. И поэтому у тех, кто проработал в отрасли два года и занимался исключительно функциональным программированием, их уровень стажа превзойдет мой в этой одной области. И потому что существует так много разных инструментов и техник и ...
Даже если вы просто подумаете о веб-стеке со всем, что работает в браузере, все, что работает на сервере, протоколы для связи между ними, базы данных за кулисами, архитектуру, есть даже дизайн продукта, выяснение, что построить ... Там происходит огромное количество событий. Так что просто думать об этом как о едином континууме от младшего до старшего кажется красивым ...
N: линейный.
G: Да, очень линейно, и не для того, чтобы отражать всю сложность реальности. И тогда один человек может просто получить CSS, потому что он соответствует принципу работы его мозга или похож на то, что они видели раньше, за пределами разработки программного обеспечения. И поэтому они очень быстро становятся опытными в этом вопросе. И кто-то другой может действительно столкнуться с этим инструментом, и я не думаю, что, поставив этих двух разных людей с разными стилями обучения или разным прошлым опытом перед одним и тем же предметом в течение одного и того же времени, вы могли бы тогда сказать: «О , у них то же самое - "
N: Компетенция.
G: Компетентность, да. Но вы можете поставить тех же двух людей перед какой-нибудь другой технологией, и тот, кто подхватит CSS, как рыба в воде, может бороться, а другой может отлично справиться. Все очень индивидуально. Это очень индивидуально.
А как насчет нетехнических навыков?
N: Одна вещь, которую вы сказали, действительно затронула меня, была, когда вы говорили о том, насколько линейен такой взгляд на вещи. И поэтому я хотел перейти к дополнительным или целостным навыкам, которые вы можете развить, чтобы стать старше. И в некоторых из полученных нами ответов люди говорили: «Ну, я думаю, что для того, чтобы стать старшим, мне просто нужно потратить время и применить практику к изучению моих языков и изучению того, как применять их в разных контекстах, чтобы убедиться, что эти контексты максимально подходят. И я думаю, что это мой путь к тому, чтобы стать старше ». Другой человек скажет: «Я думаю, что стану старше, когда я чувствую, что мне не нужно задавать столько вопросов своим сверстникам. И если я работаю автономно, это будет для меня знаком опыта ». И другие люди на самом деле встречались и говорили: «Ну, я думаю, что стану старшим, когда смогу проводить доклады на конференциях, или проводить семинары, или обучать и наставлять других». Итак, существует большая разница в том, что люди считают опытом.
И я поинтересовался у вас, могу ли я спросить, не обязательно исходя из вашего опыта, но когда вы смотрите на людей в отрасли, которыми вы восхищаетесь, какие качества они демонстрируют и какие вещи люди могут делать по порядку. практиковать такие качества?
G: Я думаю, что есть одна универсальная вещь, помимо самого программирования, и на самом деле она пересекается со многими вещами, о которых вы упомянули, люди говорят: «Хорошо, может быть, я буду испытан, когда Я наставляю других людей, или когда я провожу выступления на конференциях, или когда я могу этому научить ». Все это в некоторой степени связано с общением.
Я думаю, что способность эффективно общаться о том, что вы делаете и почему, как другим техническим специалистам, так и нетехническим специалистам, является действительно важным компонентом, смежным с кодированием.
И некоторые люди проводят здесь небольшое разделение между консалтинговыми и продуктовыми компаниями. Но я думаю, что это немного искусственно. Если вы работаете в производственной компании, вам все равно нужно уметь разговаривать с людьми в компании. И у вас может быть больше времени на построение отношений с этими людьми, чем в консалтинговой компании, где вы довольно регулярно перемещаетесь между командами. Но вам все равно нужно уметь говорить о том, что вы делаете, и почему и почему это важно, и почему это может занять больше времени, чем вы думали, или почему может быть какой-то лучший и более быстрый способ сделать это. Так что я думаю, что это может проявляться в том, что люди чувствуют себя уверенно, выступая на конференции, или наставляют кого-то еще, или учат кого-то еще.
И обучение чему-либо, будь то устная речь, письмо или индивидуальные занятия, определенно является действительно хорошим способом закрепить ваши собственные знания, потому что люди задают вопросы, вы читаете черновик сообщения об ошибке и понимаете, что есть пробел, и вам нужно чтобы пойти, узнать, что немного, чтобы заполнить. Но все сводится к тому, можете ли вы рассказать о том, что вы делаете.
N: Да, это великолепно. Одна вещь, о которой мы кратко говорили в прошлом, - это идея выхода из зоны комфорта и работы над навыками, которые важны, но неудобны. И для меня это иногда означает, что мне нужно изучить эту новую библиотеку Python, и на самом деле мне очень нравится писать сообщения в блогах, и мне нравится брать интервью у людей, но изучение этой библиотеки Python важно для меня, чтобы сделать следующий шаг в моей карьере. И вы говорили о навыках, с которыми могут столкнуться разработчики, например о продажах, понимании пользовательского опыта и обо всем остальном. Вы бы посоветовали людям более молодого возраста уделять больше времени совершенствованию таких навыков? Или вы скажете: «Вы получите нужные навыки, когда они вам понадобятся»?
Итак, есть одна школа мысли, которая утверждает, что быть универсальным - на самом деле действительно хорошая идея, потому что это означает, что вы постоянно мыслите нестандартно и постоянно осведомлены о разных вещах, которые могут повлиять на то, как получится этот продукт. . Вы думаете о лидерах продаж, вы думаете о маркетинге, но не сегментируете эти маршруты до запуска продукта. Вместо этого вы думаете об очень комплексном подходе к запуску чего-либо.
С другой стороны, вы вроде как разработчик. А твоя работа - развиваться. И поэтому вам действительно следует сосредоточиться на этом. И если есть что-то, что другим людям нужно от вас, они могут сообщить об этом, и вы сможете ответить им. И поэтому меня всегда действительно интересовало, где проходит эта граница, и как это работает, в частности, в карьере.
G: Да, это действительно интересный вопрос, и я думаю, что он очень зависит от контекста. Например, если вы работаете в компании с преданными продавцами, то понимание того, чем они занимаются, вероятно, действительно поможет вам эффективно выполнять свою работу. Потому что тогда вы можете общаться с этой командой, но вам, возможно, не придется иметь такой же практический опыт продаж, как если бы вы работали в такой компании, как Thinkbot, в которой нет преданных продавцов, а дизайнеры и разработчики выходят и разговаривают с потенциальные покупатели.
При разработке программного обеспечения я часто думаю о том, что абстракции имеют тенденцию к утечке. Мы создаем эти уровни, чтобы вместить сложность чего-либо, а затем строим поверх этого слоя, но часто небольшие кусочки этой сложности просачиваются через абстракцию. Таким образом, может быть полезно, когда эти утечки происходят, и когда вы сталкиваетесь с этими проблемами, чтобы понять слой, лежащий под тем, с которым вы работаете.
Итак, в зависимости от типа утечки, возможно, вы работаете над приложением Rails. И действительно, действительно полезно знать разработчиков или системное администрирование, такие навыки. Потому что может быть какое-то отношение к управлению процессами Unix, которое проникает в Ruby и становится очень важным для того, как ваше приложение ведет себя в определенных обстоятельствах.
В других случаях, когда вы понимаете какой-то странный уголок стандартной библиотеки Ruby, полезно знать немного C, чтобы вы могли пойти и прочитать исходный код этого метода Ruby, потому что какое-то странное поведение C просачивается на слой Ruby . Я думаю, что то же самое верно и для организаций. Если немного узнать о том, что находится рядом с местом, где вы работаете, ваша работа будет намного проще. В ходе своей консультационной работы я часто говорю клиентам: «Мы делаем что-то, что находится на пересечении вашего опыта в предметной области в вашей компании и нашего опыта в области создания веб-приложений». Но если мы оба не работаем над границами этого и не будем сотрудничать в этой области, мы не сможем построить то, что нужно.
Итак, мы должны немного узнать о проблемном пространстве, с которым мы работаем, а наши клиенты должны немного узнать от нас о пользовательском опыте или разработке приложений, или о том, что работает хорошо и не работает. хорошо в сети. И, получив знания о том, что не является вашей обязанностью, но непосредственно рядом с ней, вы сможете лучше выполнять свою работу и решать технические проблемы.
Как вы можете измерить прогресс в своей карьере?
N: Если вы продавец, маркетолог или специалист по продукту, у вашей эффективности действительно есть четкие ключевые показатели эффективности или, во многих случаях, есть некоторые ключевые показатели эффективности. Вы знаете, что если вы продаете вещи как продавец, у вас все хорошо. И если вы продаете то количество вещей, которое должны продать, вы делаете именно то, что должны делать. Как разработчик узнает, что у него все хорошо?
G: Есть сообщение в блоге, которое Джоэл Спольски написал об этом, я думаю, много лет назад, где он говорил о попытках, которые были предприняты для определения показателей для разработчиков. И я думаю, что одним из использованных примеров было: Что ж, может быть, мы могли бы измерить количество ошибок, которые разработчик закрывает, в системе отслеживания ошибок. Так что это могут быть принятые истории Pivotal tracker, или карточки Trello, которые перетаскиваются в последний столбец, или любая другая система, которую вы используете. И в целом они обнаружили, что люди действительно хорошо умеют оптимизировать по метрике, которая использовалась, а не по желаемому результату.
Я думаю, если попытаться количественно оценить это так же, как и в случае с продажами, есть довольно прямая корреляция между тем, что мы закрыли проект, и сумма в долларах выросла, и есть еще кое-что, что нужно сделать, и это хорошо для компании. И, да, было бы трудно сказать, удастся ли увеличить количество клиентов, если это не принесет хорошего эффекта, или количество долларов, не получив при этом хорошего эффекта. Но с разработкой программного обеспечения гораздо труднее дать количественную оценку.
Гораздо позже Брайан Хелмкамп из Code Climate в этом году выступил с докладом на саммите Code Climate о некоторых метриках, которые им удалось собрать из всех репозиториев Git, к которым у них есть доступ через Code Climate. И они видели что-то вроде: В среднем люди закрывают около двух запросов на вытягивание в неделю. Поэтому, комбинируя эти две вещи, я думаю, что опасно говорить: Вам следует закрывать два пулреквеста в неделю. Потому что очень легко закрывать два пул-реквеста в неделю, просто тратя меньше времени, внимания и внимания. Но я думаю, что вы можете использовать такие метрики, чтобы оглянуться на свое прошлое я и сказать: Хорошо, я делал это до сих пор? И если нет, то почему? Есть ли какие-то проблемы в процессе работы в моей компании, которые нам мешают? Или есть что-то, что я мог бы сделать лучше? Но помимо числовых показателей, на что вы можете положиться, чтобы знать, что у вас все хорошо?
N: Ага. Это также относится к обзорам производительности, не так ли? И если вы младший разработчик, приходящий в новую компанию, не зная, что такое метрики, или метрики не отображаются вам четко или даже не существуют на самом деле, как вы знаете, что готовы совершить скачок? или как узнать, что вы находитесь в нужном месте, если вам не на что противопоставить? Я всегда находил это действительно сложным. Также потому, что многие области, в которых мы работаем, являются новыми, и в них нет той корпоративной культуры, которая существует во многих других отраслях, таких как финансы или право, где это очень ясно. Вы перепрыгиваете через этот обруч, значит, вы на этом уровне. Вы перепрыгиваете через обруч, и тогда вы достигаете этого уровня.
Интересно, что для младших разработчиков, входящих в это пространство, есть много беспокойства или много ощущения, будто вы ступаете, стараясь не наступить на яичную скорлупу, спрашивая: «Ну что, я готов? Есть ли у меня хоть какой-то опыт? » Потому что нет свода правил. Вы читаете миллиард сообщений в блогах в неделю или слушаете все подкасты, которые только можете, и кормите себя как можно большим объемом информации. Но вы, возможно, все еще не приблизились к выяснению: «В моем следующем обзоре, моем следующем полугодовом обзоре или обзоре производительности, как мне провести разговор, когда я скажу, что, по моему мнению, я готов двигаться вверх, если есть мне нечем измерить себя? »
G: Я думаю, что, когда я работал с более молодыми разработчиками, одним из самых полезных для меня индикаторов в понимании того, где они находятся, как идут дела и каковы должны быть следующие цели, часто бывает читать код, который пишут люди.
К счастью, многие компании, в том числе Thinkbot, проводят проверку кода как часть повседневного процесса. Так что это не то, для чего нам особенно нужно изо всех сил стараться изо всех сил. Так что, если вы оставляете отзыв о запросах на включение и замечаете, что существует шаблон, тогда у вас есть возможность сказать: О, похоже, что область объектно-ориентированного дизайна - это то, над чем вы могли бы поработать. В обзорах запросов на вытягивание мы часто говорим о том, как эти объекты разбиты и структурированы, сколько у них обязанностей, как они взаимодействуют друг с другом, или что-то еще. Итак, вот книга об этом, которую вы можете прочитать. И в этом конкретном случае я бы, наверное, сказал POODR by Sandi Metz, если кому-то интересно.
Но я думаю, что это один из способов постановки целей и измерения прогресса - это возможность сказать: «Хорошо, я вел эти разговоры по запросам на вытягивание, и после этого я ушел и изучил этот материал, и теперь я У меня другой разговор о пул-реквестах ". И я не думаю, что цель состоит в том, чтобы когда-либо избежать обратной связи. Я не думаю, что кто-нибудь когда-нибудь будет отправлять запросы на включение, где, просто ...
N: Это прекрасно. Идеальный запрос на вытягивание.
G: Или в комментариях просто говорится: «Вау. В этом нет ничего плохого ". Но вы можете видеть-
N: Улучшение.
G: Улучшение и прогресс в этом. Особенно, если вы смотрите на время, и вы смотрите на совокупность, и вы не думаете о каждом просто так: «Ну что ж, это один запрос на вытягивание». Но вы оглядываетесь на несколько месяцев назад и спрашиваете: «Ну, как же все прошло?»
N: Но, опять же, мы возвращаемся к постановке целей и возвращаемся к выполнению перехода. Это как: «Да. Я вижу, что я улучшился абстрактным или нематериальным образом. Но достаточно ли этих абстрактных нематериальных способов, чтобы я теперь считался опытным разработчиком? » Или: «Да, я понимаю, что задаю вопрос другого типа. Но разве этот вопрос, относится ли он к другой лиге или это просто на другом языке? » Существует так много путаницы в том, как это выглядит на самом деле, если цели не ставятся с самого начала. Итак, одна вещь, которую я заметил в учебнике мыслебота и схеме учеников, - это то, что есть несколько довольно четких целей, и на протяжении всего процесса проводится постоянная проверка.
Но ранее мы говорили о том, что парное программирование не является отраслевым стандартом. Это инструмент, которым пользуются очень немногие, но при правильном использовании он может делать действительно хорошие вещи. Точно так же постановка целей для разработчиков и конкретные обзоры производительности не являются стандартом. И я думаю, что многие люди просто спрашивают: «Значит ли это, что если я достаточно смел, чтобы попросить повышения или попросить новую должность, то я получу это?» И это кажется невероятно произвольным и немного похожим на Дикий Запад в карьере.
G: Да, я думаю, что вы правы, и мне хотелось бы получить лучший ответ на этот вопрос. Я думаю, что здесь много ... Многие из них зависят от контекста, поэтому, например, в рамках той программы, которую мы проводим, ученик работает с наставником. Они разговаривают каждый день. Они еженедельно проверяют цели более подробно. В конце каждого месяца обычно делается передача новому наставнику с обсуждением общего прогресса в достижении цели - завершить обучение и стать разработчиком в Thinkbot.
Это довольно структурировано, но требует участия наставника, который готов сделать это и потратит на это столько времени.
Что бы вы сказали компаниям, которые хотят нанять разработчиков?
N: Что бы вы посоветовали стартапам, потому что вы работали в сфере стартапов и наставляли многих разработчиков. Какой совет вы дали бы стартапам или даже компаниям, которые нанимают разработчиков и не уверены, ищут ли они младших разработчиков, разработчиков среднего уровня или старших разработчиков? Я знаю, что Thinkbot помогает в этом многим компаниям. Таким образом, с одной стороны, молодые разработчики не знают, как позиционировать себя на рынке. С другой стороны, люди, которые знают, что им нужны технические вещи, не знают, как обращаться к нужным техническим специалистам. Итак, одна группа не знает, кто они такие, а другая группа не знает, как найти эту группу, которая не знает, кто они. Что бы вы посоветовали группе, которая ищет разработчиков?
G: Ага. Итак, три конкретных вещи. Один из них: адаптируйте процесс собеседования к работе, которую собираются выполнять люди. Если кто-то может перевернуть строку C на месте, не выделяя тепловую память, кого это волнует, если только вы не перевертываете строку в компании C. Но если вы пишете веб-приложения на Ruby, вам, вероятно, никогда не придется этого делать. Так что, если кто-то не может идеально написать этот сложный код на языке, который ему никогда не придется использовать для своей работы на доске без компьютера, это не совсем проверка его навыков.
N: Я был в том интервью.
G: И они, вероятно, нанимают не тех людей. Потому что они, вероятно, нанимают людей, которые разбираются в теории. И им нужны люди для практических занятий, поэтому в этом нет большого смысла. В Thinkbot мы делаем парное программирование на реальных вещах как часть собеседования. Последний этап собеседования - это день в нашем офисе, и вы проводите полдня в паре с одним человеком и полдня в паре с другим человеком, над тем, над чем эти два человека все равно работали бы в тот день.
И соискателю приятно видеть, как на самом деле он поработал в Thinkbot в течение дня. «Хотел бы я получать пять таких штук каждую неделю?» И нам тоже приятно видеть: «Может ли этот человек на самом деле делать настоящую работу?» Не какое-то моделирование работы, не какая-то теория, а реальная работа. Так что это одно. Адаптируйте процесс собеседования к работе.
Еще я хотел бы сказать: посмотрите на свой конвейер и как он работает, а затем адаптируйте свой язык. Если вы ищете младших разработчиков, а младшие разработчики не подают заявки, измените свое объявление. Сделайте это более явным. Ищите там вещи, которые могут отталкивать или пугать.
N: Как рок-звезды.
G: Как рок-звезды. Есть отличный инструмент, который написала Кэт Мэтфилд.
N: Ага. Это великолепно.
G: Итак, это хороший инструмент, и он будет вызывать такие вещи, как язык с тонкой гендерной кодировкой, а также просто неприятные слова, такие как рок-звезда. Так что посмотрите, кто подает заявку, и используйте это как отзыв, а также настройте и измените свой пост.
И третье, что я хотел бы сказать: посмотрите на команду, которая у вас сейчас есть, и настройте людей на успех. Так что, если вы действительно заняты, и у вас нет времени на все функции, которые вам нужно отправить, и тот, кто собирается присоединиться к вашей команде следующим, должен будет взяться за дело и доставлять вещи самостоятельно и ни у кого не будет времени обучать их, наставлять или помогать им, тогда, может быть, не нанимать кого-то только что из буткемпа, которому понадобится какое-то наставничество. Потому что вы не настроите этого человека на успех. В то время как если вы находитесь в более стабильной ситуации, когда вы инвестируете в долгосрочный рост команды, и у вас есть некоторая пропускная способность в своей команде для обеспечения наставничества и поддержки, и вы думаете о долгосрочной перспективе, тогда абсолютно. Наймите молодых людей и помогите им повысить свой уровень.
Как вы настраиваете людей на успех?
N: Это то, что я хотел затронуть. В среднем, похоже, что люди остаются в компаниях от 18 месяцев до двух лет в технологической отрасли, особенно в инженерной сфере. Как вы увеличиваете это число и как вы справляетесь с такими вещами, как уход за людьми или решение уехать? Я не обязательно думаю, что это плохо, когда люди решают уйти, потому что у нас обоих были карьеры, в которых было несколько итераций, и я думаю, что на самом деле нам было выгодно иметь эти итерации и сделать нас лучше в конце . Но для компании, безусловно, довольно утомительно необходимость обучать, переобучать, обучать, переобучать и удерживать приходящие когорты. Не только из-за усилий и распределения ресурсов для этого, но и потому, что, опять же, вы один из очень немногие компании, которые вкладывают значительные средства в парное программирование и довольно много вкладывают в наставничество. И это почти похоже на то, что если кто-то действительно уйдет, то на обучение этого человека было выделено больше ресурсов, чем в другой сфере. Как вы справляетесь с этим и как вы… С какими проблемами вы сталкиваетесь, удерживая людей на корабле?
G: Это может быть немного стандартным ответом, но я думаю, что Книга Дэниела Пинка, Драйв интересна тем, что в ней говорится о людях, которых мотивируют не только деньги. Вы должны платить людям достаточно хорошо, чтобы они не беспокоились, но тогда более мотивирующими факторами являются ... Я считаю, что это мастерство, поэтому ощущение, что вы постоянно становитесь лучше в том, что вы делаете, автономия, наличие свобода выбора в отношении того, как вы выполняете свою работу, и цели. Итак, понимание не только своей маленькой частички машины, но и того, как все это дает то, что стоит делать. Думаю, это может быть полезно для общей мотивации.
И в рамках этих вещей, мастерства, у людей должна быть возможность учиться и развиваться, и чувствовать, что они добиваются прогресса. И, скажем, при обучении в Thinkbot это довольно структурировано и довольно ясно. Там очень четкая цель. Я думаю, что потом будет немного сложнее и нечетко удостовериться, что это происходит и что люди чувствуют. У нас есть такие вещи, как инвестиционное время, у нас есть правила проведения конференций, и люди могут покупать книги и все такое, чтобы попытаться предоставить эти возможности. Но, возможно, он мог бы быть более структурированным, чем есть на самом деле. Возможно, это могло быть более формализовано, чем есть на самом деле.
Что вы ищете в резюме?
N: Что вы чувствуете, когда видите кого-то, у кого есть резюме, которое выглядит следующим образом: 18 месяцев, два года, 18 месяцев, два года, 18 месяцев, два года? Влияет ли это на ваше восприятие их как кандидата, или-
G: Нет. Я вообще-то не уделяю так много внимания резюме.
Я буду искать, какие технологии кто-то использовал в производстве в прошлом.
И я буду искать общий многолетний опыт работы в отрасли как нечеткое свидетельство того, чего, возможно, ожидать. Мы очень быстро переходим от обзора резюме к обзору образца кода в процессе работы интеллектуального робота, и я думаю, что просмотр какой-то работы, которую кто-то проделал за последнее время, гораздо больше говорит об их текущем уровне квалификации, чем обязательно количество лет или количество лет на эта компания или эта компания, или как часто они переезжали.
N: Многие компании отчаянно пытаются нанять технических специалистов. По моему мнению, у thinkbot есть много людей, которые подают сюда заявки. Как ты это сделал?
G: Я думаю, что у нас довольно хорошая репутация в мире разработчиков. Мы много ведем блог, вносим свой вклад в open source, выступаем на конференциях. Итак, люди слышали наше имя, люди использовали наши инструменты. И это действительно помогает людям, желающим прийти к нам. Я также думаю, что есть привлекательность в компании, которую возглавляют люди, которые делают вещи. В thinkbot не так уж много людей, не являющихся дизайнерами и разработчиками. Генеральный директор - разработчик. У нас нет большой повестки дня, кроме создания вещей, создания правильных вещей и создания хороших вещей, но создания вещей. И нет такой большой стороны в компании, которая не понимала бы, что такое делать вещи и что это значит. Так что довольно легко сказать разработчикам: «Эй, мы пытаемся сделать это место приятным для разработчиков, и мы знаем, что это значит, потому что мы такие». Я все время говорю «разработчики», я бы сказал еще и «дизайнеры». Просто разработчикам легче приходит в голову, потому что это моя роль.
Что бы вы хотели знать о младших разработчиках?
N: Нет, конечно. Ага. Я думаю, мы как бы приближаемся к последнему вопросу, а именно: есть ли что-нибудь, чего вы не знаете о младших разработчиках, что вы хотели бы понять? Или есть что-нибудь, о чем вы думаете: «Хм, интересно»?
G: Я думаю, что сложно сделать обобщение на такую большую группу людей. Но я не совсем понимаю, что люди ищут в долгосрочной перспективе. Я думаю, что большую часть времени, когда я разговариваю с младшими разработчиками, они ищут работу, где они могли бы получить больше опыта. Но я не знаю, какой шаг-
N: Чем больше опыта, тем лучше.
G: Да, каков шаг два, каков шаг третий? Итак, вы получаете эту работу, получаете больше опыта, и что тогда? Вы хотите чем-нибудь заняться после этого? Вы действительно хотите получить консультацию? Вы упомянули некоторые вещи, когда люди думают: «Ну, может быть, если я буду преподавать, я буду чувствовать себя опытным. Или если я буду выступать на конференциях ». Это цели для людей или их ожидает естественное достижение? Люди хотят оставаться в разработке? Хотят ли они перейти в другие области, например, более ориентированные на продукт или более ориентированные на управление? Я не уверен, что достаточно разговариваю с людьми в начале их карьеры, когда они говорят: «Ну что ж, что мне делать в первую очередь?» Примерно так: «Что ты хочешь делать после этого?»
N: Какое видение?
G: Ага.
N: Ага. Хорошо, это действительно интересно.
G: Но я также не думаю, что мог бы ответить на этот вопрос, только что окончив университет.
Мне просто нравилось писать код, и я хотел этим заниматься. И были люди, которые заплатили мне за это, так что это казалось хорошей идеей.
N: Вы были последовательны, так что это определенно есть. И большое спасибо за то, что нашли время поговорить со мной. Это был действительно забавный чат. И я думаю, что многому научился из этого разговора, так что спасибо.
G: Большое спасибо.
N: Ура.
