Комментарии 22
We do what we must
Because we can
Because we can
Do what you can and be what will be
Так как увольнять специалистов по $ЗАУРЯДНЫЙ_ЯЗЫК увольнять дорого и жалко, а специалистов по @МОДНЫЙ_ЯЗЫК и $РАСКРУЧЕННАЯ_ТЕХНОЛОГИЯ нанимать еще дороже и дольше, то наш новый сайт на $МОДНЫЙ_ЯЗЫК написан спецами по $ЗАУРЯДНЫЙ_ЯЗЫК через жопу и мы нихера не понимаем что происходит
Требует редактуры в части они/мы, но в целом весьма забавно!
После перехода на $МОДНЫЙ_ЯЗЫК и $РАСКРУЧЕННУЮ_ТЕХНОЛОГИЮ наши специалисты конечно же не смогли сразу осилить все их тонкости и нюансы, потому нам пришлось увеличить ресурсы наших серверов в 3 раза чтобы достичь прежней производительности. Но мы уже работаем над оптимизацией и рефакторингом нагенерируемого кода и в планах достигнем производительности $ЗАУРЯДНОГО_ЯЗЫКА через год, а затем даже обгоним его.
P.S. Или найдем новый $МОДНЫЙ_ЯЗЫК и $РАСКРУЧЕННУЮ_ТЕХНОЛОГИЮ
P.S. Или найдем новый $МОДНЫЙ_ЯЗЫК и $РАСКРУЧЕННУЮ_ТЕХНОЛОГИЮ
Хехе, норм.
Интересно почитать (может даже кто-то из наших напишет) статью об изобретении $СВОЕГО_СОБСТВЕННОГО_ЭФФЕКТИВНОГО_РЕШЕНИЯ :)
С одной стороны — велосипед, а с другой — реакт, кликхаус, тарантул, нжинкс.
Интересно почитать (может даже кто-то из наших напишет) статью об изобретении $СВОЕГО_СОБСТВЕННОГО_ЭФФЕКТИВНОГО_РЕШЕНИЯ :)
С одной стороны — велосипед, а с другой — реакт, кликхаус, тарантул, нжинкс.
Я это сплагиачу! Я это обязательно буду использовать как основание, для топ менеджмента, о том, что технологический стэк нужно менять, и бабло восторжествует, независимо от уровня компетенции исполнителей.
Программирование эти люди уже практически похоронили, теперь и за системными администраторами потихоньку приходят. Раньше ты одну ОС учил 10 лет, а теперь каждый год нужно по 10 новых не имеющих аналогов в мире тулз изучать. И все как одна — с громкими названиями, красивыми сайтами и обещаниями, что ну вот в этот раз наверняка.
Единственное, кому это не мешает — это фронтенду. С самого появления этой специальности как отдельной специальности, у них иначе не было и в обозримое время не будет.
Единственное, кому это не мешает — это фронтенду. С самого появления этой специальности как отдельной специальности, у них иначе не было и в обозримое время не будет.
НЛО прилетело и опубликовало эту надпись здесь
Потому что это всё немодно.
Думаю, все кто непрерывно сидел внутри большого стэка, чувствуют себя отлично.
А тем, кто покидал его на время, а потом возвращался, с удивлением обнаруживал гору модных изменений в синтаксисе языка, новые модные инструменты и вакансии в духе «PHP / $frameworkName со стажем работы 2 года» (то есть недостаточно знать сам язык, надо знать и нюансы модного фреймворка, который на нём написан).
Т.е. изменения есть и там, они необязательно дурные сами по себе, однако требуют непрерывных инвестиций в освоение меняющейся области.
А тем, кто покидал его на время, а потом возвращался, с удивлением обнаруживал гору модных изменений в синтаксисе языка, новые модные инструменты и вакансии в духе «PHP / $frameworkName со стажем работы 2 года» (то есть недостаточно знать сам язык, надо знать и нюансы модного фреймворка, который на нём написан).
Т.е. изменения есть и там, они необязательно дурные сами по себе, однако требуют непрерывных инвестиций в освоение меняющейся области.
Да ладно. Что вы прикопались к эффективным менеджерам?!
Они работой заняты — бюджет осваивают.
<:o)
Они работой заняты — бюджет осваивают.
<:o)
Проблема в том, что они формируют рынок на самом деле. Про освоение бюджетов далеко не всегда так. Я видел как тот же самый Go начинал использоваться тем, где в нём по большому счёту особого смысла не было. Просто потому что он используется Google и позволил python-программистам легко въехать в hiload (на самом деле это было не так — сервис вышел очень слабый).
Для своего pet-проекта я сейчас использую Common Lisp, перед этим перепробовав множество вещей — от хайповых NodeJS, Dart и Elixir до узкоспециализированных Erlang и Racket. Остановился на Lisp-family не знаю почему. CL просто потому, что надоело делать патчи на базовые вещи в библиотеки для Racket. По сути — выкинул наработки на Racket (как до этого делал с другими языками) и начал сначала. Итог — начал использовать Woo (самый быстрый сервер, который я видел), освоил какую-то часть CL, проникся духом lisp-хакеров. Понравилось. Оглядываясь назад — да, всё это можно сделать на любом стеке, но мне удобнее Common Lisp.
А про модные стеки… есть нехорошая тенденция, которую можно проследить. Чаще всего популярными становятся примитивные инструменты с низким порогов вхождения и килотоннами денег затрат потом. Т.к. никто не пытается при выборе стека вот прям решить задачу, которая стоит. Так в своё время я принимал участие в проекте разработки мобильной версии сайта на Ember, который переписали на React в итоге. И знаете почему? Сверстал компоненты «эффективный тимлид» очень быстро и он работал быстрее. А вот после обвязки логикой… всё стало очень печально. Скорость работы была ± такая же, а вот архитектуры нормальной не было.
Для своего pet-проекта я сейчас использую Common Lisp, перед этим перепробовав множество вещей — от хайповых NodeJS, Dart и Elixir до узкоспециализированных Erlang и Racket. Остановился на Lisp-family не знаю почему. CL просто потому, что надоело делать патчи на базовые вещи в библиотеки для Racket. По сути — выкинул наработки на Racket (как до этого делал с другими языками) и начал сначала. Итог — начал использовать Woo (самый быстрый сервер, который я видел), освоил какую-то часть CL, проникся духом lisp-хакеров. Понравилось. Оглядываясь назад — да, всё это можно сделать на любом стеке, но мне удобнее Common Lisp.
А про модные стеки… есть нехорошая тенденция, которую можно проследить. Чаще всего популярными становятся примитивные инструменты с низким порогов вхождения и килотоннами денег затрат потом. Т.к. никто не пытается при выборе стека вот прям решить задачу, которая стоит. Так в своё время я принимал участие в проекте разработки мобильной версии сайта на Ember, который переписали на React в итоге. И знаете почему? Сверстал компоненты «эффективный тимлид» очень быстро и он работал быстрее. А вот после обвязки логикой… всё стало очень печально. Скорость работы была ± такая же, а вот архитектуры нормальной не было.
Любая смена ЯП/фреймворка/технологии и т.д. бесплатно не делается.
Для этого нужны ресурсы.
Вот у вас есть система, которая работает. Есть особо не просит. нагрузка стабилизировалась, т.к. расширения бизнеса растет очень медленно.
И тут у топ-топ менеджеров может возникнуть вопрос — «Зачем нам столько программистов, да и весь департамент?».
Чтобы «предупредить» такие вопросы, нужны «новые проекты». А т.к. новое придумать и сделать сложно, то начинают переделывать старое.
Ну а хайп и все остальное, это всего лишь «экономическое обоснование». ;-)
Для этого нужны ресурсы.
Вот у вас есть система, которая работает. Есть особо не просит. нагрузка стабилизировалась, т.к. расширения бизнеса растет очень медленно.
И тут у топ-топ менеджеров может возникнуть вопрос — «Зачем нам столько программистов, да и весь департамент?».
Чтобы «предупредить» такие вопросы, нужны «новые проекты». А т.к. новое придумать и сделать сложно, то начинают переделывать старое.
Ну а хайп и все остальное, это всего лишь «экономическое обоснование». ;-)
Ну так классика:
Ничего не поменялось
Но другая группа ... нашла ... фатальный недостаток – его писали не они!
Ничего не поменялось
Сначала прочитал Hope Driven Development.
… Это всё фигня. Наше приложение было написано на разумном выборе для 1963 года (COBOL) с использованием разумных технологий (база данных кобола на ленточном накопителе).
С тех пор приложение было провело транзаций на 2147483647 * 1.232323e5 долларов (счётчик денег не поддерживает больше 2147483647 долларов, так что мы добавили специальный код для умножения максимального значения на DOUBLE). Я не понимаю, почему мы должны переходить на любую из недавних [1964-2020] новомодных технологий. Наш ведущий инженер всё ещё может самостоятельно поднести ложку ко рту с третьей-пятой попытки, так что мы отвергаем идею bangwagon hype driven переписывания чего-либо.
Алсо, у нас открыты вакансии COBOL-разработчиков. Мы обновляли список требований там последний раз совсем недавно (в 1991 году), так что если вы хорошо знаете COBOL-60, то добро пожаловать.
А ЕСЛИ ВЫ АПОЛОГЕТ ALGOL-58 ТО МЫ ВАС НЕ ХОТИМ ВИДЕТЬ.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему мы в $ИЗВЕСТНОЙ_КОМПАНИИ перешли на $РАСКРУЧЕННУЮ_ТЕХНОЛОГИЮ