Как стать автором
Обновить

Комментарии 115

Странно — то говорят, что постоянно нужно изучать что-то новое (а значит и эти самые туду листы как практика), чтобы держать себя в форме, а теперь говорят, что это вредно.
Определитесь, пожалуйста.
Не обязательно же ограничиваться хеллоуворлдами на новых фреймворках. Можно изучать алгоритмы, можно углубляться в то, что уже знаете
Мне новые фреймворки интересны тем, как они написаны: какая идеалогия положена в их основу, какие архитектурные решения выбраны, как решены проблемы, с которыми вы сталкиваетесь в вашем основном фреймворке… С этой т.з. я очень люблю смотреть чужой код, а тупо писать helloword'ы и пр тестовые штуки как-то странно, — в этом плане автор прав.
Конечно обозревать новые технологии нужно. Автор говорит о нерациональном расходе времени на обучение навыкам, которые не будут применяться на практике. Ранее были статьи с посылом «недостаточно быть программистом, нужно стремиться стать разработчиком»; для этого как раз нужно думать не о результате, а уметь сосредоточится на процессе.
Конечно обозревать новые технологии нужно.

Всё дело в том, что эти ваши так называемые "фреймворки" — это не технологии. Это всего лишь плод деятельности очередного графомана-программиста, или команды таковых. Зачем тратить время на изучение чужой графомании — непонятно. В компьютерной сфере в плане софта вообще очень мало того, что можно на самом деле назвать технологиями, и в них мало что меняется со временем. Примеры: технология fork-on-accept и более современная, но всё же немолодая, технология асинхронной обработки всех соединений в одном потоке — для веб-серверов. Заметьте, они не привязаны ни к каким конкретным программным продуктам, но вторую, например, использует nginx. Сам nginx — не технология, но он содержит некоторые внутри себя.

А я о технологиях и говорил (или как правильно, паттерны?). Последний раз занимался web ещё до выхода рельс (что доставляет некоторые неудобства, — буду обозревать).
Эта тенденция касается не только веб-разработки, информация удваивается каждые 1.5-2года и с этим ничего не поделать, особенно перфекционистам, привыкшим знать свою область в совершенстве.

Вредно, но надо.
Никакого противоречия.

А зачем надо, если вредно? Может, лучше надо что-нибудь полезное вместо этого?
Автор, на мой взгляд, даёт хороший ответ на Ваш вопрос: «Думаю, что решение в поиске правильного баланса.»

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

Могу привести пример первой крайности, т.к. вторая крайность есть у большинства программистов и тут примеры не нужны. :-) Работал в одной конторе, через которую выполняли федеральную программу выдачи льготных лекарств. Там нужно было загрузить в систему полученные миллионы данных о выданных рецептах, накрутить на них свои 10% стоимости и выгрузить для следующего посредника, который сделает тоже самое. Если кто не знал, так работают у нас большинство федеральных программ и каждый такой посредник имеет отношение к определенному правителю.

В общем, у нас начальник отдела ИТ знал только 1С 7.7, при том знал хорошо, но такая задача явно не для 1С. Он знал только 1С и не хотел осваивать что-то ещё и как результат мы всё в конторе писали на этой платформе. Когда мы всё сделали и начали гонять рецепты, но у нас уходило на эту операцию часов 5-6 в то время как контора которой мы передавали рецепты делала тоже самое примерно за час, потому что они реализовали это в БД Оракл. Их программисты приходили к нам и хвастались. К слову контора передавшая нам рецепты и контора в которую мы передали, находились в одном здании и мы друг друга знали.

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

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

Просто я не понимаю зачем "изучать" какую-то технологию просто так, ради интереса

  1. Помогает развеяться/отвлечься/сделать "перекур"/т.п. от текущей работы.
  2. Всё-таки изучение технологии (если это действительно технология) может дать новые знания, навести на новые мысли. Это помогает смотреть на текущие проблемы (и даже на уже решённые) "из новых мест". Бывает, в голове загорается лампочка.

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

