Connect with us

Разработка

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

Продолжение спорной истории об увольнении лучшего разработчика компании: инженер Тони Робинсон разобрал объективные ошибки менеджмента, которые в итоге и привели к ситуации, описанной в оригинальной статье.

Анна Гуляева

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

/

     
     

Продолжение спорной истории об увольнении лучшего разработчика компании: инженер Тони Робинсон разобрал объективные ошибки менеджмента, которые в итоге и привели к ситуации, описанной в оригинальной статье.

Давайте присядем, нам нужно поговорить. Если вы не читали эту историю, то прочитайте её и впитайте.

Закончили? Отлично. Давайте проанализируем её, потому что здесь скрыто намного больше. Если вы прочитали историю, вы понимаете, что автор описывает проблемного сотрудника, которого он прозвал “Рик”. Рик – это местный гений с массой специфических знаний об их продукте и ключевой участник команды разработки этого продукта.

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

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

Лично я считаю, что если такие люди приходят к вам на собеседование, несмотря на то, какой у них талант, они не стоят вашего времени из-за разлада, который они вносят в команду. Это указано и в самой истории – то, как Рик игнорировал встречи и принижал своих коллег. После того, как Рик ушел, продуктивность возросла, и они объединились, чтобы спасти проект. Автор делает так, чтобы вы возненавидели Рика и сказали: “Да! К черту этого парня! Похоже, что менеджеры наконец набрались смелости и отправили эту рок-звезду погулять! Я хочу работать с этими людьми!”

Посмотрите на мою историю! Я буду использовать персонажей поп-культуры и мемы, чтобы быть ближе к аудитории!

Если вы были достаточно внимательны, в статье возникало несколько тревожных звоночков:

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

При возникновении любой достаточно сложной проблемы, Рик брался за неё.

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

Где документация? Где встречи по обсуждению этих проблем и путей их решения?

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

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

В этой точке Рик больше похож на Тириона Ланнистера. Он умен и может решать разные проблемы.

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

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

Где были менеджеры? Где метрики? Серьезно, за время своей работы в IT и информационной безопасности я запомнил одно – менеджерам нужны показатели.

Всем было все равно, что Рик пропускал встречи? Никто не измерял количество открытых и закрытых проблем? Никто не документировал проблемы и их решение? Никто не замечал, что Рик запер себя, так как у него было все больше и больше работы?

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

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

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

Рик брал на себя больше работы, чем он мог сделать, и вдобавок он работал по 12 часов семь дней в неделю. Никто ничего не сказал, когда заметил, что Рик находился в офисе или работал удаленно дополнительные часы, дни и недели? Менеджеры не вмешались, чтобы потребовать, чтобы Рик сделал шаг назад и задокументировал свою работу? Никто не проверил его список задач и не решил, что задания нужно распределить? Сверх того, менеджмент позволил этому продолжаться два года?

Где были менеджеры? Где были тимлиды?

Мы пригласили Рика обсудить его роль в проекте.

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

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

Представьте, что месяц за месяцем, или даже несколько лет, вас считают краеугольным камнем и доверенным сотрудником компании. Может быть, даже ответственным за главный продукт. Вы уже долгое время работаете по графику 12×7. Никто этого не ценит, а ваш объем работы только растет, пока этот монстр ужасных хаков и недокументированного кода не начинает угрожать вам, как монстр Франкенштейна.

Все в порядке. Вы все контролируете. Вы можете вернуться и исправить все позже. Вы можете убрать эти пластыри импровизации и заменить их нормальным кодом, которым вы будете гордиться. Сейчас у вас в коде есть части, которые кажутся загадкой даже вам. Мы вернемся, перепишем этот код и задокументируем его. Все, что мне нужно сделать, это довести продукт до RTM/GA, и тогда я смогу вернуться и все улучшить. Я им нужен. Моя работа важна. Мне нужно все сделать. Я не могу провалить. У нас кончается финансирование. Я не могу потерять работу.

Что если я потерплю неудачу? Как я восстановлюсь? Смогу ли я восстановиться?

И вот вас приглашают на встречу с менеджерами и говорят, что вашу работу начнут с нуля. Как вы можете отреагировать? И не говорите, что вы примете это со смирением.

Повторите?

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

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

Культура стартапов не задает такие вопросы, потому что эта культура (как, во многом, и культура IT) не заботится о вашем благополучии. Только о вашей работе и об ограничении своих обязательств, если им придется вас уволить.

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

Это чувство свободы начинает исчезать, когда ваши сбережения быстро истощаются (учитывая, что компания автора находится в Калифорнии, где нелепо дорого жить), и превращается в ужас, когда эти вопросы начинают преследовать вас:

– Найдете ли вы работу вовремя? Выдержите ли вы это? Почему они уволили вас, когда вы отдали им все? Почему никто не боролся, чтобы оставить вас в компании?

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

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

Вместо этого они вертели Риком, как хотели, эксплуатировали его талант и навыки, и, как только он перегорел, выгнали его ради продуктивности компании. Как смело и героично!

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

Вместо того, чтобы создать историю о том, как они остановили падение человека при помощи вмешательства, выдающейся командной работы и грамотного руководства (что действительно нужно людям из IT), они решили рассказать о токсичной среде и проблемах, причиной которых, как казалось, был Рик. Вместо того, чтобы затронуть корень проблемы, они решили применить быстрое и простое решение. Что и следовало ожидать.

 

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

