Connect with us

Разработка

Мы уволили нашего лучшего разработчика – и это стало нашим лучшим решением

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

Анна Гуляева

Опубликовано

/

     
     

Почему увольнение главного разработчика компании стало её лучшим решением? Мы перевели популярную историю, в которой один из сотрудников рассказал, как получилось так, что вся работа по проекту велась одним безумным гением, и в итоге затянулась на несколько лет.

“Вы никогда не поймете что-то из того, что я сделал. Я Альберт, [чертов], Эйнштейн, а вы все обезьяны, копающиеся в дерьме”.

Итак наш местный гений, наш доктор Джекил, полностью превратился в мистера Хайда.

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

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

Эта история посвящена одному очень одаренному члену нашей команды с глубоким пониманием архитектуры продукта. У него была сверхъестественная способность прогнозировать будущие потребности и тонна специфических знаний об отрасли.

Он был нашим главным сотрудником. Он убивал наш основной проект.

Назовем этого человека Риком.

Все знали, что Рика – главный талант нашей команды. Он был ведущим разработчиком и создателем архитектуры наших проектов.

Если у кого-то возникал вопрос или кому-то требовалась помощь, этот человек всегда шел к Рику. У него была гигантская белая доска, установленная только для этой цели. Она была всегда заполнена следами предыдущих дискуссий, которые не стирались до конца.

При возникновении любой достаточно сложной проблемы, Рик брался за неё. У Рика на столе был сервер с теми же характеристиками, что и наш производственный сервер. Он использовал его для запуска всего стека приложения и устранения неполадок на всех уровнях одновременно.

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

Вскоре Рик перестал посещать встречи. У него не было для этого времени, потому что было слишком много работы.

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

У Рика рос бэклог. В инструментах, созданных им прежде, возникали баги. Они отвлекали его внимание от требований по созданию нового продукта.

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

На доске нашего проекта зеленые флажки сменились на желтые. Желтые – на красные. Красные огни начали мигать. Задачи постепенно оказались отложенными. Все ждали Рика.

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

Рик писал код быстрее, чем когда-либо. Он работал семь дней в неделю, двенадцать часов в день.

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

День за днем Рик становился все агрессивнее и изолированнее. Джекил становился Хайдом.

Я участвовал в моей первой встрече с командой проекта примерно через два года после первоначальной согласованной даты выпуска. Некоторое время я знал об этом проекте, потому что он стал печально известным в моей организации, но не работал над ним.

Меня послали, чтобы узнать, можем ли мы спасти проект. Моя первая встреча была вышеупомянутой встречей с “Альбертом Эйнштейном”.

Я открыл исходный код. Рик был прав: никто не мог понять то, что он создал. Кроме него. Этот код был воплощением его разума. Что-то было очень умно, что-то было большим количеством копипасты, все было очень своеобразным, но ничего не было задокументировано.

Я отправился к CIO с вердиктом. Только Рик мог поддерживать этот продукт. Но каждый день его работы сдвигал дату готовности на неделю. Рик разрушал продукт быстрее, чем создавал.

Мы пригласили Рика обсудить его роль в проекте. Мы рассказали о своих опасениях. Мы пропустили его сравнение с Альбертом Эйнштейном.

Мы объяснили нашу новую стратегию. Команда должна была объединиться над созданием нового продукта с нуля. Эти усилия были бы очень ограниченными по объему и обеспечивали бы только основные потребности, которые были необходимы для выпуска продукта. Вся команда будет вносить свой вклад и сможет поддерживать продукт. Больше никаких бутылочных горлышек.

Как на это отреагировал Рик? Только так, как он мог отреагировать: он взорвался.

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

Мы уволили Рика. За неделю всё немного успокоилось. Шокированной команде понадобилось время, чтобы прийти в себя после потери своего гуру.

Затем я увидел, как они столпились у доски. Они объединялись. Они создавали новый продукт. Он будет гораздо проще. В нем не будет много функций, но он не потребует ещё пяти лет для создания.

Продукт Рика поддерживал динамический рабочий процесс с более чем пятнадцатью тысячами вариаций. На самом же деле 99% наших кейсов использования следовали одному из трех путей. Команда жестко закодировала рабочий процесс. Это позволило удалить более 30% работы Рика.

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

Они убрали сотни часов работы Рика. Но они убрали и тысячи часов технического долга.

Мы достигли соглашения со спонсором о прекращении работы над некоторыми функциями. Они были полезны только 5% группы пользователей, но составляли четверть сложности продукта.

Мы снова выпустили продукт для этой небольшой группы пользователей. Он на 10% состоял из стабильного кода Рика. Он также включал в себя несколько тысяч строк нового кода, которые заменили около 150 тысяч строк непонятного хаоса.