Смотря какой у вас опыт в программировании. Если вы уже несколько лет работает на какой-то технологии и более-менее углубились, то почему бы и изучить новую. Тем более вам есть с чем сравнить. А если молодой разработчик год обучения потратит на js, реакт, aгуляр, vue(по 3 месяца на каждый отрезок), то скорее всего кпд будет так себе
НЛО прилетело и опубликовало эту надпись здесь
Эникейщик — это человек который бегает между бухгелтерами и нажимает им кнопку Any Key, которую они не могут найти на клавиатуре.

Программисты так никогда не назывались.

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

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

Главное — что через какое-то время сами эникейщики начинают верить в то, что они программисты — ну там, начинающие…
Эникей — принеси, подай, иди нафиг, не мешай. Жаргонизм. Часто имеет пренибрежительно-снисходительный окрас. Означает неквалифицированного работника, которого привлекают на работы по администрированию небольших офисных сетей и ПК. Кроме администрирования нередко занимается обслуживанием оргтехники. Не имеет необходимых знаний по программированию, хотя в трудовой книжке может числиться как программист. Как правило, о словах «эникей, эникейщик» известно лишь коллегам из IT сферы. Потому что эникей — это такой аналог «духа» в армии.

Программист — общепринятое название профессии.
Бухгалтер — общепринятое название профессии.
Главный бухгалтер — общепринятое название должности.

Пожалуйста, покажите этот пост всем страшно обидчивым главным бухгалтерам.
— Здравияжелаю, товарищ Главный Бухгалтер! Тут такое дело…
и показываете пост.

Пожалуйста, покажите этот пост всем страшно обидчивым главным бухгалтерам.
— Здравияжелаю, товарищ Главный Бухгалтер! Тут такое дело…
и показываете пост.
Смешно… но полезно. Показывать этот пост нужно скорее тем, что обижается на тех, кто эникейщиков в программисты записывает.

Бухгалтер — общепринятое название профессии.
Главный бухгалтер — общепринятое название должности.
Ой ли? Тут ведь куда строже, чем в случае с «тыжпрограммистами». Если вы наймёте «тыжпрограммиста-эникейщика» с десятилетним стажем (но, скажем, зачитывавшегося Корманом по ночам) — то вам слова никто ходуго не скажет. А в случае с бухгалтерами — есть аттестация. Правда пока она касается только госучереждений, но с 2018го года — собираются вводить её для всех. При этом для аттестата «бухгалтера» — требуется только среднее профобразование, а для «главбуха» — высшее плюс стаж работы по специальности.

Фактически главбух от линейщика отличается не меньше, чем эникейщик от программиста Яндекса или Гугла.

В 90-е годы, часто на одном человеке висело и программирование, и админка, и техподдержка пользователей.

А сейчас что-то поменялось?
Да

Веб-мастерами их называли. Но суть та же, понемногу отовсюду и ничего на уровне программиста.

эникейщиками называли третьих помощников младшего системного администратора — их основная задача была реакция на надпись — Press any key to continue

НЛО прилетело и опубликовало эту надпись здесь

Fullstack это не тот кто знает всего понемногу, а тот кто может взять горсть различных технологий и совместить их всех вместе. Sql, noSql, кеширование, фреймворк на сервере и клиенте, плагины для этих фреймов итд. Стыки технологий у многих вызывают трудности. Фуллстек хорош тем, что для него эти стыки просты.

Это в идеале. Взять инструменты, которыми ты владеешь профессионально и построить дом.

В ситуации, когда новые молотки появляются по три штуки в год — овладеть ими профессионально становится все сложнее.

ИМХО.
Зачем изучать новые молотки?
Вот есть у вас React/angular, делайте на нем.
Как поймете что зарплата скатилась ниже 180 и технология мертва, берете другой фреймворк.

Хотя технология так быстро не мрет, вон Delphi спецы даже сейчас требуются

Это где такие зарплаты?
Т.е. раньше делал ВСЕГО понемногу. Всего что надо людям. И это называлось эникейщик. А теперь из всего зоопарка технологий, благодаря «квалификации», делаю одну фигню в одной области. Это видимо называется словом «специалист».

