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

Flutter - самая популярная кроссплатформенная (Android + iOS) платформа. Каждую неделю публикуется с десяток статей о Flutter - это НЕ одна из таких статей:

  1. Мои причины изучить Flutter и не терять руки
  2. Моя методика по изучению этого или чего-то нового
  3. Мои мысли о Flutter и то, что я узнал

Почему я научился флаттеру?

У меня более 20 лет опыта - около 1/2 на руководящих должностях, а в последнее время на довольно высоких должностях. Я написал код на десятке языков / экосистем, мне нравятся мои основные инженерные навыки и знания, и я увлечен технологиями. Однако…

  1. Мы все начинаем ржаветь. Мы начинаем верить, что «инженерные принципы не изменились, изменились только инструменты / языки» - и, поскольку принципы - это ключ, мы можем игнорировать новые вещи - в некоторой степени верно, но однажды вы просыпаетесь и все еще думаете, что мир плоский ??
  2. Мы избегаем попадания в руки. Разве это заставляет нас чувствовать себя слабыми / неполноценными, зная, что мы можем (или привыкли) выполнить задачу на C или Perl за час, но теперь нам придется возиться с последними версиями Kotlin, Dart или Julia? Действительно ли избегание наших слабостей работает надолго? Так Майкл Джордан стал величайшим?
  3. Мы привыкли делегировать полномочия, особенно если что-то техническое и практическое. На самом деле мы можем предложить только плоды нашего прошлого опыта, то есть «общее руководство». Руководство - это здорово, но конкретные и подробные решения еще лучше, не так ли?

Есть контраргумент, что менеджеры должны сосредоточиться на управлении, а проектирование оставить инженерам. Проблема в том, что двое не говорят на одном языке - и, следовательно, общение прерывается и приводит к ошибкам и кризисам. Это способствовало катастрофам космического корабля "Шаттл" и 737-MAX, а также бесчисленному количеству других катастроф, в которых инженеры и руководство не смогли понять друг друга. Из отчета НАСА о Challenger и недавнего анализа [14]:

«… Конфликт между инженерными данными и суждениями руководства и структурой управления НАСА, которая позволила внутренним проблемам безопасности полетов обойти ключевых менеджеров Shuttle».

«Менеджеры НАСА слушали инженеров и их PowerPoint. Инженеры посчитали, что они сообщили о потенциальных рисках. НАСА чувствовало, что инженеры не знали, что произойдет, но все данные указывают на то, что повреждений недостаточно, чтобы подвергнуть опасности жизнь экипажа ».

У лучших менеджеров и лучших команд есть руководители, которые разбираются в деталях и могут руководить как менеджментом / людьми, так и технически. Это редкий единорог, но он является одним из самых успешных команд. Исторический пример - создание атомной бомбы возглавлял ученый, а не бюрократ - Роберт Оппенгеймер. Есть интересные анекодоты и цитаты, которые довольно красноречивы (некоторые из его заклятых врагов!).

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

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

Подавать личным примером и активно руководить. Это намного проще сделать, когда вы соприкасаетесь с технологиями (буквально руками на клавиатуре).

Кстати, я не собираюсь в ближайшее время возглавить команду Flutter. Так помогает ли мне это как техническому менеджеру в целом? Я думаю, что это так - он повторно запускает ту часть вашего мозга, которую ваши инженеры используют ежедневно, и напоминает вам, что работа - это весело, но действительно сложно (и еще труднее избегать ярлыков). Сочувствие и понимание вашей команды и их работы имеют решающее значение для успеха.

Отступление: как учиться

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



Образование в летучей мыши: семь принципов для педагогов
Когда профессор Гарвардской школы образования Дэвид Перкинс оглянулся на свою маленькую лигу детства и… www.gse.harvard .edu



Эта команда онлайн-обучения FastAI использует этот подход (см. Статью Рэйчел Томас). TL; DR; - забудьте старые методы обучения, изучая древние тексты и заучивая символы - выходите из калитки и получайте удовольствие.

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

Мой подход к обучению:

Уровень 0: пассивное слушание / чтение / просмотр. (требуется всего 4–6 часов)

  • Обычно после того, как я читаю статью, я думаю: «Вау, это здорово, я полностью понял!». (Пассивное обучение 5–10%)
  • Посмотрите несколько видеороликов на YouTube и закрепите мои потрясающие навыки самообучения! (Аудио-видео - 20%)

На этом этапе запустите IDE и попытайтесь написать код ... который у меня быстро не получается (обычно с пустым экраном) ... в основном мои ~ 4 часа пассивного обучения == 0 способность создавать что-либо. Уровень 0 «нуб» - ›бесполезен, кроме как для создания слайдов PPT.

Уровень 1. Практика - Учебное пособие по написанию кода. (требуется 1–3 дня)

  • Затем я кодирую демонстрационный проект (клон из github) или следую руководству из книги или видео.
  • Во время или после я взломаю демонстрационный проект, чтобы добавить функции, которые вы хотите добавить / изменить / удалить.

Сейчас я могу что-то взломать и запустить (обучение сверху вниз на практике), но я действительно не знаю, что делаю. «Студент» уровня 1 - ›вы знаете достаточно, чтобы быть опасным (очень опасным).

Уровень 2. Кодирование с нуля. (требуется несколько недель)

  • Если ваша цель - выйти за рамки базовых знаний, которыми обладают 95% ваших коллег, вам необходимо узнать, что на самом деле делает каждая строка кода.
  • Удалите все и создавайте с нуля, больше никаких общих копий - станьте хирургом и точно разработайте свое приложение, функция за функцией, строка за строкой.

Проведя несколько недель мучений из-за этого и понимания того, как все работает (т. е. срезания путей для выполнения задач), я чувствую себя комфортно, говоря: «Я могу писать код на этом языке!». Выпускник 2-го уровня - ›готов к реальной работе, но далек от продуктивного или эксперта. Обратите внимание на бинарный характер изучения языка:

Уровень 3. Понимание внутренностей. (требуется остаток жизни)

  • Следующий шаг займет вечность. Настоящее понимание лучших практик, идиом, философии дизайна компонентов и т. Д.
  • Все языки и ремесла требуют самоотверженности, чтобы изучать и овладевать. Хотя я знаю, как писать код на одном языке, адаптация к новому требует усилий. Не считайте само собой разумеющимся, что «программирование - это программирование». Детали убивают вас.

Если вы дойдете до этого уровня, вы начнете понимать то, чего не знаете - это классический парадокс кривой обучения, описанный EdWeek.org. Ощущение мастерства то вверх, то вниз (и, в конце концов, вверх). Если не считать непрофессиональных инженеров, мы должны стремиться хотя бы преодолеть первую ступеньку - и перейти на: уровень 3- › профессиональный . Поздравляю, теперь вы готовы (если вы хотите писать код весь день) .

Мое приложение Flutter: FooTime!

Наконец, история Flutter. Я последовал своему собственному совету, приведенному выше, в процессе обучения.

Начал с некоторых онлайн-видео и документов по флаттеру.

Используя приложение World Time от Net Ninja, я закодировал тень во время просмотра, затем разорвал его на части, добавил некоторые новые функции и окончательный продукт:

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

Последним шагом является сборка и публикация - для Android через Android Studio вы можете напрямую создать пакет и загрузить его в Google Play Store.

  • Чтобы стать издателем, в Google Play Store требуется единовременный регистрационный взнос в размере 25 долларов. Полная информация находится на обучающем сайте Flutter. После этого использовать Play site довольно просто (хотя в первый раз встретить все предварительные требования, такие как значки, изображения и т. Д., Несколько болезненно).

  • Для iOS: членство Apple для разработчиков составляет 99 долларов в год, и я был слишком дешев, поэтому отказался от iOS - извините перед миллионами моих потенциальных клиентов iPhone, которым отчаянно нужен FooTime!