Команда завершила пять лет работы за шесть месяцев. За следующие несколько месяцев мы перешли от пилотной версии к полноценному релизу. Мы не только заменили то, что создал Рик, но и обогнали его и полностью запустили продукт меньше чем за год. Результат был в пять раз меньше и проще чем то, что создал Рик. Он был также в сотни раз быстрее и почти не имел багов, несмотря на то, что создавался за меньший срок и обслуживал в десять раз больше клиентов.

Команда вернулась к другим проектам Рика. Они убрали его старый код и оттуда. Они перевыпустили продукт, над которым он работал три года, всего за три месяца совместных усилий.

В команде больше не осталось Риков. У нас больше не было безумных гениев, создающих все с нуля. Но наша продуктивность никогда не была столь высокой.

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

Мастер строительства – это хорошо. Но небоскребы строят команды.

Его присутствие было разрушительным.

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

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

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

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

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

Сила вашей команды не зависит от талантов отдельных её членов. Она зависит от их сотрудничества, упорства и взаимного уважения. Создавайте команды, которые ценят друг друга и пытаются использовать лучшие качества каждого из участников. Вместе они смогут решить большие вызовы, чем Рик когда-либо мог себе представить.

 

Далее: Вы уволили лучшего разработчика. Надеюсь, вы довольны?

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
2 комментария

2 Comments

  1. Сергей Шинкарёв

    17.10.2017 at 11:42

    Если бы это было кино, самая деликатная рецензия выглядела бы так: полный набор голливудских штампов.

    Коллеги, зачем вы тратите время на такие поверхностные материалы?

    • AppTractor

      17.10.2017 at 11:47

      Ну так “полный набор” не отменяет происходящего и необходимости избегать таких ситуаций, нет? А вообще “хайпанули немножко”, да :)

You must be logged in to post a comment Login

Leave a Reply

Исследования

Какие эмодзи больше всего используют программисты

Эваристо Карабайо  проанализировал около 3,5 гигабайтов логов, чтобы узнать о том, какой эмодзи самый популярный у разработчиков.

AppTractor

Опубликовано

/

Автор:

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

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

В этой статье я рассматриваю то, как новые разработчики используют эмодзи, в частности, в Gitter Main Chat Room на платформе freeCodeCamp.

Есть как минимум два способа рендеринга эмодзи в Gitter:

  • с использованием псевдонимов (например, таких);
  • с использование UTF-8 путем написания эмодзи непосредственно ключевым словом или копированием/вставкой символа из онлайн-ресурса.

Оба по-разному рендерется в сообщении, причем первый визуализируется существующими изображениями Gitter, а второй показывается в соответствии с настройками вашего компьютера. Первый метод – «использования псевдонимов» – является самым популярным и будет основным предметом обсуждения.

Чтобы дать вам краткое представление о том, чем я интересовался, я хотел бы быстро осветить ответы на такие вопросы, как:

  • Есть ли явный шаблон в использовании эмодзи?
  • Каковы самые популярные эмодзи?
  • Сколько людей использует эмодзи?
  • Насколько люди разбираются в словаре эмодзи?

Поэтому давайте начнем и ответим на эти вопросы.

Поговорим об эмодзи

Проведя свой анализ чата freeCode, я узнал, что около 23% вовлеченных в разговоры в чате также были и любителями эмодзи. Я определяю слово «вовлеченный» как человека, который отправил не менее 10 сообщений. Если мы сравним вовлеченных и невовлеченных любителей эмодзи с обычными ценителями чатов, эта цифра возрастет до 45%.

Количество «эмодзионеров» в чате freeCode может показаться маленьким по сравнению с другими чатами и платформами. Однако важно отметить, что:

  • Многие пользователи чата очень скоро выходили из него.
  • Были пользователи, которые предпочли консервативное общение.
  • Некоторые пользователи могли и не знать о существовании эмодзи.

В целом, наши эмодзионеры отослали по крайней мере 753,000 эмодзи (или 600,000, если считать не общее количество эмодзи, а количество сообщений, в которых они появлялись) со средним значением 32 эмодзи для каждых 100 сообщений.

В целом, наши эмодзионеры показали коллективную грамотность, отослав около 800 самых разных эмодзи, то есть около 25% от полного списка. Я отобразил появление новых эмодзи с помощью D3.js, показав, что многие из них были впервые представлены в чате в период с июля 2015 года по июль 2016 года с темпом роста от 10 до 20 новых эмози в неделю.

В среднем один человек использовал около трех разных эмодзи. Такое число получилось потому, что были у нас и настоящие профессионалы эмодзи – так, один использовал около 500 различных эмодзи.