ясно там, где нет необходимости в нормальном системном администраторе — там пользовали аникейщиков. Не стоит говорить очевидные истины
Насчет fullstack разработчиков — это просто неверно. Многие разработчика в силу своего профессионального опыта могут реализовать многокомпонентную систему.
Разделение на backend и frontend повышает скорость разработки и увеличивает ее надежность в силу взаимного тестирования в ходе разработки.

Разделение на backend и frontend повышает скорость разработки и увеличивает ее надежность в силу взаимного тестирования в ходе разработки.

Не всё так однозначно. Разделение так же повышает риски несогласованных изменений (или потери времени на согласование), либо решение проблем не надлежащей стороне.

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

Не всегда это экономически оправдано.

Раньше это были «веб-разработчики PHP+jQuery»
Эникейщик и фулл-стек разработчик — абсолютно разные вещи. Эникейщик вообще не разработчик, если что.
Исторически, эникейщик это именно сисадмин, который работал в небольшой конторе, где большинство проблем было вида «на мониторе возникла надпись press any key to continue» и необходимо было звать админа для решения этой проблемы. Даже из названия понятно что и откуда появилось. Если где-то в какой-то узкой среде, форуме, коллективе эникейщиками называли фулл-стек разработчиков это не значит, что так делали изначально и повсеместно, это лишь конкретный мем конкретного круга лиц.
Я страдаю этим синдромом. Но из-за того, что на обещал много по своему проекту, у меня просто нет времени на изучение, только практика. Верно подмечено: действительно ощущение, словно пропускаешь что-то очень важное)

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

А что даёт это написание туду-листов? Какой в этом прок? Я к тому, что если уж коротать вечера за изучением новых языков или фреймворков, то гораздо интереснее взять какой-нибудь небольшой, но реальный собственный проект из уже реализованных и рабочих. Тогда можно сразу посмотреть, как в новом языке или фреймворка будут решены те проблемы, которые реально возникали. Будет ли тут что-то подобное, может быть, какие-то задачи с использованием новой технологии решаются изящнее или, напротив, криво. Опять же, при «переводе» с языка на язык, есть хороший шанс найти пару-тройку ошибок в реальном проекте, что тоже хорошо. Зачем миру миллионы одноклеточных туду-листов?
Свой реальный проект ещё придумать надо, не у всех фантазии на это хватает. А тестить технологии на чем-то надо, вот и пишут простенькие велосипедики из раза в раз.

"Перевод" рабочего проекта или его части на новый стэк в рабочее время на рабочем месте может быть не разрешён работодателем по причине "мы тебе не за это платим", а дома в личное время по всяким NDA.


А какое-то стандратное приложение хорошо для сравнения технологий или для контроля своего их понимания.

ИМХО это синдром потребительской культуры: «покупай непрерывно!», «выброси старый гаджет и купи новый; неважно, что старый отлично работает и удобен!» и т.д. Под гаджетом может подразумеваться всё: автомобиль, iPhone, ПО и т.д.
НЛО прилетело и опубликовало эту надпись здесь
это называется «неомания»: когда нечто объявляется лучшим просто потому, что оно самое новое, самое свежее, самой последней версии
В некоторых компаниях звучит: «Мы хотим взять full-stack разработчика», а на деле: «мы решили сэкономить, поэтому наймем вместо двух, одного»

Это называется рациональный подход, а не экономия на спичках.


Есть очень много реальных задач где двоим выделенным спецам с отдельной специализацией работы очень не надолго.


И что же им потом делать? В потолок плевать за зарплату?

Гораздо чаще берут двух фуллстэков вместо фронтендера и бэкендера. Этим исключают простои типа «есть большая задача по бэку, а по фронту пока делать нечего» или наоборот. Плюс исключают ситуации типа «это задача по бэку, а я фронт, а бэк в отпуске/на больничном — ждите»
5версий змейки за 2-3месяца )На си, C#, C++, Python, JS
Обычный переводчик текста из сценарного в скриптовой — F#, PYTHON, C#
Нормальных проектов — один-два и то по работе
>Обычный переводчик текста из сценарного в скриптовой — F#, PYTHON, C#