3 Comments

  1. Глеб Ткачук

    18.10.2017 at 17:35

    Тут что-то пошло не так. При переходе по ссылке все нормально https://uploads.disquscdn.com/images/e184b971787f93c639b07c18f9ee9e4f0be93116974c2ecdb4ac27dd3665e05d.png

You must be logged in to post a comment Login

Leave a Reply

Новости

Digest MBLTdev: Новости для iOS разработчиков №152

В течение недели топовые iOS-разработчики Руслан Гуменный, Саша Черный и Саша Зимин, а также директор по продукту VK Иван Козлов собирают для вас интересные и полезные ссылки на статьи, необходимые для прочтения каждому начинающему и опытному разработчику. В каждом выпуске – новости, коды, инструменты, дизайн и прочее.

e-Legion

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

/

Автор:

Кстати, о командах. Опрос о скорости работы команд Android- и iOS-разработки показал следующее: iOS-команда хоть немного быстрее — 32,4%, команды в общем-то равны — 24,9%, Android-команда хоть немного быстрее — 42,7%. В опросе приняли участие 185 человек и один учёный кот.

Почему мы видим то, что видим — как всегда отдельный вопрос, но с личным наблюдением некоторых авторов дайджеста совпадает. Нам же, iOS-разработчикам, стоит подумать: что изменилось? iOS стала сложнее, хуже? Качество разработчиков? Сложность создаваемых продуктов?

1

Опрос про отечественные команды мобильной разработки

А вот и ещё один опрос, который заполнят многие, а в итоге мы получим обработанную информацию о том, какие же компании работают над Dev PR’ом лучше всего, и откуда выходят самые активные мобильные разработчики :)

GOO.GL

Tim Cook says users will be able to turn off iPhone battery performance throttling in future iOS update

История с тормозящими айфонами подходит к концу. Теперь Apple обещала дать пользователям выбор: долгая жизнь батареи или быстрый девайс.

9TO5MAC.COM

Xcode Activity Time Tracking. Results of 2017

Два разработчика год собирали статистику про свою работу в Xcode. Сколько времени проходит от Cmd+B до успешной сборки? А до неуспешной? А с тестами как?

MEDIUM.COM

Universal link broken in iOS 11.2

Незамеченная, но очень важная новость: диплинки сломаны в iOS 11.2. Так что не пугаемся и ждём свежего релиза с фиксом.

STACKOVERFLOW.COM

4

Uber RIBs

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

GITHUB.COM

A better way to update UICollectionView data in Swift with diff framework

Про DeepDiff мы писали. А вот вам статеечка про применение DeepDiff к UICollectionView. В конце — абзац про производительность. С картинкой!

MEDIUM.COM

Swift 4.1 Beta

Apple активно развивает 4.1. И там уже много интересного. Например, Struct и Enum получили дефолтный hash и equal, array/dictonary/set получили дефолтный Codable/Decodable, полностью реализован KeyPath и так далее. Прямо праздник какой-то.

GITHUB.COM

Обновление строк на лету в мобильных приложениях: часть 1

Вводная статья про то, как команда Badoo подошла к локализации приложения.

HABRAHABR.RU

2

iOSSnapshotTestCase (previously named FBSnapshotTestCase)

Помните FBSnapshotTestCase, единственную нормальную библиотеку для UI Snapshot тестов на iOS, которую забросили Facebook в этом году? Так вот, Uber взяли её под своё крыло и обещали поддерживать. Хорошие новости, господа.

GITHUB.COM

16f106c0eaa442b184873f18f426a916

All-English conferences for Cocoa developers.

Список будущих (и прошедших) конференций для iOS-разработчиков с датами, городами и информацией по CFP.

GITHUB.COM

Computer latency: 1977-2017

Товарищ вооружился высокоскоростной камерой и измерил время между нажатием на кнопку/экран и рендром символа на экране. Интересно, что iPad Pro c Pencil является самым быстрым в его тесте.

DANLUU.COM

Affine transformations

Аффинные преобразования — очень важная для понимания штука, если дело доходит до анимаций. Вот немножко теории.

ELI.THEGREENPLACE.NET

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

Разработка

Интересные материалы для разработчика мобильных приложений #197 (15-21 января)

В новом дайджесте мы рассказываем про особую магию HQ Trivia, самую необычную головоломку в Google Play, мгновенную локализацию, итоги 2017 года и перспективы 2018.

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

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

/

Пожалуй, самая необычная головоломка на Google Play

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

Распознавание жестов движений на Android используя Tensorflow

В сегодняшние дни есть много разных способов взаимодействия со смартфонами: тач-скрин, аппаратные кнопки, сканер отпечатков пальцев, видео камера (например система распознавания лиц), D-PAD, кнопки на гарнитуре, и так далее. Но что насчет использования жестов движений?

Реверс-инжинеринг iPhone 2G

Для проведения опытов нам понадобится сам телефон порвергнутый Jajebreak’у, программа IFunBox для просмотра и модификации системных файлов, дизассемблер IDA, HEX редактор. На моем телефоне установлена IOS 3.1.3, но данные модификации будут работать и на других версиях(может быть).

 iOS

 Android

 Разработка

 Аналитика, маркетинг и монетизация

 Устройства, IoT, AI

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

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

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

Эваристо Карабайо  проанализировал около 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, и я добавлю вас в список.

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

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

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

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

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

Вакансии

Популярное

X

Спасибо!

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