Нетипичные эмодзи в чате?

Чтобы лучше понять, как люди обменивались эмодзи в чате, я сравнил свои выводы с докладом, подготовленным SwiftKey в 2015 году. Эти данные немного устарели, поэтому я добавил данные unicod.org. Объединил их и вот что получилось.

Сначала я оценил использование эмодзи на уровне категории, и результаты были очень похожими на отчет SwiftKey. Большинство эмодзи, размещенных в чате freeCodeCamp, принадлежали к категории «Смайлики и люди», которая включает лица, жесты, персональные роли, части тела и сердца.

Поскольку сравнения, основанные на категоризации высокого уровня, обычно слишком непонятные, я попробовал другое сравнение, сосредоточившись на 25 наиболее используемых эмодзи с 2015 по 2017 год, используя их подкатегории. Вместе эти 25 эмодзи составляли около 15% всех, отправленных в течение этого периода смайликов.

Список эмодзи и их подкатегорий показывает, что наши эмодзионеры все равно хорошо вписываются в типичную модель пользователя эмодзи. Широкое использование иконок категории «Позитивные лица» совпало с подкатегорией «Счастливые лица» SwiftKey.

То же самое было и с подкатегорией «Негативные лица», подобной категории «Печальные лица» SwiftKey. Немного обособленно было использование «: trollface:», которое является доступным значком в GitHub, и обычно оно связано со спам-сообщениями и вредительством, но также используется как шутка в чат-комнате freeCodeCamp. «Какашка» 💩 также была в числе 25 самых используемых эмодзи.

Наиболее часто используемые значки жестов в чате freeCodeCamp являются положительными, связанными с приветствием, поддержкой, доверием и признанием успеха. Еще одно отличие заключается в меньшем использовании значков, таких как «сердца» ♥️ или «поцелуи» 💋, что говорит о том, что поиск партнера не был главной целью этого чата. В чате находится обычно около 70-80% мужчин, что может объясняться тем, что они использовали иконки с оружием 🔫.

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

И награду получает…

В качестве бонуса я написал код с графиком, который показывает Топ-5 наиболее часто используемых эмодзи на freeCodeCamp. Что интересно, некоторые эмодзи набирают постепенно популярность, в то время как другие постепенно сдают позиции. Это очень похоже на «Тур де Франс». Сегодня эмодзи является самым востребованным, а завтра о нем забывают.

Итак, вот самый популярный смайлик:

Честно говоря, я не ожидал, что 😄 («: smile:») станет самым популярным эмодзи. Я думал, что им будет 😂 («: joy:») , учитывая, что Apple недавно назвала его самым популярным за 2017 год.

Следующие 8 эмодзи также появлялись в чате freeCodeCamp. Угадайте, как называется каждый из них.

Я использовал Python и Gitter API, чтобы получать сообщения из основной комнаты чата freeCodeCamp. Библиотеки Python, такие как мультипроцесс и эмодзи, использовались для преобразования данных.

Часть преобразований также требовала данных, доступных в интернете, для которых я сделал настраиваемые скребки, также с библиотеками Python (запросы, urllib, BeautifulSoup4).

Для анализа данных я использовал простой Python и некоторые панды. Визуализация была сделана с использованием matplotlib, а интерактивные графики — в D3.js.

Версии кода доступны в моем репозитории GitHub вместе с несколькими конечными наборами данных. Что касается необработанных наборов данных, используемых для этого проекта, они теперь доступны в Kaggle freeCodeCamp.

Комментарии
Продолжить чтение

Обучение

Истории разработчиков, получивших первую работу после 30, 40 и 50 лет

Куинси Ларсон, преподаватель в freeCodeCamp, собрал более 300 историй разработчиков, которые доказывают, что начинать учиться программированию никогда не поздно.

Анна Гуляева

Опубликовано

/

Почему я это сделал

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

Мне __ лет. Мне уже поздно учиться разработке?

Это один из самых распространенных вопросов в разработке в целом. Чтобы показать вам, сколько разработчиков волнует их возраст, я зашёл на Quora. Конечно, я нашел людей всех возрастов, которые переживают из-за того, что они «слишком старые», чтобы учиться программированию и становиться разработчиком: 60, 59585756555453, 52, 51504948474645444342414039383534333231, 29282726252423222120191817161514.

Что вы скажете кому-то, кто переживает, не слишком ли уже поздно? Многие люди ограничатся старой цитатой Уолта Диснея: «Если вы можете представить это, вы можете сделать это!»

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

Я получил первую работу в качестве разработчика в 31. И, конечно, я верю, что возраст — это просто число. И что все, кто могут вложить в обучение свои силы, могут научиться программировать и получить работу.

