Как выживать в изменяющемся мире разработки  



Как выживать в изменяющемся мире разработки +16

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


Взять к примеру, мир фронтенда. Со знанием JavaScript пятилетней давности сейчас хорошую работу не найдешь. Сейчас RequireJS + Grunt не прокатят, надо знать React, Webpack, современный ES или TypeScript и т.д. Причем в следующем году многое уже снова устареет.


При этом не всегда на работе можно получить новые знания, потому что зачастую там тонны легаси (если долго пилится какой-то продукт — это неизбежно), которые никто переписывать "по модному" не даст.


Что же делать? Делать pet projects по ночам? Или пытаться сменить направление развития на более стабильное во времени?


Особенно часто этот вопрос встает у программистов с детьми. Как оставаться актуальным на рынке в долгой перспективе, не тратя на это всё личное время?


Уйти в руководство


Преимущества:


  1. Иногда достаточно знать технологии по верхам (это зависит от вида руководства, team lead, tech lead, CTO и т.д. — совершенно разные обязанности)
  2. Можно выбирать технологический стек самому.

Недостатки


  1. Не знать детали технологий пожалуй можно лишь менеджменту верхних уровней. Простой тимлид должен всё знать, никуда не денешься. Tech lead должен знать лучше всех.
  2. Эта работа многим не по нутру. Управление людьми — это совершенно отдельная профессия, не имеющая ничего общего с программированием. Многие туда стремятся, но, едва попробовав, с радостью возвращаются обратно к коду.
    Если одним из поощряемых качеств простого программиста является суперконцентрация на сложной задаче, то здесь наоборот: зачастую жонглируешь задачами, толком не вникая в реализацию (просто нет на это времени).
  3. Даже если ты выбираешь стек сам, то ты не будешь делать радикальных изменений в проекте (переписать с PHP на Rust), потому что для этого всё так же не будет ресурсов. Когда ты отвечаешь за всю "техничку", то понимаешь это как никогда.

Уйти в суперстабильные или зарегулированные компании


Говорят, до сих пор где-то в банках и нефтянке пилят на Java 7 и горя не знают. И такой работы там еще на 100 лет.


Недостатки тоже очевидны: скукота, бюрократия. Ну и если вдруг стабильная компания внезапно умирает, а так тоже бывает, то на рынке труда с java 7 будет сложновато.


Полумёртвые языки


Ходят легенды о программистах на COBOL и их нечеловеческих зарплатах. Вполне верю: спрос хоть и маленький, но предложения вообще нет. Никто не пойдет учить cobol.


Недостатки: древние языки ужасны, и инструменты для них ужасны. Перспективы не ясны, вполне возможно язык доумирает до конца.


Развивать ядро базы данных или линукса


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


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


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


Изменение мышления работодателя


Это из серии несбыточных мечт, но всё же.


Если человек знает три языка и две базы, сколько ему нужно времени, чтобы начать писать на четвертом подобном? Очень мало. Тем не менее в вакансиях как мантру пишут что-нибудь такое: "опыт работы на java от трех лет". Я предлагаю работодателям писать так: "опыт работы на java от трех лет или выполнение тестового задания". Вам ведь ехать, а не шашечки.


Подкину немного на вентилятор: php-шник с десятилетним опытом, который хорошо знает ООП и, допустим, писал на typescript, запросто пересядет на java. Там даже ключевые слова одинаковые: class, interface, extends, implements и т.д. Принципы SOLID ровно те же.


И возможно через 2-3 месяца будет писать не хуже, чем 3-летний труъ джавист. Потому что уже умеешь писать сложные SQL-запросы, знаешь стандарт HTTP, умеешь верстку и JavaScript и прочее. Конечно, там есть 100500 нюансов, многопоточность и т.д., но если ты за 10 лет привык решать проблемы, то разберешься уже с чем угодно, дайте только мануал полистать.


На первых порах кто-то должен бить по рукам, но это всё равно не сравнимо с полным новичком в профессии.


Смена деятельности


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