Вот сейчас не понял. Сценарный же и есть скриптовой.
А вариант «Я этим синдромом наслаждаюсь» не предусмотрен? Можно ведь просто посмотреть, что есть ещё, а потом уже решать, погружаться или нет глубже.
А какой фреймворк, из приведённой в статье картинки, можно еще считать не почившим в бозе технологий, спустя хотя бы лет 10.
Когда ты его изучил долго колупаясь, и написал таки что-то важное и полезное, какой нибудь магазин например. Или 1С'очку в Web-исполнении.
1С'очка кстати имеет офигенный список туду. И очень значительная часть относится к Web-исполнению. Хронически не успевая за Web-стандартами.
Потому в Web-области и перевелись программисты, остались фул-стеки.

В жизни понял одну вещь. Чтобы не было синдрома ученика нужно уходить в менеджмент. Всеми способами. Отработал, принес пользу, задрочил стек и в менеджмент. Быть рограммистом в 30+ лет, которому нужно постоянно переучиваться или прыгать с технологии на технологию за "ну вечером почитай, чего тебе стоит" — себя не уважать.

Ага, и получится из вполне приличного инженера хреновый менеджер, много раз видел такое. Все-таки задачи и скилы менеджера и программиста сильно разные
А у менеджеров нет стека? Побыл менеджером, принёс пользу, задрочил стек и… Куда? Шучу конечно, я был программистом, потом небольшим менеджером, потом плюнул на менеджера, не понравилось, вернулся программировать, очень доволен.
Что значит «и куда»? Программистов давить: вы медленно пишете, ваш код плохой, продукт не продавабельный, вы ничего не хотите знать, не хотите учиться.
Из менеджеров не уходят! Из них только выносят :)
>> Программистов давить: вы медленно пишете…
Шутите?))). Быстро получить неизвестное решение? Разве только сомнительного индусского качества. Согласен, что в профессии программиста есть две составляющие — продумывание решения и программирование. Писать можно быстро, если именно вы дали продуманное решение, которое понято и которое соответствует ТЗ. Но сколько вы на это потратили время? Такое нельзя предсказать за исключением однотипных задач. За продажи программист ответственности не несёт. Это ваша, менеджерская зона ответственности. А если менеджер обвиняет программистов в плохой продаваемости продукта, то, простите, это плохой менеджер. (Не имею ввиду лично вас)
>> Из менеджеров не уходят! Из них только выносят :)
Некоторых прямо с совещаний.
Себя не уважать — это всеми способами бежать из разработчиков в менеджеры, не испытывая к этому особого желания.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Я не гоняюсь за ветром, я занимаюсь тем, что мне интересно. А есть профессии, где если не в 35, то в 40 отправляют на пенсию по вполне объективным причинам. И PHP за 20 лет очень сильно изменился. А, главное, любой другой способ зарабатывания на жизнь не будет, с одной стороны, мне доставлять такого уодовольствия, а, с другой, я все равно буду программировать для души. И это не гипотетические рассуждения, а опыт, полученный в 30-35 лет.

Сейчас не Средние Века. Люди не умирают к 30. Чтобя только самые старые, коих мало, становились менеджерами.

А по вашей системе вы просто избавите мир от толковых senior
НЛО прилетело и опубликовало эту надпись здесь

А нравилось хоть когда-нибудь? Была радость "о, а за это ещё и деньги платят?!"

НЛО прилетело и опубликовало эту надпись здесь

Ну а мне и 30 лет назад нравилось, и сейчас нравится. Не считаю, что нарушаю закономерность :)