Но как мне убедить всех этих людей, задающих этот вопрос каждый день? Просто говорить «не переставайте верить» — неэффективно.

Я собрал доказательства, чтобы убедить людей расслабиться по поводу возраста

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

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

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

Поэтому однажды, после очередной попытки успокоить тревоги людей, я пересмотрел свой подход. Я подумал: «Возможно, я смогу найти список разработчиков, которые получили первую работ в 30, 40 или больше лет. Может быть, это убедит людей перестать так беспокоиться о возрасте».

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

Оказалось, что многие разработчики получили первую работу в 30, 40 или 50 лет. Вот несколько историй:

https://twitter.com/mikleane/status/949452946600730626?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F2215e9cee7ade93a7ffbf76c00f6702a%3FpostId%3D64306eb6bb27

https://twitter.com/americanwombat/status/949486088325799937?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2Ff3305f7a1f903b59e7c4c9a9c6edd974%3FpostId%3D64306eb6bb27

https://twitter.com/jefflazerus/status/949457462939205632?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2Fc3053bd231b0056db2839f8c57f3828d%3FpostId%3D64306eb6bb27

https://twitter.com/peterdaily/status/949453856127307776?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F054d685fc2fed0e12bfc45634abf6296%3FpostId%3D64306eb6bb27

https://twitter.com/gillessew/status/950138976655912960?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F48799b09a4826507d15624371e46bf60%3FpostId%3D64306eb6bb27

https://twitter.com/amwcodes/status/949581047808716800?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F46ff7a793cd12eb3273696b47e4f17f3%3FpostId%3D64306eb6bb27

https://twitter.com/dbriesz/status/949483215256825856?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F5daccc8369b60bb9807d39e133237d74%3FpostId%3D64306eb6bb27

https://twitter.com/jessdelgrande/status/950163504773902342?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F700f10a61f7d7a18fd00ba8d9bc31ecf%3FpostId%3D64306eb6bb27

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

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

Комментарии
Продолжить чтение

Новости

Интересные материалы: 18.01

Под конец дня – Unity 2018, приложение по доставке и огромное академическое исследование стоимости разработки игр.

Леонид Боголюбов

Опубликовано

/

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Мероприятия

Как я участвовал в хакатоне с 13 днями опыта в программировании

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

Анна Гуляева

Опубликовано

/

Я даже не понял, что подал заявку на хакатон. Я услышал этот термин в подкасте CodeNewbie, когда кто-то делился своей историей. Из подкаста я запомнил рекомендацию стать частью сообщества. Поэтому, когда я увидел пост в группе freeCodeCamp Las Vegas о мероприятии StartUp Weekend, он привлек мое внимание.

Это мероприятие было посвящено созданию новых компаний через объединение предпринимателей, дизайнеров и разработчиков. Но, согласно моему аккаунту freeCodeCamp, я занимался программированием всего 13 дней. Я оставил комментарий под постом и спросил, могу ли я получить пользу от этого мероприятия, несмотря на нехватку знаний и опыта. Мне ответил Майк Зиетлоу и сказал, что я могу получить пользу, только мне нужно будет постараться. Поэтому я оставил заявку на то, что я сначала принял за митап.

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

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

Майк на питче своей идеи

Выбор команды

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

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

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

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

Работа над проектом

Наконец пришло время работы над проектом. До этого мероприятия я писал код в браузерных редакторах в freeCodeCamp и CodePen. После общения с командой я скачал VS Code. Я понял, что не понимаю, как все это работает. Мне нужно было разобраться с git, концепцию которого я понял, но мне ещё многому предстояло научиться. В один момент я работал над master вместо своей ветки. Эта работа была довольно нервной. Я думал, что подведу всю команду. Но, к счастью, я ничего не разрушил.

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

Мне напомнили заходить в Google, как только я застряну. Это звучит несложно, но я думаю, здесь есть особая техника. Я должен был знать, что задаю верные вопросы и получаю нужные ответы. Потом я понял, что никто не хотел браться за работу, которую дали мне. Я пока слишком мало знаю, чтобы понять, почему все ненавидят CSS.

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

Итоги

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

Я думаю, что значительная часть успеха команды основана на лидере. С самого начала Майк страстно относился к своему проекту. Большую роль сыграло его решение уделить время познакомиться друг с другом. Он также сыграл роль куратора, и наш успех во многом основан на том, что в команде был человек, который понимал конечную цель и средства для её достижения.

В итоге мы заняли второе место! Я рад, что поучаствовал в этом событии. Хотя оно и прервало мою 13-дневную серию на freeCodeCamp, я бы сделал это снова.

Комментарии
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X

Спасибо!

Теперь редакторы в курсе.