Можно начать своё дело и делать вообще что угодно. Правда и риск максимальный: 9 из 10 таких начинаний обычно прогорают. Ну и саморазвитие здесь обычно также в приоритете )


Постоянная смена работы


Если менять работу раз в год-два, то точно будешь востребован на рынке. На одной работе изучил React, на другой Postgres и т.д. Однако недостатков тут тоже много. Карьеру построить сложнее; всё время надо притираться к новой команде и начальству; придется объяснять на собеседованиях, почему ты такой "летун"


Путь компромисса


Если мы не можем решить проблему, то можно её ослабить. Например, хотя бы какую-то часть кода продукта осовременить и т.д., ведь иногда можно найти выгодные для бизнеса изменения. Ну и по мелочам тоже: переехать с Grunt+RequireJS на Webpack+ES Imports — дело одного дня, а дальше уже можно спокойно использовать современный JavaScript.


Тайм-менежмент


Если изучать новое интересно, но нет времени, то зачастую можно что-нибудь придумать. Я, к примеру, стараюсь ездить до Питера на электричке (живу рядом с Павловском). Это около 40 минут времени туда и столько же обратно. Вполне можно успеть сделать пару "помидорок" по интересной теме. Ну или просто почитать книжку. Сейчас, например, пишу эту статью )


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


Вместо вывода


