Connect with us

Разработка

Inkdrop: как я создал редактор, зарабатывающий $1300 в месяц

Я поделюсь своим опытом по созданию мультиплатформенного приложения Inkdrop в одиночку. Это приложение теперь приносит мне 1300 долларов в месяц.

Анна Гуляева

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

/

     
     

Создатель кроссплатформенного приложения Inkdrop Такуя Матсуяма поделился советами для работы над сторонними проектами, которые он вывел для себя при самостоятельной работе над своим продуктом.

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

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

Ежемесячный доход приложения – $1361

TL;DR

  1. Найдите проблему, с которой вы сталкиваетесь каждый день
  2. Работайте над MVP, пока не будете довольны
  3. Получайте первых пользователей при помощи приватного бета-тестирования
  4. Сосредоточьтесь на стоимости
  5. Используйте Stripe для обработки платежей
  6. Создайте идеальный лендинг
  7. Сконцентрируйтесь на предоставлении хорошей пользовательской поддержки
  8. Запишите, что вы узнали при работе над проектом
  9. Улучшайте качество
  10. Игнорируйте критику

Найдите проблему, с которой вы сталкиваетесь каждый день

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

Около двух лет назад я был очень раздражен созданием заметок о разработке. Я перепробовал множество приложений, основанных на Markdown, но не мог найти подходящее. Веб-сервисы, такие как Wiki, было сложно найти во множестве вкладок и нельзя использовать офлайн. Приложения, использующие облачные сервисы вроде Dropbox, слишком медленно синхронизируются и потребляют слишком много оперативной памяти, потому что я храню в них много файлов. Я не мог принять приложение со слишком маленьким количеством функций, слишком сложное приложение или недостаточно красивое. Эти проблемы в моих предпочтениях были очень важны, поэтому я решил создать собственное приложение для заметок, когда устал искать идеальное.

Работайте над MVP, пока не будете довольны

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

Мое приложение для заметок:

  • Имеет похожий на GitHub markdown-редактор
  • Простое
  • Имеет красивый интерфейс
  • Быстро синхронизируется
  • Работает офлайн

Другие требования тривиальны. Я выбрал Electron для создания кроссплатформенного приложения для десктопа. ReactJS был отличным выбором, потому что для создания мобильной версии я использовал React Native. Чтобы достичь быстрой синхронизации, я использовал CouchDB и PouchDB. Они отлично работают в приложениях Electron. Благодаря CodeMirror, мне удалось создать отличный Markdown-редактор практически не прилагая усилий. В дизайне UI вдохновением для меня послужил интерфейс Airmail.

Это был мой первый опыт использования Electron и ReactJS. Поэтому я начал использовать Kitematic, менеджер контейнеров Docker с открытым исходным кодом, потому что они уже решили множество проблем за меня.

Получайте первых пользователей при помощи приватного бета-тестирования

Как только я создал MVP, который был достаточно хорош для получения отзывов людей, я решил устроить приватное бета-тестирование. Я никогда не устраивал публичного бета-тестирования. Как сказал Дэвид Хейнемейер Ханссон в своей книге Getting Real:

Не используйте “бету” как козла отпущения… Бета-тестирование сваливает ответственность на ваших пользователей. Если вы недостаточно уверены в своем релизе, почему вы ожидаете, что остальные будут уверены? Приватное бета-тестирование – это нормально, публичное – ерунда. Если продукт недостаточно хорош для публичного использования, не давайте публике его использовать.

Для приватного бета-тестирования я разместил ссылку на Hacker News, она попала на главную страницу и собрала больше тысячи заявок. Бета-пользователи предложили мне много разных вещей и отправили отчеты о багах, чем помогли мне улучшить приложение до официального релиза.

Трафик с Hacker News

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

Сосредоточьтесь на стоимости

Самое важное – убедиться в том, что всё стабильно. Фиксированная стоимость потребует от вас продолжать продажи, добавляя все больше и больше. С приложением, основанным на модели подписки, вы должны постоянно предоставлять ценный сервис.

Я решил продавать приложение по $4,99 за месяц и $49,9 за год с 60-дневным пробным периодом. Я не пытаюсь создать следующей Google, и мне не нужны сотни миллионов пользователей. Это просто нишевое приложение, в которое не инвестируют крупные компании. Поэтому стоимость не должна равняться на другие крупные сервисы, например, Evernote, даже если она кажется слишком большой для некоторых людей. Аудитория приложения – такие же люди, как я, которые захотят платить за свои любимые инструменты.

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

Используйте Stripe для обработки платежей

Stripe – популярная платежная платформа, доступная в Японии, которая позволит вам принимать платежи из других стран. Я был удивлен, насколько у них мощный и понятный API. Например, Stripe предоставляет:

  • Пробную подписку
  • Предоставление скидок на подписку при помощи купонов
  • Продуманные уведомления о том, что подписка заканчивается
  • Email-квитанции
  • Автоматическое распределение стоимости подписки при смене плана пользователем
  • Клиентская библиотека, не требующая от пользователей отправки информации о карте на ваш сервер

С этими функциями мне удалось быстро внедрить платежи.

Создайте идеальный лендинг

Я просмотрел множество отличных лендингов моих любимых сервисов, например, Sketch, Stripe, Mixpanel, Airmail и Basecamp, чтобы узнать, что входит в эти страницы. Вот чеклист для создания идеальных лендингов:

  • Быстрое объяснение
  • Демо (скриншот, видео, образец и т.д)
  • Главные преимущества
  • Стоимость
  • Отзывы
  • Call-to-action

Промовидео – очень мощный инструмент, который показывает, как действительно выглядит приложение и как его использовать. Качество не так важно. Я создал простое видео самостоятельно при помощи Adobe After Effects и iMovie. Я не знаю человека из видео, я купил эти клипы на VideoHive. Множество фоновой музыки продается на AudioJungle, поэтому я смог создать отличное видео за несколько дней и с небольшими затратами.

Я использовал After Effects для создания демо с динамическими переходами, но обработка занимала много времени, поэтому для монтажа я использовал iMovie.

Сконцентрируйтесь на предоставлении хорошей пользовательской поддержки

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

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

Создание привязанности при помощи быстрой и чуткой поддержки эффективно для приобретения платящих пользователей.

Запишите, что вы узнали при работе над проектом

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

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

Вот англоязычная версия статьи, которая также привела пользователей на сайт.

Улучшайте качество

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

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

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

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

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

Игнорируйте критику

Если вы пытаетесь угодить всем, вы не угодите никому.

Я получал много критики с момента открытия бета-тестирования, например, “Что будет, когда приложение закроется?”, “Оно выглядит, как Electron-приложение, но с плохой производительностью и памятью”, “$50 в год – это нелепо”, “Я не могу доверять безопасность удаленному серверу”, “А, оно по подписке. Это не для меня”.

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

Я игнорировал критиков и был сосредоточен на довольных пользователях. Этот подход должен развивать ценность приложения.

Надеюсь, это поможет в вашей дополнительной работе!

 

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

1 Comment

  1. Alexander Kurdadze

    29.09.2017 at 11:39

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

    Спасибо автору

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

Спасибо!

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