Comments 15
Сам написал, сам прокомментировал. Наверное сейчас таким инструментом становится Go для части разработчиков, ну и никуда не девается Java
Кодить попеременно на C++ и Python - не возникает проблем.
Вот на JS и Python - мрак. Они перемешиваются.
Если вы писали только на статических языках, обязательно выучите динамический
Зачем это?
Если не скрипт, не прототип и не фронт энд то зачем?
Многоязычность в большой компании на большом проекте это возможно неплохо. Но количество экспертов должно быть больше количества языков )
А экспертов много меньше чем просто программистов
Если я пишу на java и kotlin в продакшн, это считается за 2 языка? :D
Тогда мне стало понятно, что выбранная схема обучения программистов в Андеве готовит не программистов, а Rails-программистов.
А разве это - не то, что нужно для бизнеса? Бизнесу, вообще-то, нужны не программисты, а люди, способные выполнять стоящие перед бизнесом задачи средствами IT, причем - с намименьшими на них затратами. И если основную часть этих задач могут делать специально обученные люди - обученные только одному языку, в идеале - одному фреймворку, то целесообразно нанимать именно таких людей, а если их на рынке нет - готовить. Потому что это обойдется просто-напросто дешевле, чем если нанимать сплошь программистов (а уж тем более - настоящих программистов ).
Другой вопрос, что для использования специально обученных людей требуется более сложная организация процесса разработки:
вычленять задачи, которые требуют нетипового подхода и передавать их более квалифицированным исполнителям;
разрабатывать инструкции и выбирать (а то и создавать, если их нет на рынке) вспомогательные инструменты для специально обученных людей, чтобы они могли решать такие задачи, если они вдруг станут типовыми;
вовремя выявлять неправильные методы решения и давать по рукам специально обученным людям за их применение.
Да, организовать работу таким обрзом сложнее, чем просто нанять группу работников-универсалов более высокой квалификации. Но, как показала история той же промышленной революции, рост эффективности производства лежит в этой стороне - в стороне углубления разделения труда, специализации и снижении требований к массовыи работникам. Если бы производством, как в Средние века, занимались бы сплошь квалифицированные мастера-ремесленники, чтобы стать которым нужно было показать свое умение, сделав chef d'oeuvre (шедевр, если в русском произношении), то мы бы ни за что не получили такого изобилия дешевой продукции промышленного производства, какое имеем сейчас.
И я так наблюдаю, что в области разработки ПО бизнес пока что находится на стадии ремесленного производства (к сожалению это или к счастью - зависит от точки зрения).
PS Все написанное выше к теме статьи относится косвенно: в ней обсуждается, как готовить программистов широкого профиля, а не нужно ли их готовить массово. Но раз автор упомянул, то я не смог пройти мимо.
"Когда в руках молоток - всё вокруг кажется гвоздями"
"На скольких языках вы пишите продакшен код?"
На скольки пишут в компании, в комании в моем проекте, я пишу в компании, я пишу включая пет-проекты? Scala 2 и 3 - один язык или два?
Не соглашусь с тезисами в статье, во всяком случае для карьеры пользы мало. Долгое время работал в аутсорсе из-за чего постоянно приходилось "бежать" за рынком: из iOS Objective-C в Java Android, из Java Android в iOS Swift, оттуда в ReactNative, затем в Node JS, пока, наконец не ушел в продуктовую компанию писать микросервисы. При переходе между стеками, рост "вширь" не ощущается, т.к. пока осваиваешь новые технологии, старые быстро забываются, и ценность твоей экспертизы не растет на рынке. Чего нельзя сказать о программах, которые расли вертикально, развиваясь в пределах одного стека - у них и экспертиза становилась глубже и тайтлы выше.
Не могу представить чего такого есть в rails и нет например в Java spring? Пример с реакт не показателен, т к и в rails не реакт, а наверняка шаблоны, аналогичные jsf (я не знаком с rails, но предвзят, потому что как раз где-то на рубеже 2014-го пришлось иметь дело с легаси на rails. "Повеселился" тогда, больше не хочу 😁
На Го смотрю, как на современный улучшенный PHP. Да, лучше, да быстрее, да, поддержка асинхронного программирования выполнена очень правильно архитектурно. Но главный минус - язык развивается стихийно (посмотрите как "вкорячили" дженерики туда, "картина маслом") и это гугл, а у них вечная проблема с языками, они "прокляты" у них 😁.
Насчёт монокультуры, я согласен, что надо язык и платформу брать под задачу, но с другой стороны, когда все пишут в целом однотипные веб-сервисы, то и инструменты должны быть стандартизированы вплоть до ide.
Не понимаю, на кой черт маленькой организации брать что-то типа rails или, упаси господь, ml, clojure или тем более хаскеля? Зачем плыть против "течения" то? Неужели готовить своих людей выгоднее чем взять студента лабающего на VB.NET? (Ну ладно, я утрирую, но на том же c# или Java) Не уж то скорость разборки серьёзного приложения для продакшена настолько больше на rails ？ Ну не верю я. Потому что написать код - это 10% работы. А эти все "рэилсы" именно этот аспект ускоряют. К тому же вот вы выучили человека, а он взял и сбежал в большую компанию разбирать легаси код на этом "чудо"-инструменте, т к там зп выше, а вы столько платить не можете (сами же говорите по городу начали появляться конторы использующие тот же стек. Это ж они не сами начали, а люди прошедшие через вас их стали открывать) А зачем? Выигрыш тут в чем? Даже если отвлечься от денежной составляющей, по сути ничего прогрессивного в этом "рэилс" нет - это инструмент быстрой разработки, коих было сотни и все они канули в лету. В качестве шутливого прогноза могу предположить, что в какой то момент Кобол обгонит рэилс, т к он более широко использовался в своё время и легаси на нём будет больше 😁
Что бы иметь представление что есть в rails и чего нет в Java наверное надо получить не маленький опыт на Rails и Java Spring что бы сравнивать.
Но в rails из коробки идет очень много простых инструментов разработки.
Например система миграций в Rails, простая и понятная, легко накатить и откатить в БД изменения. Система роутов очень простая и понятная.
Архитектура Rails построена так, что приложения делаются простыми и понятными.
Rails очень простой и подходит для разных проектов и он подходит для маленьких организаций, потому что все приложение rails может тянуть один разработчик.
Я не знаю как объяснить, что Rails это самый простой из всех инструментов что я видел для разработки веб-приложений.
Пока вы сами не попробуете поиметь на нем опыт около года, то на вряд ли поймете.
Либо нужна очень длинная статья об этом.
Одни говорят что надо учить и совершенствоваться в одном языке, другие что надо учить все языки.
Я согласен с первыми, потому что если учить много языков, то высокого уровня знаний технологий и самих языков не достичь и эффективность такого программиста будет очень низкой, да и до кучи ведет к выгоранию.
По мимо языков нужно к ним учить их экосистемы, языки в основном сами по себе не сложные.
Но обстоятельства вынуждают учить много языков, потому что компании "ресктруктурируются" и требуют, что бы сотрудник брал на себя больше задач и других технологий.
Что бы сотрудник замещал собой целый оркестр. Это тупой но дешевый подход.
В этом ничего хорошего нет.
Монокультура в программировании