Чтобы изучить новую технологию достаточно месяца. На этом можно было бы закончить эту статью, толком не начав ее. Однако я продолжу и расскажу вам, как пришла к такому выводу, что можно сделать, чтобы ускорить процесс обучения, а также перечислю основные проблемы изучения новых технологий и, самое главное, способы их решения.
Для начала отмечу, что названный срок в месяц — это большое допущение и приблизительная оценка. Все зависит от вашего начального уровня и сложности той технологии, которой вы решили овладеть. Кому-то достаточно посмотреть исходники в библиотеке, а кому-то необходимо кропотливо разбираться во всех нюансах. И все равно я уверена, что много времени вам не потребуется.
Первое, что может радикально сократить траты времени на обучение — это вопрос «А нужно ли вообще изучать именно эту технологию?». Тут все относительно. Ведь можно писать на jQuery, и никто вам ничего не скажет. В конце концов, освоить абсолютно всё невозможно физически. И все же слишком часто отвечать «Нет» я бы не советовала. Этот вопрос мы должны задавать себе не для того, чтобы оправдать свою лень, а просто для более рационального распределения собственных ресурсов и выбора наиболее актуальных задач. Обучаться и таким образом повышать собственную конкурентоспособность просто необходимо. То, как быстро вы обучаетесь, показывает, как быстро вы сможете выйти на рынок и создать новый продукт, который сможет конкурировать с другими компаниями. Этот факт понятен интуитивно, но мы должны просто-таки вбить его в свои головы и двигаться вперед.
99 problems
Итак, будем считать, что мы уже мотивированы и горим желанием научиться чему-то новому. И тут начинаются проблемы… Первая и главная — это риски использования новой технологии. Эти риски делят между собой как разработчики, так и заказчики. Одна из причин понятна: технология может быть сырой, а еще она может не «выстрелить», и ее не будут поддерживать в будущем. И это еще не все. Для поддержки продукта на новой технологии в штате заказчика может просто не оказаться нужного специалиста. Или разработчик может уйти из компании и оставить свое творение без поддержки, так как кроме него больше никто не знает, как это делать. Хороший пример подобной проблемы — новый язык программирования Elm. Его мало кто знает и использует, поскольку он достаточно сырой.
Тем не менее, у проблемы риска есть решение. Просто перед началом изучения вам надо проанализировать ситуацию: посмотреть на востребованность технологии на рынке, а также узнать, кто является ее контрибьютером и каковы их планы по поддержке. Это несложный шаг, который избавит вас от необходимости хвататься за все подряд.
Еще одна проблема — совместимость. Некоторым продуктам необходимо использование новых технологий, но нельзя просто взять и перейти, например, на React. Ведь он требует еще и модульную сборку, вебпак и много всего прочего. Поэтому, если перед вами стоит подобная задача, самое время задуматься, стоит ли браться за то, что потребует так много сил на достижение совместимости. Решить эту дилемму просто — надо присмотреться к аналогам. Очень часто выпускаются новые однотипные технологии, некоторые из которых вполне могут оказаться совместимыми с тем, что вы уже используете. Если продолжить приведенный выше пример, возможно, вам нужен не React, а просто шаблонизатор.
Еще один часто встречающийся «подводный камень» — отсутствие необходимой сопроводительной информации. Книг по технологиям, которые вышли всего неделю назад, не бывает. Книги просто не печатаются так быстро. Даже электронные. Кроме того, часто нам не хватает русскоязычной литературы, а иногда документация либо плохо переведена, либо просто некачественна. С такой бедой, я уверена, сталкивались очень многие.
Решений тут может быть несколько. Первое — социальные сети. Мы все в них присутствуем, как и (сюрприз!) разработчики той технологии, которая так вам необходима. Свяжитесь с ними или найдите нужное сообщество и узнайте все, что требуется. Второй путь — блоги, в том числе и видео. Большинство разработчиков (опять сюрприз!) ведут их и выкладывают обзоры и советы по освоению своих творений. Третий совет — давайте обратную связь. Если вы нашли ошибку, напишите об этом. Если вам досталась некачественная документация — не молчите. И наоборот, если какой-то блог помог вам разобраться в проблеме, оставьте отзыв и похвалите автора. Ну и, наконец, есть абсолютное оружие — знание английского. Если вы освоите язык на достаточном уровне, чтобы понимать оригинальные тексты хотя бы со словарем, вы просто забудете про нехватку информации.
Финальная проблема, о которой пойдет речь — отсутствие опыта. К сожалению, никто не рождается, умея сразу все. А те, кто умеет, не часто обрывают вам телефон, чтобы поделиться информацией. Поэтому отсутствие опыта, а также видеокурсов и туториалов серьезно увеличивает срок разработки. Например, когда я работала в компании 2ГИС, был выпущен продукт под названием «Сквер». Это платформа для вопросов о городах, а при ее разработке была установлена очень высокая планка и применено много новых технологий, что, конечно же, отразилось на сроках. Так бывает всегда: делать что-то новое в первый раз всегда сложнее всего.
Решение, которое я предлагаю, называется Github Search. С помощью него вы можете быстро найти готовые примеры использования технологии, которая вас интересует, причем часто прямо от самих авторов. Еще один необходимый сервис — Stack Overflow. Там есть разработчики, которые всегда готовы ответить на ваши вопросы. А может быть, ваш вопрос уже кто-то задал, и вам нужно просто прочитать готовый ответ.
Еще один важный совет напоследок — не бойтесь покидать зону комфорта. Запишите видеоурок или выступите перед публикой на митапе, сделайте то, чего раньше не делали. Таким образом вы не только поделитесь своим опытом с другими, но и сами узнаете много нового. Почему это важно? Да потому, что это ваш личностный рост. Ходите на мероприятия, знакомьтесь и общайтесь с интересными вам людьми, рассказывайте о своих проектах — это даст вам такой фидбек, что вам захочется делать еще и еще.
Кстати, чтобы подтвердить верность собственных мыслей по всем вышеописанным поводам, я провела специальное исследование и опросила около 200 разработчиков, как только начинающих, так и уже работающих профессионалов. Вопрос был один для всех, и он вынесен в заголовок этой статьи. Результаты оказались следующими: больше полугода с новыми технологиями разбирались 9,7% опрошенных. Их противоположностей, которым хватило всего недели, оказалось 18,3%. 23,7% участников анкетирования потратили от одного до трех месяцев, но больше всего, 48,3% разработчиков, ответили, что на изучение новой технологии им необходим именно месяц или чуть меньше.
Шаги и среда
На базе этого исследования я подготовила тактику, которая поможет вам справляться с обучением быстрее. Она состоит из двух компонентов — это шаги и среда. Шагов всего три. Первый из них — «Пойми!». Поймите, что это за технология, как она преобразует данные, как именно она помогает добиться результата, каковы ее составные части и как они взаимодействуют между собой. Смотрите примеры на Github, читайте ReadMe и ищите тематические посты на Хабре. Ничего нового, но многие почему-то пропускают этот шаг и сразу бросаются в бой.
Второй шаг называется «Закрепи!». После того, как вы поняли, что это за технология и зачем она вам нужна, переходите к практике. Так вы быстрее обнаружите собственные пробелы в теории и ликвидируете их. Главное — будьте внимательны и не допускайте опечаток. Теорию же можно найти и на Stack Overflow, и на «Тостере», и в книгах издательств GitBook и O’Reilly. Смотрите уроки на Level up! или русскоязычном Loftblog, где я когда-то преподавала. В конце концов, просто найдите себе наставника. Это может быть ваш коллега, наставник на курсах, личный ментор или даже сосед по парте — кто угодно, кто опытнее вас.
После этого сделайте третий шаг — «Обсуди!». Офлайн или онлайн — неважно. Главное, чтобы вы получили шанс обменяться опытом.
К разделу среды я отнесла два фактора — это «Выживание» и «Время». «Выживание» отвечает за реальную необходимость изучения той или иной технологии. Наш мозг очень ленив, он не желает трудиться ради цели, важность которой не доказана, и всегда будет подсовывать вам много таких наиважнейших дел, как позвонить бабушке, полить цветы, покормить кота. А вот если он будет точно знать, что без JS вы не выживете, не найдете работу и не прокормите семью, вот тогда вас самих удивит скорость обучения. В некоторых случаях мозг можно стимулировать самомотивацией: пролистайте список вакансий и помечтайте о большой зарплате, посмотрите на чужие качественные продукты, чтобы захотеть самому сделать такой же.
Со «Временем» все проще, но это кажущаяся простота. Мы думаем, что если будем тратить как можно больше времени на обучение, то быстрее получим результат. Вообще-то, все не так. Время должно быть организовано. Нельзя нарушать режим сна, питания, отдыха. Только так вы достигните максимальной продуктивности. Двух-четырех часов в будний день и в течение одного или двух выходных в неделю достаточно для обучения. Если вы не будете отдыхать, то перестанете получать удовольствие от процесса освоения новой технологии. Есть много тактик общения со временем. Моя любимая называется Pomodoro и она заключается в том, чтобы разбивать время на блоки по 30 минут. 25 из них надо тратить на дело, а 5 — на отдых.
Заключение
Если подвести некий итог, то он будет звучать так — все просто, нет такой технологии, которую вы не смогли бы освоить в разумных временных рамках. Не забывайте доказать себе критичность выживания при помощи объекта изучения и правильно организовывать свое время, а потом делайте необходимые три шага, и тогда все получится! Удачи!
Комментарии (40)
jbubsk
26.12.2016 21:29+1Если изучить — это прочитать книгу, все понять, и даже сделать несколько задач из книги, то да, хватит месяца. А вот уметь применить в правильном месте — вряд ли. Нужен опыт работы с той или иной технологией, ну, хотя бы 3-4 месяца.
mx2000
26.12.2016 21:46+4В 1992-93 году мне в руки попалась брошурка за авторством (очевидно, это псевдоним) «Слава Чип», в которой было довольно много полезностей по Turbo Pascal 5.5 и общей алгоритмике. Так вот, автор брошурки утверждал, что минимальный срок освоения незнакомой технологии — 3 месяца ежедневной практики по 2-4 часа.
Потому что:
— нужно изучить документацию. Если это библиотека, скажем, в 1500 функций — только на чтение по диагонали у вас уйдет неделя и выше, в зависимости от качества документации.
— нужно полистать примеры кода и сырцы, если они доступны. Чтение библиотеки в 20к строчек — это месяц работы.
— нужна практика «на кошках», особенно если технология меняет привычные вам шаблоны. На примере того же Elm, я регулярно наблюдаю в slack-чате одни и те же вопросы: как отправить HTTP-запрос, как распарсить JSON. Как работают Subscriptions. И это всего лишь Elm — примитивный коцый язык, охаскеллированный бейсик для веба.
Если говорить про смену технологического стэка, например, перескакивая с JS на Python (или наоборот), то добавьте сюда время на изучение доступных конкурирующих между собой решений (фреймворки, библиотеки, better practices, инструменты для скаффолдинга, разработки, поддержки кода проекта) — это никак не меньше 3 месяцев, несмотря на обилие готовых ответов на SO.
Сколько времени у вас займет/заняло разобраться с borrowing & lifetimes в Rust? Сколько времени понадобится, чтобы начать уверенно писать на Factor?
По оценке рисков при выборе технологий тоже не всё так гладко: жил-был RethinkDB с коммерческой поддержкой, сильной командой и инвестициями в шестизначную сумму. Прошло 4 года — и, бульк, контора закрылась, проект фактически не разрабатывается, несмотря на то, что планы были ого-го.
ЗЫ. https://habrahabr.ru/post/277323/
AlexZaharow
26.12.2016 22:06+1Мне кажется, что больше нужно напирать не на технологии, а на интерфейсы. Интерфейсы стандартизируются, а технологии далеко не всегда. Поэтому нужно ставить вопрос не о том, сколько нужно изучать конкретную технологию, а взглянуть на интерфейсы, которые она поддерживает, чтобы понять, пригодится ли технология в принципе и какую часть от технологии стоит изучать. Технологии бывают очень заумные и не всегда все части технологии нужны. Очень хорошо, если технология поддаётся разделению на части, потому что конечный продукт это далеко не одна технология, а их сумма. Просто нужно стараться не сильно увеличивать сумму неиспользуемых частей в проекте.
Мой вывод такой — интерфейсы нужно учить всегда и в это нужно вкладываться и не жалеть времени, а технологии просто берутся и тратиться нужно в основном на изучение части, которая подходит к нужному интерфейсу.
P.S.
Технологии, конечно, нужно учить, но с оглядкой на то, как быстро она начнёт приносит профит в какой-то части разработки.Особенно интересно «проникаться» технологией, когда читаешь документацию и вдруг ловишь себя на мысли — «Вау, КРУТО! Я бы до этого не догадался» или «Да, я тоже так бы сделал». ))) Тогда и освоение идёт быстрее.
ProgrammerMicrosoft
26.12.2016 22:30-2Мне лично понравилась данная статья так как автор раскрывает истину об обучение как не крути у всех у нас с вами всего 24 часа в одном дне — единственное различие состоит в том, что кто-то использует отведённое время с максимальной пользой таким образом увеличивая качество и скорость обучения, а кому-то нужно больше года так как у данного человека либо время не организовано, либо в конце дня остаётся всего 30 минут
botnet
26.12.2016 22:35+3>А нужно ли вообще изучать именно эту технологию?
Возможно я уже старый, но в 90% случаев отвечаю «Нет, не нужно». А если книг нет, и тем более на русском, то для меня это некий фильтр, типа технология не прошла боевое крещение и померла не родившись.
*ушел пилить проект на jQuery и PHP"*3aicheg
27.12.2016 03:46+3Если программисту нужны книги, и тем более на русском, то он не прошёл боевое крещение и помер, не родившись.
maxpsyhos
27.12.2016 06:14Тут дело не в том, что программисту нужны эти книги. Дело в том, что если про какую-то технологию до сих пор не написано "#techname# for dunners" и с десяток разной паршивости учебников, то значит она либо появилась очень недавно либо не востребована на рынке.
Writerim
27.12.2016 06:50К сожалению не могу найти статью на хабре, где писали про то как развивается мир. Примерная суть — «Если человека из 2000 перенести в 2016, то он будет сильно удивлен. Если взять человека из 1984, то такого эффекта не будет. Надо брать из 1800 допустим.» и так все дальше и дальше в геометрической прогрессии (*-------------------*--------*---*-*). Так что если придерживаться этой диаграммы, то в будущем ни одна технология не будет жить до написания книги. Возможно мы уже в этой точке.
botnet
27.12.2016 22:22Могу порекомендовать книгу Капицы «Парадоксы роста», там он писал про скорость развития прогресса. Сейчас он 25 лет, и быстрее он не сможет бежать. 25 лет — это одно поколение.
el777
05.01.2017 17:39Проблема в том, что сможет. И даже в пределах поколения будет нелегко, надо будет гибко перестраиваться.
VolCh
27.12.2016 00:07+3А как же правило 10000 часов? Ну, пускай 5000, если есть знания в смежных областях, скажем знания плюсов при переходе на шарп.
Deosis
27.12.2016 07:04+2Тут может сработать и в обратную сторону. (Притча о полной чашке)
Знания из одного языка могут конфликтовать со знаниями из другого (например, когда в шарпе вызывается деструктор объекта?)
Хотя чем ближе языки, тем быстрее будет переход.
ПС. Опрос какой-то расплывчатый. Есть поговорка Easy to start, hard to master. К какой половине относится слово изучить?
Изучил ли я язык, если могу написать на нем ввод, сортировку и вывод чисел? (Если да, тогда любой язык после первого изучается за день)VolCh
27.12.2016 08:38+1Если это хотя бы третий схожий язык, то различия будут восприниматься не как когнитивный диссонанс, а как деталь реализации. Столкнувшись с отсутствием ожидаемого поведения лезешь не в отладчик с мыслями «какого черта оно не работает как надо», а в документацию/гугл с мыслями «что я упустил» :)
Согласен, да, я посчитал в смысле «master».
ProgrammerMicrosoft
27.12.2016 16:30-2
Внимательно просмотрите данный ролик а потом уже пишите про 10 000 часов
10 000 часов это миф
Психологи заново изучили данные шести предыдущих исследований шахматистов (больше тысячи участников) и восьми исследований музыкантов (628 человек) и обнаружили, что разные гроссмейстеры и разные музыканты высочайшего класса практиковались по-разному. Одному шахматисту потребовалось 26 лет, чтобы достичь уровня, которого другой добился за два года. То есть явно дело далеко не только в количестве «отработанных» часов. «Вполне очевидно, что некоторые люди достигают высшего мастерства без обширной практики, тогда как другие, даже прибегая к ней, мастерства не добиваются». Андерс Эриксон, чье исследование 1993 года цитировал Гладуэлл, не согласился с этими выводами, утверждая, что его критики исследовали слишком много начинающих игроков. В то же время Эриксон, как и другие исследователи, подверг сомнению и ряд деталей самой теории Гладуэлла (да и вообще его книги немало критиковались за неточности).
nApoBo3
27.12.2016 00:44+1Имхо конечно, но изучить технологию и начать более менее успешно её использовать очень разные вещи. Для использования при прочном общем базисе и опыте в смежных технологиях ( скажем перейти с c# на java) нужно 1-3 месяца. Но для изучения нужно набить шишек и походить по граблям, а для этого часто и года мало. Без это будут сходит со стапилей велосипеды на костылях.
movl
27.12.2016 02:02+8Меня немного передернуло от фразы в самом начале статьи: "… этот факт понятен интуитивно, но мы должны просто-таки вбить его в свои головы и двигаться вперед". На первом собрании в университете, еще до начала учебы, заведующий кафедры нам сказал примерно такое: "Мы будем вас учить умению самостоятельно добывать знания и научим думать. Поэтому у вас будет математика, физика, множество различных теорий, история этих теорий, гуманитарные науки и все, все, все. А если вам нужны JavaScript+HTML+CSS+PHP, то в ПТУ скорей всего лучше этому научат.".
Мне показалось, что автор предлагает прижать задницу и зазубрить, грубо говоря, технологию за месяц. Выучить все ключевые слова из языка программирования, выучить все методы в библиотеке, выучить все шаблоны проектирования и так далее. В этом, конечно, ничего плохого нет, теорию надо знать, но добавит ли это какой-то конкурентоспособности большой вопрос (отсылка к статьям про собеседования). Лично для меня, понимание каких-то базовых вещей чаще помогает решать проблемы, чем знание чего-то конкретного в конкретных технологиях, и из базовых вещей я имею ввиду: алгебру, матан, теорию множеств, теорию графов, теорию алгоритмов и многое другое.
Допустим не нужно знать ни одного метода из связки React+Redux, чтобы понимать принципы работы этой связки, и кому-то будет достаточно схемы с потоком данных и списка методов, чтобы начать работать с этими библиотеками. Тоже касается и других технологий, возьмем что-нибудь по сложнее, допустим OpenGL, можно месяц читать обучающие материалы, но так и не осознавать до конца, за счет каких вычислений вращается треугольник в примере: какие-то матрицы, вектора, проекции, формулы, полигоны —, а можно знать аналитическую геометрию и линейную алгебру и достаточно быстро в этом всем разобраться. Или, чтобы далеко не ходить, CUDA, тут уже нужно знать почему и как алгоритмы можно распараллеливать, и еще было бы не плохо представлять как биты пересылаются на железном уровне. Вот пара технологий, которые без большой теоретической базы, как-то не особо получится освоить за месяц, не говоря уже про большое множество других. Знания должны быть в первую очередь в областях, а не в конкретных технологиях. Конечно, и в конкретных технологиях всегда есть множество моментов, которые ты просто не узнаешь без изучения, но посыл в том индуктивное мышление всегда создает больше вопросов, чем ответов.
Еще немного проясню свою точку зрения. Вот конкретно в статье, автор предлагает отфильтровать технологии для изучения, на основе востребованности, известности авторов, публикаций в блогах, и, по моему мнению, это не осознаное решение, а поедание маркетингового говна. Но мои мысли сейчас даже немного про другое. Понятно, что программирование уже очень далеко от науки. Но вот с точки зрения ведения просветительской деятельности, зачем призывать людей еще больше удаляться? Нужно не технологии изучать, а то какие проблемы эти технологии решают и как, чем были вызваны проблемы, что решение таким способом даст, какие еще способы есть, а какие истоки у тех способов и так далее, это касательно конкретных вещей, а в целом нужно призывать всех максимально расширять свой кругозор и думать. А не учить на какой стул сесть, потому что это интуитивно понятно. Мы так дальше споров, о том какой js-фреймворк быстрее, какая методология/парадигма/технология/бд/яп/<подставь_свое> лучше, мы не уйдем. Накипело немного и идеалист во мне проснулся, но все равно чуть большего мнения о Mail.ru был до этого момента.
Writerim
27.12.2016 06:42+1Заметил за собой, что самые сложные 2 этапа — начать и знать тонкости.
Начать сложнее всего, потому что надо понять философию того с чем хочешь работать, как это устроено и т.д.
Первое приложение мне далось очень не просто. Затем приходит полное понимание и ты шпаришь по документации уже более менее интуитивно. Знаешь что искать и где искать. Некоторые моменты можно попробовать написать на «горячую» и есть шанс, что все будет работать.
Второй сложный момент — углубленное знание. Мало документации, специфические решения.
hlogeon
27.12.2016 12:49+7Когда ставишь вопросы наподобие: «Сколько уйдет на изучение технологии N», неплохо было бы держать во внимании уже имеющуюся базу. Я не думаю, что кто-то без серьезной подготовки в области физики и астрономии можно быстро освоить какую-нибудь новую технологию поиска отдаленных, мелких небесных тел. Тоже справедливо и для программирования. Без БАЗОВЫХ знаний программирования, осваивать новые технологии нет большого смысла. Обладая сильной базой, тебе намного проще изучать «новые» технологии, которые, на самом деле, в большинстве своем реализуют старые, давно известные принципы. Помню, когда обычный паттерн Observer, известный с незапамятных времен в мире фронтенда произвел вау-эффект и все заговорили о 2-way data binding.
Потом: под освоением все понимают совершенно разные вещи. Я программирую на PHP больше 7 лет, но не могу сказать, что я его освоил. Значит ли это, что у меня какие-то проблемы? Отнюдь. Просто всегда есть куда расти и углубляться. Другая сторона медали, что по долгу службы мне иногда приходится писать фронтенд, в том числе и на хипстерских реактах с редуксами и прочих ангулярах.
Объективно, мой уровень во фронтенд-разработки несколько выше, чем у большинства middle-фронтендщиков, с которыми мне приходилось пересекаться. Причина тому — более сильная БАЗА. Абстрактное мышление, умение гуглить, хорошее знание и понимание паттернов, как всем известных, так и более специфических, постоянное изучение трендов и исходников на гитхаб. В то время, как многие фронтенд-разработчики не могут даже разобраться как работает event-loop в JS, они считают что «освоили JS». Хотя вопрос цикла обработки событий — один из ключевых в JavaScript.
Так вот, что бы вкатиться в ангуляр и сделать на нем простенькое SPA для бронирования билетов на концерт и последующей их верификации мне потребовался день. Значит ли это, что я освоил Angular за день? Ну конечно же нет, потому что мне не пришлось использовать и 10% возможностей и инструментов фреймворка.
В общем: научиться варить пельмени != научиться готовить. Если говорить об освоении новой технологии, как о пельменях, то месяца — очень много, если есть база(умеешь включать плиту, кипятить воду, наливать ее в кастрюлю и т.д). Если базы нет — то это время может ОЧЕНЬ сильно возрасти. Непредсказуемо сильно, если говорить об абстрактных знаниях или навыках. Человеку без математической подготовки и определенного склада ума будет почти невозможно без базы начать писать код на Erlang, например. А подготовка базы может легко занять и целый год.
Если говорить, как о более общем навыке«готовка», то это бесконечный цикл, ибо даже самый хороший повар постоянно совершенствует свое мастерство.
dmrt
27.12.2016 16:25+2Больше всего интересует откуда вы берете типы задач для освоения технологий?
Все время какую-то одну всеоблемлющую, класическую или придумаваете каждый раз новую или в голове и так накопилось полно задач интересных?
Должен же быть еще какой-то результат помимо освоения новой технологии?
aGFicmFoYWJy
28.12.2016 22:38От меньше пяти минут до "жизни не хватит", и зависит от количества информации которую нужно усвоить (и от того кто будет её усваивать), чтобы технология считалась изученной.
vigo2
28.12.2016 22:38-1Сколько нужно времени для обнаружения подозрительной активности на своих компьютерах и предложения установить бесплатный антивирус Cezurity?
masai
Извините, не могу удержаться.
masai
А если по существу, то советы очень хорошие, но заголовок в самом деле смущает. Серьезную технологию выучить полноценно, чтоб стать в ней специалистом, вряд ли возможно. Но и сидеть сложа руки, конечно, тоже не стоит. По этому поводу есть замечательная статья Норвига «Научитесь программировать за десять лет», которую, как и предыдущий комикс, уже, наверное, все видели.
6thSence
Спасибо за отзыв)
6thSence
ахаха в тему )
nrcpp
Мне тоже, первое в голову что пришло — это плюсы. Учил я их до коммерческого применения года 3. Писав свой С++ компилятор попутно.
masai
Писать компилятор, чтобы выучить язык — это круто! :)
nrcpp
Это перфекционизм к тому же :) Тут лежит до сих пор.