Комментарии 115
Определитесь, пожалуйста.
Конечно обозревать новые технологии нужно.
Всё дело в том, что эти ваши так называемые "фреймворки" — это не технологии. Это всего лишь плод деятельности очередного графомана-программиста, или команды таковых. Зачем тратить время на изучение чужой графомании — непонятно. В компьютерной сфере в плане софта вообще очень мало того, что можно на самом деле назвать технологиями, и в них мало что меняется со временем. Примеры: технология fork-on-accept и более современная, но всё же немолодая, технология асинхронной обработки всех соединений в одном потоке — для веб-серверов. Заметьте, они не привязаны ни к каким конкретным программным продуктам, но вторую, например, использует nginx. Сам nginx — не технология, но он содержит некоторые внутри себя.
Вредно, но надо.
Никакого противоречия.
А лично мне статья кажется полезной — позакрываю пару десятков вкладок со всякими разными и интересными фреймворками и технологиями до которых ещё пока не доходили руки
Могу привести пример первой крайности, т.к. вторая крайность есть у большинства программистов и тут примеры не нужны. :-) Работал в одной конторе, через которую выполняли федеральную программу выдачи льготных лекарств. Там нужно было загрузить в систему полученные миллионы данных о выданных рецептах, накрутить на них свои 10% стоимости и выгрузить для следующего посредника, который сделает тоже самое. Если кто не знал, так работают у нас большинство федеральных программ и каждый такой посредник имеет отношение к определенному правителю.
В общем, у нас начальник отдела ИТ знал только 1С 7.7, при том знал хорошо, но такая задача явно не для 1С. Он знал только 1С и не хотел осваивать что-то ещё и как результат мы всё в конторе писали на этой платформе. Когда мы всё сделали и начали гонять рецепты, но у нас уходило на эту операцию часов 5-6 в то время как контора которой мы передавали рецепты делала тоже самое примерно за час, потому что они реализовали это в БД Оракл. Их программисты приходили к нам и хвастались. К слову контора передавшая нам рецепты и контора в которую мы передали, находились в одном здании и мы друг друга знали.
Для меня это тогда стало первым уроком, что не всё можно эффективно сделать на одном языке, после чего я ударился во вторую крайность. :-)
Я думаю надо ориентироваться на свои задачи и использовать те инструменты которые нужны для ее решения. Просто я не понимаю зачем "изучать" какую-то технологию просто так, ради интереса — возможно, но на это уходит часто много времени, а выгоды ноль.
Просто я не понимаю зачем "изучать" какую-то технологию просто так, ради интереса
- Помогает развеяться/отвлечься/сделать "перекур"/т.п. от текущей работы.
- Всё-таки изучение технологии (если это действительно технология) может дать новые знания, навести на новые мысли. Это помогает смотреть на текущие проблемы (и даже на уже решённые) "из новых мест". Бывает, в голове загорается лампочка.
Не поверите, но многие люди делают что-то не только ради выгоды, но из интереса. Кто-то книги читает, кто-то путешествует, кто-то футбол смотрит под пиво, а кто-то технологии изучает.
Программисты так никогда не назывались.
Наоборот — есть. Эникейщиков программистами называют. Админов не эникейщиков бухгалтера тоже называют программистами
Главное — что через какое-то время сами эникейщики начинают верить в то, что они программисты — ну там, начинающие…
Программист — общепринятое название профессии.
Бухгалтер — общепринятое название профессии.
Главный бухгалтер — общепринятое название должности.
Пожалуйста, покажите этот пост всем страшно обидчивым главным бухгалтерам.
— Здравияжелаю, товарищ Главный Бухгалтер! Тут такое дело…
и показываете пост.
Пожалуйста, покажите этот пост всем страшно обидчивым главным бухгалтерам.Смешно… но полезно. Показывать этот пост нужно скорее тем, что обижается на тех, кто эникейщиков в программисты записывает.
— Здравияжелаю, товарищ Главный Бухгалтер! Тут такое дело…
и показываете пост.
Бухгалтер — общепринятое название профессии.Ой ли? Тут ведь куда строже, чем в случае с «тыжпрограммистами». Если вы наймёте «тыжпрограммиста-эникейщика» с десятилетним стажем (но, скажем, зачитывавшегося Корманом по ночам) — то вам слова никто ходуго не скажет. А в случае с бухгалтерами — есть аттестация. Правда пока она касается только госучереждений, но с 2018го года — собираются вводить её для всех. При этом для аттестата «бухгалтера» — требуется только среднее профобразование, а для «главбуха» — высшее плюс стаж работы по специальности.
Главный бухгалтер — общепринятое название должности.
Фактически главбух от линейщика отличается не меньше, чем эникейщик от программиста Яндекса или Гугла.
В 90-е годы, часто на одном человеке висело и программирование, и админка, и техподдержка пользователей.
Веб-мастерами их называли. Но суть та же, понемногу отовсюду и ничего на уровне программиста.
эникейщиками называли третьих помощников младшего системного администратора — их основная задача была реакция на надпись — Press any key to continue
Fullstack это не тот кто знает всего понемногу, а тот кто может взять горсть различных технологий и совместить их всех вместе. Sql, noSql, кеширование, фреймворк на сервере и клиенте, плагины для этих фреймов итд. Стыки технологий у многих вызывают трудности. Фуллстек хорош тем, что для него эти стыки просты.
ясно там, где нет необходимости в нормальном системном администраторе — там пользовали аникейщиков. Не стоит говорить очевидные истины
Насчет fullstack разработчиков — это просто неверно. Многие разработчика в силу своего профессионального опыта могут реализовать многокомпонентную систему.
Разделение на backend и frontend повышает скорость разработки и увеличивает ее надежность в силу взаимного тестирования в ходе разработки.
Разделение на backend и frontend повышает скорость разработки и увеличивает ее надежность в силу взаимного тестирования в ходе разработки.
Не всё так однозначно. Разделение так же повышает риски несогласованных изменений (или потери времени на согласование), либо решение проблем не надлежащей стороне.
"Перевод" рабочего проекта или его части на новый стэк в рабочее время на рабочем месте может быть не разрешён работодателем по причине "мы тебе не за это платим", а дома в личное время по всяким NDA.
А какое-то стандратное приложение хорошо для сравнения технологий или для контроля своего их понимания.
Это называется рациональный подход, а не экономия на спичках.
Есть очень много реальных задач где двоим выделенным спецам с отдельной специализацией работы очень не надолго.
И что же им потом делать? В потолок плевать за зарплату?
Обычный переводчик текста из сценарного в скриптовой — F#, PYTHON, C#
Нормальных проектов — один-два и то по работе
Когда ты его изучил долго колупаясь, и написал таки что-то важное и полезное, какой нибудь магазин например. Или 1С'очку в Web-исполнении.
1С'очка кстати имеет офигенный список туду. И очень значительная часть относится к Web-исполнению. Хронически не успевая за Web-стандартами.
Потому в Web-области и перевелись программисты, остались фул-стеки.
В жизни понял одну вещь. Чтобы не было синдрома ученика нужно уходить в менеджмент. Всеми способами. Отработал, принес пользу, задрочил стек и в менеджмент. Быть рограммистом в 30+ лет, которому нужно постоянно переучиваться или прыгать с технологии на технологию за "ну вечером почитай, чего тебе стоит" — себя не уважать.
Из менеджеров не уходят! Из них только выносят :)
Шутите?))). Быстро получить неизвестное решение? Разве только сомнительного индусского качества. Согласен, что в профессии программиста есть две составляющие — продумывание решения и программирование. Писать можно быстро, если именно вы дали продуманное решение, которое понято и которое соответствует ТЗ. Но сколько вы на это потратили время? Такое нельзя предсказать за исключением однотипных задач. За продажи программист ответственности не несёт. Это ваша, менеджерская зона ответственности. А если менеджер обвиняет программистов в плохой продаваемости продукта, то, простите, это плохой менеджер. (Не имею ввиду лично вас)
>> Из менеджеров не уходят! Из них только выносят :)
Некоторых прямо с совещаний.
42 и не малейшего желания идти в менеджмент
Я не гоняюсь за ветром, я занимаюсь тем, что мне интересно. А есть профессии, где если не в 35, то в 40 отправляют на пенсию по вполне объективным причинам. И PHP за 20 лет очень сильно изменился. А, главное, любой другой способ зарабатывания на жизнь не будет, с одной стороны, мне доставлять такого уодовольствия, а, с другой, я все равно буду программировать для души. И это не гипотетические рассуждения, а опыт, полученный в 30-35 лет.
А по вашей системе вы просто избавите мир от толковых senior
А нравилось хоть когда-нибудь? Была радость "о, а за это ещё и деньги платят?!"
Пару лет назад сделал дауншифтинг с менеджмента назад в чистую разработу — и счастлив.
Он должен знать стек управления людьми, если можно так выразиться.
А старшие спецы которые знают технический стек — это тех лиды и сенторы и архитекторы.
Менеджер пусть лучше знает как заказчика убедить больше бабла дать за меньше работы.
Самому низовому менеджеру конечно желательно представлять с чем он работает, тогда он не будет лишь передатчиком слов от тех спецов к клиенту.
Но строго говоря это не обязательно.
Как говорил мой знакомый и успешный руководитель — моя работа это постоянные беседы, таким образом я бываю в курсе дел.
Интересно, кто-нибудь оценивал пользу от этого зоопарка технологий и фреймворков?
Как минимум польза от множества фреймворков в PHP — конкуренция.
Конкуренты предлагают разные пути решения одних типов задач, а ты выбираешь тот, что лучше.
Архитектурная прежде всего. Насколько сильно помогает фреймворк решать типовые задачи, насколько сильно мешает решает нетиповые, легко ли заменять какие-то компоненты на сторонние или самописные, если штатные чем-то не устраивают.
На мой взгляд, в мире PHP фреймворков, которые можно рассматривать в качестве основы для нового серьёзного проекта пять штук, максимум, будет, причём лидеры одни и те же последние годы. Пускай даже десять. Каждый коммит в них отслеживать не надо, достаточно время от времени читать обзоры о новых версиях, как, например, бухгалтеру нужно время от времени читать изменения в нормативной базе, а не вылезать с сайтов законодателей и регуляторов.
А сейчас успешно писать на PHP4 сложно, даже поддержку 7.0 некоторые уже дропают. Писать-то вы можете, но вот использовать сторонние решения — с трудом.
Или перевыбрать раньше если что то прям не устраивает.
Нет ничего удивительного что они разные — ведь и задачи разные.
А это уже не просто хайп — а предварительно нужно тщательно подумать. Авторы фреймворков занимаются тем до чего не доходят руки в потоке каждодневных работ у большинства.
Изучать надо то, что только-только появилось, когда ещё даже не вполне понятно, выстрелит оно или нет. Тогда, если вы угадали с технологией, как раз станете экспертом к пику популярности. Если же не угадали — что ж, вы просто потеряли время.
Хм, игра на бирже начинает казаться гораздо более надёжным вложением времени и денег, чем это.
он выйдет из моды как раз к тому моменту, как вы в нём станете экспертом.
Из моды выйдет, а проекты на нём останутся.
Смотрите продолжают ли авторы поддержку — и используйте или нет.
Смотрите сильно ли лучше под именно ваши задачи новые и переходите на них или нет.
С момента начала работы в ИТ пережил несколько стадий синдрома:
Стадия первая — потребление знаний, без применения. Симптомы: жесткие диски забиты книгами, видео уроками, любая попытка найти информацию в интернете заканчивается вагоном вкладок и кучей закладок в браузере, множеством материала, который «потом дочитаю», подписка на массу рассылок, ничего из изученного не идет дальше «hello, world».
Стадия вторая — я все могу, явилась следствием первой стадии. Симптомы: казалось, что с таким объемом прочитанного и просмотренного могу написать хоть черта лысого, любая задача воспринималась как «фигня», которую я сделаю без проблем, характеризовалась минимумом реально сделанной работы и максимумом чесания языком.
В моем случае, обе стадии шли рука об руку. Побороть самому, осознанно, не вышло, пока не стало слишком поздно — по крупному зафакапил несколько проектов и чуть было не зафакапил диплом, дело было в университете, но вовремя пришло понимание, что так дальше нельзя.
Стадия третья — упороться в одну тему и копать вглубь, результат осознания проблем первых двух стадий. Симптомы: долгое, упорное копание одной темы, без явной на то необходимости. Первым и последним опытом в этой стадии для меня стали алгоритмы, я нашел несколько хороших книг и начал изучать и реализовывать от и до по списку. Закончилась быстро, в это же время устроился на работу в сфере ИТ и довольно быстро понял, что занимаюсь не тем, потому что реального применения на должности html-версталщика алгоритмам найти было непросто.
Стадия четвертая — не делать ничего, пока на то не будет реальной необходимости. Симптомы: ничего не делать, пока не столкнешься с проблемой, которую не можешь решить, поиск решений или схожих проблем на просторах интернетов. Лечением стала новая работа с оплатой за выполненные проекты, довольно быстро пришло понимание, что много времени уходит на поиск решений, что уменьшает количество сделанной работы, что в свою очередь влияет на оплату, а также, не в лучшую сторону, влияет на предсказуемость сроков на выполнение работы.
Стадия пятая — разочарование. Симптомы: кажется, что ни один из вариантов обучения не прокатил и начинают закрадываться мысли, что, что ни сделай, ничего не сработает. Лечение пришло с неожиданной стороны. В это время мне довелось поработать на заводе, где в первый же день работы мне выдали кипу должностных инструкций, в которых были четкие указания, что и в каком порядке нужно делать в определенных ситуациях, были расписаны этапы работы и за мной были закреплены четкие обязанности. После пары недель работы стало понятно, что и работал я раньше хаотично и учился точно также, пренебрегал инструментами и механиками и все решения обладали одной общей чертой — были уникальными и разовыми.
После этого я сделал небольшой перерыв в работе, в это время занимался тем, что писал «в стол», написал несколько разных приложений, полностью от начала, до «релиза», отточил прикладные навыки в нескольких областях, собрал себе «ящик с инструментами»: система контроля версий, крупный фрэймворк, несколько десятков необходимых библиотек, ide, научился пользоваться инструментами дебага, начал обкатывать процессы непрерывной интеграции. После этого заново устроился на работу в ИТ, работу подбирал под навыки. И был приятно удивлен — работалось на удивление продуктивно и довольно качественно, я редко лажал по срокам и приносил, небольшому бизнесу, вполне ощутимую пользу. Это для меня был следующий этап, продуктивный застой, количество новых знаний стремится к нулю, но работа идет хорошо.
Следующий этап — хочу больше. Симптомы: работа нравится все меньше, кажется, что делаешь одно и то же, а вокруг расцветают пышным цветом всякие nodejs'ы и прочие интересные штуки. Ничего лучше, чем сменить работу, в голову не пришло. Новая работа дала возможность попробовать много всего нового, что в определенной мере заглушило симптомы.
С этого момента я научился много чему, изучил много нового, видел как учатся и развиваются другие люди, но основная механика осталась:
С этого момента я научился много чему, изучил много нового, видел как учатся и развиваются другие и для себя определил следующие механики:
1. копать знания до фундамента, фрэймворков и инструментов очень много, но на фундаментальном уровне они мало отличаются
2. встраивать обучение в работу, в каждую задачу закладывать небольшой объем для изучения, оставлять, так сказать, в задаче пробелы, чтобы в процессе их заполнить
3. концепция ящика с инструментами: фундаментальные знания определяют, что можешь, а чего нет, остальное — инструменты, важно уметь быстро с ними разобраться
4. не учиться чему-то одному, если начинаешь давить в одну сторону, то страдают остальные направления
5. весь процесс обучения должен подводить к одному логическому результату — все знания должны органично складываться в целостную картину мира, если есть пробелы, как в паззле, значит очень скоро они дадут о себе знать, если паззлов несколько — значит знания фрагментированы
6. важно не только сколько у тебя знания, но как ты их получаешь, важна не только цель, но и путь пройденный до нее, нужно учиться получать новые знания, это точно такой же скилл как и написание кода, проектирование или постройка дома, если не этому не научиться — то процесс будет хаотичен и ни к чему не приведет
7. доверяй, но проверяй, информации много и большая её часть представляет из себя мусор, ни к чему обременять мозг этим
8. большая часть знаний использующихся сейчас — знания старые, большая часть представляет собой удачное переосмысление того, что было придумано десятки лет назад, понимая первопричины возникновения определенных механик, практик и знаний гораздо проще их воспринимать
И ответ именно такой — тот язык что лучше знаешь
Тут весь вопрос в том, что понимать под "изучить". Между написанием туду-листа и выдачей хотя бы мало-мальски приличного продакшен-кода для сложного проекта — если не пропасть, то как минимум не одна сотня часов. Тут все подряд уже не наизучаешься...
Согласно подобной точки зрения все люди, кто задействован вне каких-то умственных сфер деятельности — должны уже деградировать. Хотя, на практике, лично я вижу обратное, но это отдельная сфера для разговора.
Лично я вижу как раз деградацию. Отдельные сферы, вроде прокачки эрудиции (решение кроссвордов, например, или чтение литературы широкого профиля) не в счет. Да, такой человек знает много, но гугл знает еще больше, это не умственное развитие.
p.S. Один мой молодой знакомый говорит, что зарабатывает недостаточно, но учиться на разработчика не хочет, т.к. «там постоянно нужно учиться».
У вас есть синдром ученика?