Это индивидуально. Мне сейчас 43, первую программу написал в 14 (т.е. скоро 30летний юбилей будет), все еще нравится программировать.
Ну а мне 48 и программирование за счастливку. В том числе и регулярное изучение всех этих новшеств о которых статья.
Пару лет назад сделал дауншифтинг с менеджмента назад в чистую разработу — и счастлив.
Менеджер тоже должен знать стек технологий далеко не поверхностно, ну если это нормальный управленец
Нет. Генеральный директор крупной конторы должен знать весь свой огромнейший стек что ли? Это тупиковый подход.
Он должен знать стек управления людьми, если можно так выразиться.
А старшие спецы которые знают технический стек — это тех лиды и сенторы и архитекторы.
Менеджер пусть лучше знает как заказчика убедить больше бабла дать за меньше работы.
Самому низовому менеджеру конечно желательно представлять с чем он работает, тогда он не будет лишь передатчиком слов от тех спецов к клиенту.
Но строго говоря это не обязательно.
Как говорил мой знакомый и успешный руководитель — моя работа это постоянные беседы, таким образом я бываю в курсе дел.

Интересно, кто-нибудь оценивал пользу от этого зоопарка технологий и фреймворков?

Конечно. Под каждую задачу можно найти фреймворк, лучше её решающий.
НЛО прилетело и опубликовало эту надпись здесь

Как минимум польза от множества фреймворков в PHP — конкуренция.

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

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


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


А сейчас успешно писать на PHP4 сложно, даже поддержку 7.0 некоторые уже дропают. Писать-то вы можете, но вот использовать сторонние решения — с трудом.

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

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

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

Хм, игра на бирже начинает казаться гораздо более надёжным вложением времени и денег, чем это.

он выйдет из моды как раз к тому моменту, как вы в нём станете экспертом.

Из моды выйдет, а проекты на нём останутся.

Ну вышел он из моды? Что он перестал решать проблему?
Смотрите продолжают ли авторы поддержку — и используйте или нет.
Смотрите сильно ли лучше под именно ваши задачи новые и переходите на них или нет.
Все претензии о немодности — они с точки зрения возможной смены работы.
Занимаюсь разработкой около 10 лет, за это время успел поработать над разработкой под дэсктопы, мобильные, серверной и клиентской разработкой под вэб, проектированием, архитектурой, коммерческая разработка, немного open source, в общем много чего было.

С момента начала работы в ИТ пережил несколько стадий синдрома:

Стадия первая — потребление знаний, без применения. Симптомы: жесткие диски забиты книгами, видео уроками, любая попытка найти информацию в интернете заканчивается вагоном вкладок и кучей закладок в браузере, множеством материала, который «потом дочитаю», подписка на массу рассылок, ничего из изученного не идет дальше «hello, world».

Стадия вторая — я все могу, явилась следствием первой стадии. Симптомы: казалось, что с таким объемом прочитанного и просмотренного могу написать хоть черта лысого, любая задача воспринималась как «фигня», которую я сделаю без проблем, характеризовалась минимумом реально сделанной работы и максимумом чесания языком.

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

Стадия третья — упороться в одну тему и копать вглубь, результат осознания проблем первых двух стадий. Симптомы: долгое, упорное копание одной темы, без явной на то необходимости. Первым и последним опытом в этой стадии для меня стали алгоритмы, я нашел несколько хороших книг и начал изучать и реализовывать от и до по списку. Закончилась быстро, в это же время устроился на работу в сфере ИТ и довольно быстро понял, что занимаюсь не тем, потому что реального применения на должности html-версталщика алгоритмам найти было непросто.

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

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

После этого я сделал небольшой перерыв в работе, в это время занимался тем, что писал «в стол», написал несколько разных приложений, полностью от начала, до «релиза», отточил прикладные навыки в нескольких областях, собрал себе «ящик с инструментами»: система контроля версий, крупный фрэймворк, несколько десятков необходимых библиотек, ide, научился пользоваться инструментами дебага, начал обкатывать процессы непрерывной интеграции. После этого заново устроился на работу в ИТ, работу подбирал под навыки. И был приятно удивлен — работалось на удивление продуктивно и довольно качественно, я редко лажал по срокам и приносил, небольшому бизнесу, вполне ощутимую пользу. Это для меня был следующий этап, продуктивный застой, количество новых знаний стремится к нулю, но работа идет хорошо.

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

