Чему меня научил обмен знаниями

Если вы не потратили пару десятилетий на кодирование, вы можете не вспомнить те дни, когда некоторые из наиболее важных сведений о фреймворках, API и даже языках программирования были столь же скудными, как точки с запятой в файле .py. . Но было время, когда информация о программировании была настолько ценной, что потрепанные книги (например, Программирование Windows Петцольда) передавались по офису из кабинета в кабинет. Иногда они пропадали.

Книги были особенно ценным источником информации о новых технологиях. В 2001 году, за год до того, как я написал свою первую книгу, одной из самых популярных компьютерных книг было подробное руководство по бета-версии нового фреймворка. (Это был ASP.NET 1.0, в то время еще называвшийся ASP +.) Вот насколько ценной может быть инсайдерская информация. Компании-разработчики программного обеспечения признали, что книги и журналы являются бесценным проводником для их аудитории разработчиков - факт, который я осознал, когда посетил кампус Microsoft во время их саммита партнеров по издательству книг, закрытого собрания с менеджерами по маркетингу и разработчиками, которое было гораздо более информативным, чем гораздо более крупный MVP. конференция в следующем году.

С тех пор мир прошел долгий путь. Сегодня больше нет Publishing Summit, и информация о программировании, доступная в Интернете - от бесплатных книг до игровых площадок, видеокурсов и даже болтливых Twitch-стримов - просто невероятна. Для начинающих программистов барьеры для входа рухнули, и нет перспективы, где это плохо.

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

1. Хорошие учителя узнают больше, чем хорошие ученики

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

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

  • Чтобы научить чему-то должным образом - уметь отвечать на каждый вопрос и контекстуализировать каждую дизайнерскую практику - вам необходимо полностью это понять. Я изучал технологии, о которых писал, гораздо больше, чем те, которые использовал только для написания кода приложения.
  • Формализация своего мнения заставляет его прояснить. По мере того, как мы становимся опытными программистами, мы начинаем понимать, где кроются опасности и где есть определенные предостережения. Вы оттачиваете ценный инстинкт. Но пока вас не попросят объяснить свое мнение, вы не проверили свои предположения.
  • Вы можете многому научиться у новых людей, пытающихся решить старую проблему. Да, я часами уточнял объяснения и демонстрации наиболее часто задаваемых вопросов. Через некоторое время вы можете их предвидеть. Но даже начинающий программист может задать вопрос, который побудит вас глубже задуматься о том, о чем вы всегда проносились.

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

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

2. Истории определяют наш код

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

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

Вот пример. Как новичок в JavaScript, вы лучше поймете ограничения клиентского программирования, если узнаете, как браузеры и веб-серверы обмениваются сообщениями. Без этой точки зрения все _1 _ / _ 2 _ / _ 3_ учебные пособия в мире не дадут вам необходимой информации. Как эксперт по JavaScript, вы лучше поймете роль WebAssembly, если проследите историю транспиляции и ранние эксперименты с asm.js. И так далее, от потоковой обработки до облачных вычислений и искусственного интеллекта. В большинстве случаев знать как что-то делать легко. Искусство программирования решает, когда вам следует.

Хорошие истории полезны, но плохие - не безразличны. Они активно вредны. Плохие ментальные модели скрывают реальность или поощряют рискованные привычки. ASP.NET Web Forms, огромная популярная технология, засохла, потому что ее история (представление серверной веб-страницы как настольное приложение с отслеживанием состояния) не выдержала критики.

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

  • Пример Code-It-All-Yourself. Здесь вы узнаете о новом API, увидев технически впечатляющий, но крайне непрактичный пример. Часто это связано с изобретением велосипеда - например, с созданием версии чего-то, что уже есть в вашей библиотеке классов. Самостоятельное шифрование - типичный (и очень распространенный) плохой пример.

  • Урок рисования по номерам. Сделайте это. Сделай это. Тогда сделай это. В эту обучающую ловушку легко попасть, потому что новичкам нужно держаться за руки. Но изучение рецепта всегда бледнеет по сравнению с обучением тому, как готовить, и вы не сможете стать эффективным разработчиком, пока не поймете возможности и ограничения ингредиентов, которые у вас под рукой.
  • Величайшая новая технология на свете. Это история, которую многие маркетинговые отделы прививают продукту после того, как он готов. Проблема в том, что эта история скрывает правду о том, какое место технология занимает в экосистеме разработчика. Чтобы понять это, вам нужно знать его активы и его болевые точки. На быстро желтеющих страницах написанных мною книг больше всего я горжусь тем, что уводил читателей от пустых обещаний или технологий, которые имели очевидные недостатки.

Выявление недостатка всегда полезнее, чем объяснение функции.

3. Принятие превосходит техническое совершенство

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

Большинство моих книг посвящено стеку программирования Microsoft, и Microsoft отказалась от множества старых технологий. Некоторые из них были плохими (например, SharePoint Access Services), но большинство просто шло неверным путем против более широкой эволюции современной разработки (скажем, WPF). Вы, вероятно, никогда не слышали о давно заброшенном наборе Intel P2P, но я слышал. Несколько лет назад я написал книгу о программировании в одноранговой сети и был слишком оптимистичен в отношении того, что комплект Intel P2P превратится в надежный инструмент, который разработчики .NET могут использовать для обхода межсетевых экранов. Вместо этого это была удачная проверка концепции, которая вскоре бесследно затонула.

Другие примеры включают наборы инструментов с открытым исходным кодом, которые просто не имели достаточной поддержки сообщества, чтобы поддерживать их работу, или скрывали более глубокие проблемы, такие как ASP.NET AJAX Control Toolkit и WPF Community Toolkit. Последней технологией, которая присоединилась к этой забытой семье, является некогда популярная Visual Basic, актуальность которой снижается, поскольку она теряет свое место в мире .NET. (Нет ничего плохого в написании приложения VB сегодня, но зачем вам это? У вас есть лучшая инструментальная поддержка, лучшая документация и больший кадровый резерв, из которого можно нанять, если вы придерживаетесь C #.)

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

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

4. Делать ставку на самого себя никогда не неправильно.

Скорее всего, большинство людей, читающих эту статью, не мечтают опубликовать 1000-страничный справочник по программированию в твердом переплете (в цвете!). Но есть вероятность, что у вас есть собственный увлекательный проект или идея нестандартного пути, и велика вероятность, что вы позволите ей исчезнуть. Самая сложная задача, с которой я когда-либо сталкивался, - это не поиск новых инструментов или решение таинственных сбоев в пре-альфа-сборках новых фреймворков без документации. Самой сложной задачей было заниматься интересными проектами, даже когда я не знал, кто будет их использовать и какую форму примет конечный результат. В конце концов, самыми успешными моими книгами часто были гадкие утята - темы, которые я преследовал по прихоти, потому что считал их интересными, полезными или забавными. Обычно я ожидал, что они проиграют.

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

Хотя мир технических изданий никогда не будет прежним, я все же время от времени пишу гораздо менее прибыльные книги. Прямо сейчас я работаю над необычным бесплатным руководством для детей, изучающих JavaScript. Чтобы получить копию, когда она выйдет, подпишитесь на информационный бюллетень Young Coder.