Основные мысли о Flutter (в основном по сравнению с React, Python, Java)

  • Настройка очень проста - проще, чем virtualenv / pip, maven, npm и т. д.
  • Горячая перезагрузка - это круто (наравне с React). Я не большой поклонник Android Studio, но меня это уже не волнует ...
  • Пользовательский интерфейс по умолчанию выглядит великолепно - так же, как React with Material Design - и стиль легко настраивается (проще, чем темы React, но сомнительно в ремонтопригодности).
  • Быстрое обучение (по сравнению с React) - настройка, обратные вызовы, управление состоянием - все кажется более простым и интуитивно понятным из коробки.
  • Отличная документация по flutter + сильное сообщество по StackOverflow и GitHub (условно говоря).
  • Dart - это просто - кажется, он ближе всего к Javascript - очень легко понять его, если вы знаете Java, JS или Python.

Более подробная информация о плюсах (в основном о минусах):

  • Все-есть-виджет хорош, но дает множество слоев (по одному для каждой функции). Напоминает мне Декоратор GOF Pattern.
  • Наслоение адом реально - совпадение фигурных скобок ([({};)]); иногда раздражает даже с автозаполнением помощи IDE.
  • Тонны встроенных функций - такие базовые вещи, как перелистывание страниц и сохранение настроек, были очень простыми (в данном случае PageView и SharedPreferences).
  • Поддержка библиотек все еще растет. это с нуля в React).
  • Отсутствует система сборки CI / CD - она ​​имеет как минимум интегрированное тестирование.
  • Платформа - движущаяся цель. Поскольку она новая и быстро меняется, ждите, что с обновлениями все выйдет из строя!

Почему все это было ценно

И наконец, почему старшие менеджеры, такие как я, пожилые люди, непрограммисты (DevOps, QA, PM и т. Д.), Должны получить доступ к этим материалам. Почему ? Возвращается к эмпатии - чтобы понять, что такое инженерия. Примечательно:

  1. Оцените легкость и удовольствие от начала работы (первые 80%)
  2. Признать сложность завершения (последние 20%)
  3. Осознайте, насколько ценно иметь в вашей команде гуру для решения всех сложных проблем, на которые у вас уйдут месяцы .. [12]
  4. Продолжайте учиться и расти - цельтесь высоко!

Спасибо за чтение.

Цитированные и вдохновляющие ссылки

[1] Технологии против нетехнического менеджмента - https://insights.dice.com/2017/04/14/non-tech-manager-oversee-tech-pros/

[2] Оппенгеймер и Манхэттенский проект - http://wavefunction.fieldofscience.com/2016/06/lessons-on-management-styles-from.html

[3] Официальный отчет о челноке - https://history.nasa.gov/rogersrep/v1ch5.htm

[4] 737-Max - https: // www. nytimes .com / 2019/10/02 / business / boeing-737-max-crashes.html

[5] мыслей о книге Перкина об обучении сверху вниз - https://www.gse.harvard.edu/news/uk/09/01/education-bat-seven-principles-educators

[6] Почему активное обучение является ключевым - https://www.educationcorner.com/the-learning-pyramid.html

[7] отличное объяснение того, почему методы Перкина работают лучше для большинства - https://www.fast.ai/2016/10/08/teaching-philosophy/

[8] Правило 80/20 (Парето) применимо к программному обеспечению - https://dzone.com/articles/applying-8020-rule-software

[9] курс обучения технологиям - http://blogs.edweek.org/edweek/learning_deeply/2015/04/the_paradox_of_deeper_learning_the_unlearning_curve.html

[10] Мысли Сатья об эмпатии - https://knowledge.wharton.upenn.edu/article/microsofts-ceo-on-how-empathy-sparks-innovation/

[11] Краткое руководство по Flutter + - https://medium.com/swlh/why-busshops-should-start-focusing-on-googles-flutter-and-fuchsia-48e16820f2a9

[12] По-прежнему обсуждаются различия в производительности программистов (10-кратный программист) - https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin -of-10x /

[13] менеджмент в эпоху схваток - https://www.infoq.com/articles/scrum-management-deemer/

[14] популярные размышления о том, как (плохой) PowerPoint потопил шаттл - https://mcdreeamiemusings.com/blog/2019/4/13/gsux1h6bnt8lqjd7w2t2mtvfg81uhx