Эта статья не попытка научить жить в стиле дурацких статей а-ля "7 способов разбогатеть, ничего не делая". Наоборот, я с удовольствием научился бы чему-нибудь полезному из комментариев. Так что welcome!

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (59):

  1. DrPass
    /#18769129 / +3

    Взять к примеру, мир фронтенда.

    Возьмите любой другой мир :) В остальных отраслях разработки всё намного стабильнее. Да и первичный суп из технологий во фронтэнде — тоже явление сугубо временное, через несколько лет стабилизируется, и начнёт укрупняться, как это ранее произошло в других сферах.

    • AbstractGaze
      /#18771647

      Про мир вы правильно написали, и даже не разработки. Возьмите типичного кассира или бухгалтера. На сколько изменились требования и навыки в их работе? Тот же кассир в наливайке раньше писал деньги на «листике» и все, теперь он дожен «чекать» егаис, уметь пользоваться например 1с (конкретный случай), сканировать и отправлять отчеты, и это человек который вообще даже мышкой пользоваться не умеет.
      Те же бухгалтера должны постоянно переходить на новые версии и типы софта, некоторые конечно упорно этому препятствуют и им все равно, что работа выполняется в разы медленней.

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

      • x-foby
        /#18771767

        Типичный кассир продолжает работать на том же калькулятора, только в профиль: добавили монитор, слегка расширили клавиатуру.
        Типичный бухгалтер знает несколько типичных (для своего софта) горячих клавиш и работает только с ними. И это, скорее, уникальный случай, когда сынок рассказал про Ctrl+C и Ctrl+V (но забыл/не знал про Ctrl+X).
        Поэтому нет, революций там не произошло никаких, тем паче не произошло никаких метаморфоз уровня того же JS)

        • cheshircat
          /#18771915

          Думаю тут стоит еще учесть уровень гибкости мышления. Мне кажется у того же кассира он менее гибкий чем у программиста. Соответственно добавление монитора, клавиатуры, 1С и т.п. вместо привычного калькулятора, наверное можно соотнести с переходом на новый фреймворк на программиста. Вроде бы тот же JS/PHP/Python/Ruby(подставить нужное), но другое :)

        • apxi
          /#18771917

          Ты просто не в теме.

  2. Ombre
    /#18769237 / +8

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

    • andreysmind
      /#18772701

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

  3. lingvo
    /#18769611 / +2

    Как вариант — уйти в серьезное эмбеддерство. Там все варятся уже не один десяток лет на C и C++ и не думают с них слезать и хорошего программиста со знанием С(++), да еще и какой-нибудь ОСРВ типа VxWorks, нужно хорошо поискать, а потом еще долго учить.

    • Dima_Sharihin
      /#18771801

      Я думаю это суть про пункт "ядро Линукса". Потому что от эмбеддера обычно требуют умение обращаться с паяльником, осциллоскопом и базовое понимание электроники (рассчет резисторных делителей, фильтров и так далее).


      А программировать мб нужно даже не каждый день)

      • lingvo
        /#18772411

        Это только в маленьких конторах, где один-два разраба. Там эмбеддер обычно и за ай-тишника выступает. В бoльших начиная от 2-3 разработчиков уже обычно вводится четкое разделение труда.

  4. zigzag8312
    /#18769721

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

    • Suvitruf
      /#18770169

      Да почти про любую технологию тоже самое можно сказать. Про ту же Java.

  5. Suvitruf
    /#18770173 / +2

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

    • varanio
      /#18771971

      Поясню. Когда-то давным давно, когда jquery только стал популярным, я менял работу. И с удивлением обнаружил, что все, кроме меня знают jquery. Работу я, правда, нашел и очень быстро, но со знанием jquery я мог бы претендовать на лучшую зп и тд.
      Сейчас история такая же: во фронтенде надо знать react или vue или angular. Можно наверно и без этого обойтись, но просто условия будут хуже.

      • Suvitruf
        /#18774149

        Можете прояснить один момент? Вас не взяли, потому что вы не знали jquery, или вы решили, что вас не возьмут?

  6. Perlovich
    /#18770351 / +2

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


    Мне кажется, здесь вы преувеличиваете. Java 8 (которая сейчас LTS) не сильно отличается от Java 7. Streams API, Optional, лямбды — осиливаются за вечер-два. И вряд ли для потенциального работодателя отсутствие опыта работы с Java8+ будет принципиальным.

    Java фреймворки тоже не то, чтобы должны были сильно поменяться между Java 7 и 8.

    В общем, для Java разработчиков даже близко нет такой сильной проблемой с устареванием инструментов, как для JavaScript девелоперов.

    • varanio
      /#18771993

      Сравните: один программист пишет на jsp и java 7, javascript не знает. Другой умеет делать SPA на реакте через rest api, написанным на Spring, знает java 10.
      И вот оба оказались на рынке труда. Кого выберет работодатель? Чья з/п будет больше?

      • AGhostik
        /#18772635 / +3

        Тот кто лучше себя продаст?

      • maxzh83
        /#18772813

        Сравнение у вас не совсем корректное. В первом варианте человек не знает javaScript, во втором знает, да еще и реакт. Это опять же фронтенд, к джаве отношения не имеет. Если это отбросить, то остается jsp и java7 против Spring и java 10. Java 10 сейчас мало кто использует (потому что не LTS), т.е. фактически java 10 превращается в java 8. Spring это конечно аргумент, но ему уже очень много лет, т.е. нельзя сказать, что это что-то новое. Дальше я бы на месте работодателя смотрел на все остальное: опыт работы, проекты, работа с БД и т.д.

  7. suharik
    /#18770593 / +1

    Представляю себе то же самое на заводе. «Иван Иваныч, мы Вас взять на работу не можем. Вы всю жизнь ничего тяжелее 271-граммового молотка в руках не держали, а у нас в ходу только по 364 грамма, да скоро закупим по 380. Что ж так, не удосужились освоить?»

    • vlreshet
      /#18771857 / +1

      Тут, скорее, более верная аналогия будет такая: «Иван Иваныч, мы вас взять на работу не можем. Вы всю жизнь стамеской работали, а у нас в ходу токарные станки, а скоро закупим ЧПУ».

      • lingvo
        /#18772459

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

        • vlreshet
          /#18772495

          Ну, не совсем так. Таксистов и водителей в будущем смогут (наверное) заменить роботами полностью, независимо от уровня квалификации водителя. А программистам надо просто постоянно повышать их уровень, потому что более простые вещи сможет делать ИИ (опять таки — наверное)

        • Kanut79
          /#18772509

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

      • suharik
        /#18772955

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

  8. amaksr
    /#18770723 / +1

    90% программистов работают с существующим (по логике автора — устаревшим) софтом. Даже если пишут что-то с нуля, то разработка занимает месяцы, плюс потом годы на доработку и поддержку. Поэтому не настолько это уж и острая проблема.

  9. AlexMac
    /#18770819 / +4

    переехать с Grunt+RequireJS на Webpack+ES Imports — дело одного дня


    Посмешил. Простой апгрейд Webpack'a с одной версии на другую, не бывает без кучи ошибок и танцов сам знаешь с чем. А тут полная замена build системы за один день… Ну только если проект 'Hello world' какой-нибудь.

    • justboris
      /#18771497

      Это зависит от проекта.


      Если в нем используются только стандартные CommonJS/AMD модули и минимум плагинов, то переезжается легко.


      А если есть особые плагины, несовместимые с новыми версиями, то это боль. А еще хороший способ подумать, а точно ли нужно было ставить super-duper-loader, если потом из-за него сложно обновляться.

      • JustDont
        /#18771505

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

    • varanio
      /#18771997

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

  10. JustDont
    /#18771483 / +1

    Со знанием JavaScript пятилетней давности сейчас хорошую работу не найдешь.

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

    Так тоже не надо, на самом деле.

    • theuser
      /#18772561

      А есть еще фронтендщики, которые html/css не знают, но вроде как js знают при этом.

    • Eldhenn
      /#18776615

      Но с другой стороны, ошибки в компиляторе или ОС вы тоже не исправляете. Да и не сможете исправить.

      • DrPass
        /#18777333

        Вам не кажется, что знание JS в отношении фронтэндщика правильнее было бы сравнивать не со знанием внутреннего устройства компилятора для программиста, а со знанием языка программирования для программиста? ;)

  11. JustDont
    /#18771499

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

    Основа этого всего не меняется уже очень много лет — стэк из HTML+CSS+JS был и остаётся тем самым, что нужно всегда, везде, и не очень-то оно меняется. Дополнительные слои, навешиваемые сверху — новые языковые фичи (которые всего лишь «сахар»), типичная экосистема нынешних фронтэнд-проектов, модульность, транспайлеры, фреймворки, итд — это с одной стороны выглядит страшно, а с другой — всего лишь надстройка над базисом. Осваивается это за куда меньшие промежутки времени, чем базовые вещи.

    И просто так «чтоб было» за это всё даже и не стоит хвататься — в силу изменчивости мира фронтэнда это всё может спокойно успеть стать неактуальным еще до того, как где-либо вам понадобится. А вещей, за которыми действительно стоит всегда пристально следить — гораздо меньше: браузеры (никогда не стоит упускать из виду, как развивается то, на чем собственно вся ваша работа отображается, даже если разработка нынче идёт по пути browser-agnostic), да стандарты w3c.

    • varanio
      /#18772005

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

      • JustDont
        /#18772651

        Освоиться с промисами, с теорией и практикой — вопрос даже не одного дня, а нескольких часов. О чем и речь, мелкие надстройки — это не та штука, в которую нужно долго и последовательно вникать.

        • andreysmind
          /#18772765

          Освоился с промисами, приходишь на собеседование, а у них async\await.
          Освоился с async\await, подзабыл, за отсутствием практики, промисы, приходишь на собеседование, а у них… и так далее.

          • JustDont
            /#18772797

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

  12. Stas911
    /#18771667

    С чего это «год-два» уже стал «летуном»? На Западе это сейчас стандартное время работы на одном месте работы и вопросов вообще не вызывает. У миллениалов с этим и еще хуже, кстати.

    • varanio
      /#18772015

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

      • Stas911
        /#18774347

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

        • varanio
          /#18774387

          А толковый спец на 10 еще лучше

  13. DenBlack
    /#18772019

    Изменение мышления работодателя

    Это правда что-то из области фантастики. Да и мало кто будет из опытных предпринимателей менять работающую схему, особенно если компания какой нибудь 20ти летний мамонт. И вдогонку главное правило программиста: работает не трогай (:

  14. maxzh83
    /#18772021 / +1

    то на рынке труда с java 7 будет сложновато.

    Да нормально будет. Между java 7 и java 8 не такая большая пропасть. Можно же ведь
    мануал полистать

    А java 9 и java 10, по моему опыту мало кто использует на проде, все ждут 11. Ну и вообще, backend в целом намного консервативнее в настоящее время.

  15. zim32
    /#18772625

    А не надо постоянно учить текущие тренды. Я когда так для себя учил ангулар он был второй версии. Сейчас уже шестой вроде.


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

    • andreysmind
      /#18772773

      В рабочее время?

      • zim32
        /#18773201

        Ну а вы предлагаете сутками на пролет учииь каждый релиз кадого фреймворка?

        • andreysmind
          /#18773321

          Не понял связи между репликами?:)

          • zim32
            /#18773691

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

    • paratagas
      /#18773039

      Ага, еще 3 дни — и вы изучили Symfony, еще 3 дня — ASP.NET MVC. Через 2 месяца вы будете писать на 20 масштабных фреймворках… и не знать ни одного из них. Люди годами изучают одну библиотеку или фрэймворк, чтобы знать все тонкости — а вы: 3 дня…

      • zim32
        /#18773223

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

      • snuk182
        /#18774155

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

  16. D_E_S
    /#18773555

    По не маленькому опыту работы могу сказать что для изучения чего-то нового хорошо работать в маленьких веб-студиях)). Там хоть каждый день делай новые эксперименты и используй новые фичи. А вот чем крупнее студия тем более трепетно подходят к выбору стека технологий. А если уж работать не в веб-студии а штатным программист то и речи о развитии и не может идти одна рутина. Это скорей все зависит от интересов каждого и места на которые хотите попасть.

  17. ThisMan
    /#18775047

    Проблема ( как минимум с вебом ) это то что он еще не готов к такому бурному росту/изменению. Берешь какой-нибудь проект, который начинался в 2010, когда еще не было всяких es6, когда стандарты не выпускались каждый год и там дремучий древний лес. Как-то обновлять это — легче переписать с самого начала. Возможно, со временем, если скорость изменений языка/стандартов будет сохранятся, будут придуманы инструменты, для более безболезненного перехода на новые фичи языка.


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

    • JustDont
      /#18775679

      Как-то обновлять это — легче переписать с самого начала.

      Я по долгу службы работаю с проектом, который начинался в 2002 году.
      Нормально там всё обновляется. Можно даже (если б это было реально надо) поэтапно перетащить в современную среду и разбить на модули, несмотря на то, что проект сильно большой.

  18. Portnov
    /#18775823

    Ещё направление «миграции» — в сторону предметной области. Обычно предметные области изменяются гораздо медленнее, чем версии фреймворков. Хорошего специалиста по какому-нибудь налоговому учёту с опытом разработки софта для этого, компания, разрабатывающая такой софт, вероятно, «с руками оторвёт», даже если он не знает чем восьмая жава от седьмой отличается.
    Тут конечно 1) не всем программистам интересен налоговый учёт; и 2) в этом случае вы ограничите себе выбор работодателя только теми фирмами, которые занимаются налоговым учётом. Но можно утешать себя тем, что специалисту с дипломом что-нибудь вроде «кадровый учёт в бюджетных учереждениях», скорее всего, вообще никогда не придёт в голову собеседоваться на должность «специалист по складскому учёту в международной корпорации» (утрирую).
    Т.е. профессия «писатель кода» хороша тем, что код нужен во всех отраслях народного хозяйства. Но плата за это — большое разнообразие используемых технологий (и в некоторых отраслях — очень быстрая их смена).

  19. duff
    /#18776217

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

    • varanio
      /#18776635

      Практически все в машине слушают радио. Подкасты отвлекают не сильнее музыки, в общем-то. То же радио по сути