С этого момента я научился много чему, изучил много нового, видел как учатся и развиваются другие люди, но основная механика осталась:
Случайно, запостил, не дописал.

С этого момента я научился много чему, изучил много нового, видел как учатся и развиваются другие и для себя определил следующие механики:

1. копать знания до фундамента, фрэймворков и инструментов очень много, но на фундаментальном уровне они мало отличаются

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

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

4. не учиться чему-то одному, если начинаешь давить в одну сторону, то страдают остальные направления

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

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

7. доверяй, но проверяй, информации много и большая её часть представляет из себя мусор, ни к чему обременять мозг этим

8. большая часть знаний использующихся сейчас — знания старые, большая часть представляет собой удачное переосмысление того, что было придумано десятки лет назад, понимая первопричины возникновения определенных механик, практик и знаний гораздо проще их воспринимать
Ваш коммантарий тянет на целый пост.
Проблема зацикливания. А после того, как начал изучать новое и сделал первый десяток шагов думаешь «Надо делать заняться!», и тебя гложет то, что ты бросил на пол пути изучение. И по кругупокругупокругу!
Кхм, а что если все ограничивается только изучением? Выполнение учебных заданий после каждой главы книги/туториала и все? Даже никакой кучи todo-приложений, которые хотя бы можно было кому-то показать? Наверное, все еще хуже и нужно что-то с этим срочно делать, да?
// я из мира iOS-разработки
НЛО прилетело и опубликовало эту надпись здесь
Конечно есть, век живи — век учись.
Как говорит заведующий моей кафедрой: «Самый лучший язык программирования тот, который ты лучше всего знаешь.». И это можно спроецировать на фреймворки. Если вы используете один фреймворк в своей работе, то лучше изучить его глубже — стать в нём экспертом, нежели изучать с нуля какой-то «Newname»-фреймворк.
На счёт изучать одну ветку знаний — один фреймворк, одну технологию и т.д. как можно лучше — вполне себе соглашусь, дело благое. Но языки программирования стоит подбирать под задачи, а не использовать тот самый «золотой молоток», который лучше всех знаешь.
Частенький вопрос на Тостере — выбор языка на веб сервер под задачу.
И ответ именно такой — тот язык что лучше знаешь

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

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

Еще один фактор — изучение как «тренировка» мозга. Например, мышцы спины слабеют, если не поднимать тяжести — так же мозг банально «гасится» если не «грузить» его разные области. Изучение нового, обновление старых знаний, сходить на концерт (или просто послушать музыку не фоном, а именно послушать растворившись в ней) или почитать хорошую художественную книгу. Особенно, если в данный момент по работе в 90% времени приходится выполнять довольно однотипные задачи.
НЛО прилетело и опубликовало эту надпись здесь
Интеллектуальная активность, в том числе увлечение игрой в шахматы, и регулярное общение коррелируют со сниженным риском развития болезни Альцгеймера, по данным эпидемиологических исследований, однако причинно-следственная связь пока не доказана.
Согласно подобной точки зрения все люди, кто задействован вне каких-то умственных сфер деятельности — должны уже деградировать. Хотя, на практике, лично я вижу обратное, но это отдельная сфера для разговора.

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

А некоторым сам процесс нравится :)

Можно сказать конечно и по другому, что: «Повторение-мать учения». Но хотя, я больше соглашусь с вами. Бывает делаешь одни и те же ошибки по сто раз, порой задумываешься уже, а почему же так, почему же. А просто порой нужно следить за собой, стараться черпать что-то новое и уметь применять это в деле.
Автор статьи выделил основной посыл, который нам завещал дедушка Ленин, — «Учиться, учиться и еще раз — учиться, товарищи». Это то, что выделяет Вас от профессионала — время которое было потрачено на любимое дело. Вопрос: это время было потрачено на одну технологию, или на семесйство технологий. Пройдя пару-тройку технолгий/фреймворков начинается выделяться общая концепция/идеи, и порой сильно удивляешся, когда понимаешь, что изначально идея были описана/придумана 20-30 лет назад.

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

Публикации

Истории