Comments 144
В мои 20 лет любое малейшее предположение о необходимости дополнительной работы привело бы к тому, что я провёл бы 24-часовой марафон кодирования. Или работал бы в выходные.
Реальный мир. Я лет 10 назад стал задумываться об возрастных ограничениях в некоторых вакансиях. Тогда закралась мысль, что опытным людям работодателю сложнее морочить голову обещаниями.
Статья сама по себе прекрасна, но лучше читать ее в оригинале.
мы должны «прикоснуться к базе в оффлайне».vs
we should «touch base offline»
нужно сделать некоторые «правильные размеры»vs
we need to do some «right-sizing»
Я действительно возненавидел эту непрекращающуюся потребность поддерживать неприятные идеи в какой-то расплывчатой форме «новой речи».
vs
I could go on, but you get the point. I've really grown to hate this incessant need to doctor distasteful ideas in some vague form of New Speak.
Тут, видимо, подразумевалась "необходимость смягчать неприятные идеи расплывчатым новоязом". Вообще, должен признать, машинный перевод далеко шагнул.
"touch base" видимо специально перевели дословно, но эта идиома изначально пришла из бейсбола, она не имеет отношения к базам данных.
Ага, только в таком дословном виде она совершенно не понятна русскоязычным.
Touch base offlineТо есть речь идет о необходимости переговоров при личной встрече.
This one is the most hated bits of jargon of all time. It means let’s meet and talk.
Программисты в этом не уникальны. Так почти в любой профессии. С возрастом пропадает желание "быть частью команды" за печеньки и кофемашину, вместо этого появляется здоровая меркантильность. С возрастом вырабатывается скептическое отношение к новинкам, потому что в прошлом опыте этих новинок было слишком много и каждая из этих новинок обещала изменить рынок. Обо всём этом и говорил Писатель в "Сталкере" Тарковского.
Все по кругу. Это так.
Как говАривал опытный Россини начинающим композиторам: интересное у вас не ново, а новое не интересно.
Я уже тоже с 10 ок лет смотрю на всю эту вакханалию. Если раньше получение каких либо знаний было сопряжено с усилиями поиска книг, статей и тд, их прочтения и проб, то сейчас одни онлайн курсы и прочие видосики. Самое хорошее имхо уже стать нештатным консультантом. А если хочешь писать код и что то новое изучать — заведи хобби из параллельной области. Например микроконтроллеры программируй.
Например микроконтроллеры программируй.
Мне кажется, одна из самых консервативных сфер. Выучил Си, на крайний случай Си++ и кодишь до кон а жизни. Ну и ассемблера немношк, ну для общего развития.
да, или можно написать бота для той игры, которая интересна, но в силу старости не стать киберспортсменом, например, старкрафт )
UFO just landed and posted this here
Ну что же… Этот «я» станет сам постарше и тогда в соответствии с его теперешними представлениями ему останется тихо отойти в сторону
Смех конечно…
Отчасти это проистекает из ремесленности современного IT. Есть очень большое количествосортов гранита, добываемого в разных местах средств, фреймворков и прочего. Только находясь в относительно молодом возрасте можно с удовольствием в этом рыться. Потом приходит понимание, что это, говоря современным жаргоном, неимоверный оверхед.
Смех конечно…
Отчасти это проистекает из ремесленности современного IT. Есть очень большое количество
Я бы назвал это не оверхедом, а несколько иначе — с возрастом начинаешь больше ценить время.
Любой фреймворк (язык программирования, IDE, etc) требует времени на изучение и приобретение опыта работы с ним. Но быстротечность современных технологий такова, что пока осваиваешься с одним фреймворком, ему на смену уже идет другой. В результате ты, потратив немало времени на изучение предыдущего фреймворка, не успеваешь его применить для достижения конкретных практических целей (business value). Потому что вынужден снова тратить время на изучение нового фреймворка (языка программирования, IDE, etc).
Так и проходит жизнь — в бесконечном обучении. Вместо практической пользы от полученных знаний, ты вынужден вновь и вновь учиться.
С годами человек становится мудрее. И всё отчетливее начинает понимать, что деньги можно заработать, здоровье поправить, а вот время уходит безвозвратно. Поэтому и начинаешь ценить его больше всего.
Я не против саморазвития как такового. Но, как и в других областях, о доле здорового консерватизма здесь забывать не стоит.
«Мера должна быть во всем.» — Гораций
Любой фреймворк (язык программирования, IDE, etc) требует времени на изучение и приобретение опыта работы с ним. Но быстротечность современных технологий такова, что пока осваиваешься с одним фреймворком, ему на смену уже идет другой. В результате ты, потратив немало времени на изучение предыдущего фреймворка, не успеваешь его применить для достижения конкретных практических целей (business value). Потому что вынужден снова тратить время на изучение нового фреймворка (языка программирования, IDE, etc).
Так и проходит жизнь — в бесконечном обучении. Вместо практической пользы от полученных знаний, ты вынужден вновь и вновь учиться.
С годами человек становится мудрее. И всё отчетливее начинает понимать, что деньги можно заработать, здоровье поправить, а вот время уходит безвозвратно. Поэтому и начинаешь ценить его больше всего.
Я не против саморазвития как такового. Но, как и в других областях, о доле здорового консерватизма здесь забывать не стоит.
«Мера должна быть во всем.» — Гораций
С возрастом время течёт субъективно быстрее.
Чисто из айтишных наблюдений — релизы убунты.
Раньше с энтузиазмом ставил и осваивал каждый новый релиз.
А нынче поставил свежий LTS, не успел глазом моргнуть — уже вышел следующий, а затем текущий (так до конца и не освоенный) уже потерял поддержку...
Эх, молодежь! В моей молодости про убунту и не слышали. Это были релизы RedHat Linux. :-)
Да всякое было. Просто на модемном интернете в молодости нужно было много терпения. А так — и Alt Linux, и Mandrake ставший позднее Mandriva, и OpenSuse — чего только не было… А потом вдруг замаячила убунта, которую не надо было скачивать; достаточно было оставить заявку и совершенно бесплатно присылали полсотни дисков обычной почтой (полсотни — это чтоб друзьям раздать). Правда, и работала она с русской локалью как-то не очень...
У меня начиналось с локализации Red Hat — Красная Шапочка
https://www.go-electronic.com/?p=627
https://www.go-electronic.com/?p=627
UFO just landed and posted this here
Там какой-то несерьёзный текст. Но иногда бывает такое мнение, когда позиционируют себя как «мы — молодой коллектив, средний возраст сотрудников — 30 лет» и начинается трансформация в «геймификации, ачивки и мемчики». Становится стыдно работать.
Мне уже за 60. Ещё в 45, когда меня позвали в новый большой проект, я пошёл с условием, что программировать — не буду. И не ошибся. Не то, чтобы мне не хотелось программлять (потому скрипты для себя пишу, но сугубо для себя), но понимание того, что эту работу молодые сделают быстрее и лучше, только крепло со временем. А, раз так — лучше уйти из этой ниши.
К счастью, проект относится к реальности, не внутри-айтишный, так что сейчас уже третье поколение проекта, и как-то я в нём живу. Обнаружилось, что понимание предметной области, с одной стороны, и понимание людей как юзеров, с другой — вполне себе ценность. Так что как непосредственный проектировщик (не верхнеуровные картинки, а именно «как это сделать») — пока лучше окружающих, а то бы и это бросил. Плюс как менеджер невысокого (к счастью) уровня лучше понимаю, кому именно какую работу дать с учётом не столько даже квалификации, а характера.
Кроме того, сугубо программисткие навыки на удивление константны. Молодые программеры, освоив (признаюсь, уже недоступные мне) технологии, часто упускают банальности, что ведёт к отдалённым неприятным последствиям. Так что мои осторожные (не хочется всё же выглядеть идиотом-старпёром) советы иногда воспринимаются как открытие :-)
К счастью, проект относится к реальности, не внутри-айтишный, так что сейчас уже третье поколение проекта, и как-то я в нём живу. Обнаружилось, что понимание предметной области, с одной стороны, и понимание людей как юзеров, с другой — вполне себе ценность. Так что как непосредственный проектировщик (не верхнеуровные картинки, а именно «как это сделать») — пока лучше окружающих, а то бы и это бросил. Плюс как менеджер невысокого (к счастью) уровня лучше понимаю, кому именно какую работу дать с учётом не столько даже квалификации, а характера.
Кроме того, сугубо программисткие навыки на удивление константны. Молодые программеры, освоив (признаюсь, уже недоступные мне) технологии, часто упускают банальности, что ведёт к отдалённым неприятным последствиям. Так что мои осторожные (не хочется всё же выглядеть идиотом-старпёром) советы иногда воспринимаются как открытие :-)
>понимание того, что эту работу молодые сделают быстрее и лучше
А я вот продолжаю. И могу пока что четко сказать, что нет, не делают — ни быстрее, ни лучше. Ну или так — синьоры, которым самим скажем под 40, возможно делают, но не всегда. А молодежь — чаще нет, чем да. Это в общем ничего не значит, кроме того, что бывает по-разному.
>понимание предметной области, с одной стороны, и понимание людей как юзеров
Это понимание совершенно не мешает попутно кодить. И умение проектировать тоже.
Впрочем, если бы я сейчас точно понимал, что в текущем проекте смогу бросить ежедневную рутину — и было бы кому ее отдать, наверное отдал бы. Но для этого сначала нужно собрать или вырастить команду.
А я вот продолжаю. И могу пока что четко сказать, что нет, не делают — ни быстрее, ни лучше. Ну или так — синьоры, которым самим скажем под 40, возможно делают, но не всегда. А молодежь — чаще нет, чем да. Это в общем ничего не значит, кроме того, что бывает по-разному.
>понимание предметной области, с одной стороны, и понимание людей как юзеров
Это понимание совершенно не мешает попутно кодить. И умение проектировать тоже.
Впрочем, если бы я сейчас точно понимал, что в текущем проекте смогу бросить ежедневную рутину — и было бы кому ее отдать, наверное отдал бы. Но для этого сначала нужно собрать или вырастить команду.
эту работу молодые сделают быстрее и лучше,
40+. "Быстрее" — может быть. "Лучше" — хммммм… Если под "лучше" понимается "с такими дырками в безопасности, что шагающий экскаватор пройдёт", то таки да. Потому что молодежь считает, что "программа готова, когда она делает то, что сказали", а то, что правильный критерий — это "программа НЕ делает того, что НЕ сказали" — это им надо долго и упорно вдалбливать. Потому и имем дырявые Госуслуги, дырявые гуглмапс, постоянные глюки с Убером/Яндекс.такси/и т.п. (буквально вчера пинался с ними на тему привязки карты: банк говорит "у нас всё нормально, звоните в Я.т", в Я.т говорят "у нас всё нормально, звоните в банк", так ни к чему и не пришли).
Вы как-то уж очень в гуманитарную область переводите, в эмоции. Я не готов так обсуждать.
Простите, чисто ради интереса — Вы случайно не миллениал? Просто это весьма характерный "страусиный" подход вида "ой, мне это не нравится, поэтому закрою глаза и буду делать вид, что этого не существует". Позвольте развеять розовые мечты: открыты ли глаза, закрыты ли — на существование проблем не влияет от слова "никак"; на (не)существование проблем влияют исключительно целеноправленно приложенные усилия по их разрешению.
По моему опыту — Один опытный солдат стоит трех новобранцев, если считать вместе и soft и hard скиллы, а небольшое замедление умственных способностей с возрастом с лихвой компенсируется опытом
Во-первых, как я уже писал — это очень личное, у каждого процесс идёт по-своему.
Во-вторых, в действительно сложных задачах реализация опыта занимает настолько много времени, что собственно кодирование бывает лучше переложить на «молодых и рьяных», и без того есть, чем заняться. Лучше не один или трое, а команда. И в команде лидеру собственное программление мешает реализовывать опыт через других. ПОтому как через других — труднее, и подсознательно человек прячется, «у меня есть собственные срочные задания, вот сейчас их добью — и займусь остальными».
И, в третьих, снова повторюсь: в разных областях по-разному. В чисто ITшных задачах «внешний» опыт значит меньше, если же задача соприкасается с реальностью — гораздо больше.
Во-вторых, в действительно сложных задачах реализация опыта занимает настолько много времени, что собственно кодирование бывает лучше переложить на «молодых и рьяных», и без того есть, чем заняться. Лучше не один или трое, а команда. И в команде лидеру собственное программление мешает реализовывать опыт через других. ПОтому как через других — труднее, и подсознательно человек прячется, «у меня есть собственные срочные задания, вот сейчас их добью — и займусь остальными».
И, в третьих, снова повторюсь: в разных областях по-разному. В чисто ITшных задачах «внешний» опыт значит меньше, если же задача соприкасается с реальностью — гораздо больше.
в действительно сложных задачах реализация опыта занимает настолько много времени, что собственно кодирование бывает лучше переложить на «молодых и рьяных»
Увы, не всегда возможно. В большинстве случаев такое перекладывание выльется в то, что просто будешь сидеть рядом с молодым и пошагово ему объяснять что где и как делать. Тут проще сделать самому.
Сам сейчас в подобной ситуации — молодых в команде много, но опытных разработчиков, способных решать действительно сложные задачи, по пальцам одной руки пересчитать. В результате молодые пока занимаются рутиной, а все сложное отдается опытным. И часто это выливается в сильный напряг — сам последние две недели просидел на шестидневке по 12 часов в день потому что было две достаточно сложных задачи и очень жесткими дедлайнами. И больше было просто некому их делать.
Сам всю жизнь занимался бэкендом на уровне системных апи. Т.е. никаких фреймворков. В 52 резко поменял и предметную область и платформу (очень специфическую, совершенно непохожую на то, с чем имел дело раньше) и основной язык разработки. Было очень тяжело, но справился. И даже смог трансформировать значительную часть накопленного опыта под новые условия.
Убедился что опыт разработчика достаточно универсален и накопленное водной области вполне может найти применение в другой. И на одном энтузиазме далеко не уедешь.
К фреймворкам отношусь… В своей области достаточно скептически. Где-то «наверху» оно наверное и помогает. Но хорошо сделать «низ», на который все опирается, чтобы он эффективно работал и выдерживал большую нагрузку — тут надо понимать основы работы той платформы, на которой этот «низ» установлен. И уметь эффективно ее использовать.
Фактически мы разрабатываем те самые «фреймворки» для среднего и высокого уровня.
Увы, не всегда возможно. В большинстве случаев такое перекладывание выльется в то, что просто будешь сидеть рядом с молодым и пошагово ему объяснять что где и как делать. Тут проще сделать самому.Ровно то, о чём я и писал — программеру-лидеру мешает организовать работу то, что «легче сделать самому».
Для того и полезен (в моём случае, надеюсь) лидер, не занимающийся непосредственным кодированием. Он должен и задачу группе поставить, и организовать процесс подтягивания «молодых» так, чтобы это не мешало общему темпу.
всю жизнь занимался бэкендом на уровне системных апиЧуть ли не самая простая область, повезло :-) Простая в смысле внешних условий, главное — собственно свою часть сделать хорошо (что, конечно, не так просто).
Вообще сугубо IT-шные вещи меньше сталкиваются с реальной жизнью и потому гораздо проще и красивее устроены.
опыт разработчика достаточно универсаленМожете нам набросать модуль быстрой динамики для энергосистем? Всего-то нужно пару сотен тысяч разных (типов силового оборудования не один, да разных автоматик с сотню типов учесть) дифуров считать в темпе реального времени.
Для того и полезен (в моём случае, надеюсь) лидер, не занимающийся непосредственным кодированием.
Это все есть. Есть аналитики, есть руководители направлений… Но когда дело доходит до распределения задач, все упирается в тот же вопрос — «а кто способен решить данную задачу качественно и в срок»?
Чуть ли не самая простая область, повезло :-) Простая в смысле внешних условий, главное — собственно свою часть сделать хорошо (что, конечно, не так просто).
Тут просто сложности специфические. Кажется что все просто — ну нужно организовать распределенную обработку большого объема данных. Казалось бы чего проще — раздели данные на блоки и раздай обработчикам, пусть себе молотят.
А дальше начинаются тонкости — а как именно делить? По какому признаку делить? А что будет если в одном блоке данные обработаются быстрее чем в другом? А как обеспечить самобалансирующуюся загрузку обработчиков, как их контролировать, как обеспечить 100% гарантию обработки всех данных, если кто-то из обработчиков выпал в ошибку? Там мильен мелких тонкостей и особенностей реализации и половина из них будет зависеть от возможностей платформы, от того, гомогенная система или нет, от того, работает все это в рамках одного мейнфрейма или это гетерогенная распределенная система… В каждом случае будет свои подходы и свои особенности реализации.
Можете нам набросать модуль быстрой динамики для энергосистем? Всего-то нужно пару сотен тысяч разных (типов силового оборудования не один, да разных автоматик с сотню типов учесть) дифуров считать в темпе реального времени.
А вот это уже не совсем IT. Это уже комплекс, требующий знания предметной области.
Вам, к примеру, что-то говорит «6-12 ЛД»? :-) А я когда-то давно этим занимался… Молекулярная динамика, машинное моделирование, потенциалы взаимодействия, эффективное сечение рассеяния и т.п. Чтобы этим заниматься нужно еще на минуточку знать курс матанализа, дифуров, уравнений матфизики, статфизику, механику сплошных сред, термодинамику… И поверх всего этого быть еще неплохим разработчиком, умеющим писать быстрый и эффективный код.
Но я о задачах чисто разработки. Что выбрать для построения батчмашины? Сокеты? Пайпы? *DTAQ? В каком случае что будет лучше работать скажем, на платформе AS/400? Что должна делать головная задача, а что отдать на откуп обработчикам? Еще держать в голове, что хотелки заказчика могут поменяться через год (только что с этим столкнулся — то, что удовлетворительно работало несколько лет, начало работать очень плохо после того, как заказчик захотел расширить набор обрабатываемых данных новыми сущностями, а изначальная архитектура задачи оказалась слишком жесткой для такого расширения и все пошло по не так) и нужно сразу закладывать на будущее такую архитектуру, которая предоставит возможности расширения без существенного переписывания кода (ну скажем, меняем только схему обработки одного кванта данных, или меняем только схему отбора квантов из общей кучи, но не меняем способ сбалансированного распределения кантов по обработчикам и систему контроля обработчиков и сохранения целостности данных).
И еще приходится помнить что есть эффективность выполнения нашей задачи и есть еще несколько тысяч других задач, которые тоже в это же время выполняются на это же мейнфрейме и тоже обязаны получит свой кусочек машинного времени — нужно искать баланс между скоростью выполнения и объемом используемых ресурсов. А оптимально — иметь возможность регулировать этот объем хотя бы внешними настройками, меняющимися от запуска к запуску…
Тут очень много вещей, которые нужно держать в голове. Сейчас я с некоторой ностальгией вспоминаю прошлые задачи, где я знал, что моя задача (пусть и работающая в условиях гарантированного времени отклика) была основной и могла брать столько ресурсов, сколько ей нужно. И где можно было сосредоточится только на «быстро», а не балансировать на лезвии между «быстро» и «экономно».
Это все есть. Есть аналитики, есть руководители направлений…Нет, эти слишком отчуждены от разработчиков. Нужен свой, как рулевой в лодке. Не гребёт — но сидит там же и за конкретную лодку отвечает вместе (и больше) с коллективом. Даже картинку вставлю:
А вот это уже не совсем IT. Это уже комплекс, требующий знания предметной области.Именно! В таких областях роль «рулевого» гораздо выше. В чисто айтишных можно без него и обойтись (привлекая образ лодки — и такие есть, парные четвёрки, например, рулит один из гребцов), потому что «очень много вещей, которые нужно держать в голове» — общие для всей команды.
Но — это всё разнится в разных областях, моей — так, в Вашей — эдак. Это не хорошо и не плохо, а просто вот так.
Нет, эти слишком отчуждены от разработчиков. Нужен свой, как рулевой в лодке.
А вот это где как. У нас связка аналитик-разработчик очень плотная. Работа идет в паре и как аналитик может советоваться с разработчиком по поводу архитектуры задачи, так и разработчик советуется с аналитиком по поводу тонкостей реализации тех или иных алгоритмов. Аналитик ближе к предметной области, разработчик — к платформе на которой все это реализуется.
Именно! В таких областях роль «рулевого» гораздо выше. В чисто айтишных можно без него и обойтись, потому что «очень много вещей, которые нужно держать в голове» — общие для всей команды.
Ну чисто айтишных команд я не видел (которые выдавали бы эффективный и востребованный продукт). Это примерно как «а вот напишем-ка вот такую фигню — мы не знает кому и зачем это нужно, просто вот на м в голову ударило. Это провальная позиция — такой продукт на 100% будет неудобен для пользователя т.к. он не учитывает его текущие потребности и не встраивается в его бизнес-процессы.
Любая команда разрабатывает тот продукт, на который есть спрос (на него может не быть конкретного заказа, но неудовлетворенный спрос уже есть). И в любом случае разработка идет от спроса.
Поэтому аналитик должен быть всегда. Тот, кто вникает в потребности потенциального или реального заказчика, его бизнес-процессы и разрабатывает концепцию. А дальше уже вместе с разработчиком разрабатывает конкретную архитектуру и алгоритмы.
Тут возможны вариации в распределении обязанностей, но общая схема примерно такова.
Да, есть тимлиды, техлиды, архитекторы. Но они занимаются больше распределением задач по команде, кодревью, отвечают за репозитории в гите… С архитекторами можно обсуждать какие-то чисто технические решения (типа той же многопоточной параллельной обработки данных или какихто сложных вопросов эффективности тех или иных решений т.п.) Но предметная область — это всегда аналитики.
Но — это всё разнится в разных областях, моей — так, в Вашей — эдак. Это не хорошо и не плохо, а просто вот так.
Да, согласен.
Мне 57, и я фрилансер DevOps. Все больше последние годы чувствую желание уйти от hands-on, но увы — боязно искать и нанимать команду.
Мне просто повезло. Сам работал удалённо с американцами. Правда, последние годы уже не фрилансером. Фрилансерство мне вообще не по характеру, даётся тяжело и невыгодно. Работал постоянно в приличной конторе, неплохой проект, неплохая зарплата…
Пока однажды вечером ко мне домой не ввалилась весёлая поддатая компания и позвала в новый проект. Куда с удовольствием, несмотря на двукратную потерю в зарплате, и ломанулся. Повезло.
Пока однажды вечером ко мне домой не ввалилась весёлая поддатая компания и позвала в новый проект. Куда с удовольствием, несмотря на двукратную потерю в зарплате, и ломанулся. Повезло.
Рад за вас. Я как раз счастлив быть фрилансером — не нужно участвовать в политике, можно работать неполную ставку. У меня есть 1-2 постоянных заказчика на пару дней в неделю каждый.
Но вот гоняться за технологиями я устал, да и скучно 90% быть hands-on.
Но вот гоняться за технологиями я устал, да и скучно 90% быть hands-on.
Мне повезло ещё больше!
не нужно участвовать в политикеУ нас небольшая частная компания, нет множества этажей управления, соответственно и политики практически нет. Плюс у меня табельный номер 3, и политика мало меня касается.
счастлив быть фрилансеромЭто от характера зависит. Мне — никогда не нравилось, ни 20 лет назад, ни тем более сейчас.
гоняться за технологиями я усталопять же, у нас продукт привязан к реальной жизни и бешеная смена it-поколений нас задевает только косвенно. Какое-то количество молодых набираем постоянно, этого достаточно.
хорошая статья, а вот перевод стоило-бы «причесать»
Все в точку, вижу все то же самое в каждой новой конторе.
С моей точки зрения с возрастом приходит лучшее понимание людей, и из-за этого возникают описанные проблемы, например к тебе приходит заказчик(начальник, сосед, да кто угодно) и просит тебя сделать что-то, ты видишь что с технической точки зрения это глупость(ошибка, неправильность) но также видишь что ему на это наплевать, ему нужно выделиться(подстраховаться, настоять на своем, подставить кого-то), но прямо сказать — это серьезный конфликт, и приходится тыкать носом в технические вопросы человека которому это безразлично, ему то важно совсем другое. И здесь ты либо овладеваешь помимо своей компетенции еще и навыками практической психологии, либо действительно прослывешь старым дураком. А практическая психология ничуть не проще программирования или конструирования
А если человек хочет просто делать любимую работу, без корпоративных игрищ, которые отнимают кучу времени и нервов, и естественно никакого удовольствия не приносят? Или начальник, который со своими игрищами, пытается тобой манипулировать, и никаким win-win не пахнет? Т.е. делать вид, что не понимаешь и ждать, что на тебя вывалят ушат помоев в последствии, но зато ты будешь «свой»? Когда ты раз за разом выворачиваешься из подобных ситуаций, и начальник чувствует себя после этого дураком, то контракт быстро заканчивается.
Я с Вами согласен, я просто имел в виду, что для того, чтобы выкручиваться из подобных ситуаций без ущерба нужно овладеть еще одной компетенцией, а это во первых сложно а во вторых противно
Да. Я вашу мысль понял. И я не знаю как этому научится. Но я точно знаю, что если я буду этим заниматься, я буду тратить на «это» больше времени, чем на работу.
Спрашивается, зачем я пришёл на эту работу, если я ею не занимаюсь? Что я тут делаю?
Ситуация проигрышная как для нанимателя, так и для меня. Зато все кто хотел, поиграли в игру престолов, за счёт работодателя.
Спрашивается, зачем я пришёл на эту работу, если я ею не занимаюсь? Что я тут делаю?
Ситуация проигрышная как для нанимателя, так и для меня. Зато все кто хотел, поиграли в игру престолов, за счёт работодателя.
Возраст под полтинник, шесть лет опыта относительно по делу, некислая самооценка. Конечно, ему трудно.
Upd: и огромная любовь к словоизвержению.
Upd: и огромная любовь к словоизвержению.
так, вроде, человек прошелся по леснице вверх-вниз. А самооценка осталась соответственной верхней точке, как по мне, так правильно все…
Paradigm shift должен случаться не только при переходе на управленческую работу, но и при уходе с нее. Да и не знаем мы, прошелся он вниз, или по ступенькам на заднице слетел. По тону очень похоже, что слетел.
Кстати, в 20 лет он служил в ВВС техником по радарам, ну, или вольнонаемным был, так что лукавит он в статье.
Но пойнт мой в том, что от программиста в его возрасте (он же примерно мой возраст) обычно ждут чего-то большего, чем шестилетний опыт невнятного перебрасывания дерьмокода через забор и пятнадцатилетний опыт командования удаленными индусами. Ну и уж учителем жизни по собственной инициативе вообще не стоит становиться, при любой специальности. Просто продемонстрируй, что жил, а не небо коптил, и к тебе сами придут и попросят жизни научить.
Кстати, в 20 лет он служил в ВВС техником по радарам, ну, или вольнонаемным был, так что лукавит он в статье.
Но пойнт мой в том, что от программиста в его возрасте (он же примерно мой возраст) обычно ждут чего-то большего, чем шестилетний опыт невнятного перебрасывания дерьмокода через забор и пятнадцатилетний опыт командования удаленными индусами. Ну и уж учителем жизни по собственной инициативе вообще не стоит становиться, при любой специальности. Просто продемонстрируй, что жил, а не небо коптил, и к тебе сами придут и попросят жизни научить.
Опыт у всех разный но имхо он описал типичнейшую для индустрии ситуацию, все так и есть. острота индивидуальной реакции не делает неправдой все о чем он написал. Его вот раздражает, мне смешно, большинству пофиг. Не надо было ему уходить в individual contributors — как менеджер смог бы эффективней валенками на резинке швырятья в тех кто не так делает ).
Большинство людей не годится ни украсть, ни посторожить. В этом плане ситуация типичнейшая. Просто непонятно, возраст-то тут при чем?
А чувак, конечно, крайне любопытный в определенном смысле. Этнографическом. Ультралевый(на американский манер, конечно же). Думаю, большинство здесь присутствующих тоже показались бы ему антисемитами, женоненавистникам расистами :-) Но, опять же, возраст-то тут при чем?
А чувак, конечно, крайне любопытный в определенном смысле. Этнографическом. Ультралевый(на американский манер, конечно же). Думаю, большинство здесь присутствующих тоже показались бы ему антисемитами, женоненавистникам расистами :-) Но, опять же, возраст-то тут при чем?
В маркетинге ситуация 1:1.
Мне сейчас 38 и я понимаю, что хватит меня не долго, максимум до 45.
Ого! А можно примеры, как оно также в маркетинге?
Нет, я подозреваю, что процессы везде похожи, но как там это проявляется? Покупается ненужная реклама за кучу денег вместо нужной, но не такой пафосной?
Нет, я подозреваю, что процессы везде похожи, но как там это проявляется? Покупается ненужная реклама за кучу денег вместо нужной, но не такой пафосной?
Рекламные площадки Yandex и Google. Это и контекстная реклама и медийная и товарные предложения. Постоянно выходят обновления. Постоянно выходят платформы и сервисы, которые по идее должны упрощать управление рекламой, но в 90% являются шлаком. Но нужно потратить время на изучение сервиса, чтобы понять, что это шлак.
В том же Google одними только встроенными инструментами можно настроить автоматизацию так, чтобы та или иная реклама показывалась в зависимости от температуры на улице, идёт дождь или снег, либо рассвет или закат.
А ещё технологии сегментирования, локальный гипертаргетинг и много иной хрени, которая, например, в случае с Яндексом, нихрена не работает так, как должна работать.
Реклама в соцсетях: даже если взять основные: vk, face, insta, ok, то в них регулярно обновления. Куча дополнительных сервисов, инструментов, задача которых по идее упрощать работу с рекламой, а по факту 90% из них бестолковые.
В итоге, когда стоит задача настроить рекламу так, чтобы ROAS был свыше 100%, соответственно, нужно глубоко знать бизнес-процессы заказчика, его финансовые показатели и все вместе прикрутить с инструментами метрики, аналитики и рекламными каналами.
И тут возникает вопрос: использовать старые технологии, с которыми знаком, либо сунуться в изучение новых платформ, сервисов, технологий, которые в теории должны дать большую эффективность, позволить получить больше клиентов в рамках существующего бюджета, либо снизить расходы на рекламу, без снижения количества клиентов.
Показывать на сайте заказчика всем один и тот же контент, либо в зависимости от того, с какого рекламного канала пришёл пользователь, сколько ему лет, какого пола, какие интересы, показывать на одной и той же странице сайта другой контент?
А ещё есть технологии отслеживания на сайте пользователя, выявление его потребностей и на следующей странице сайта показывать ему в дополнительных блоках те товары/услуги, которые могут его заинтересовать. Сделать так, чтобы куда бы он ни сунулся в интернете, ему показывались те товары/услуги, которые он потенциально может приобрести.
И если ещё лет 8-10 назад ещё можно было быть универсальным маркетологом, умеющим хорошо работать со всеми каналами интернет-рекламы, то сейчас это уже в принципе невозможно, так же, как и быть универсальным программистом.
И когда кто-то меня спрашивает, чем я занимаюсь, а я отвечаю: «маркетолог», а человек тут же мне задаёт вопрос:
«- а, инстаграм ведёшь?»,
хочется прибить человека нафиг!)
И если ещё лет 8-10 назад ещё можно было быть универсальным маркетологом, умеющим хорошо работать со всеми каналами интернет-рекламы, то сейчас это уже в принципе невозможно, так же, как и быть универсальным программистом.
Не согласен: считаю что универсальным программистом быть возможно.
считаю что универсальным программистом быть возможно.
Уверены?
Вот лично вы что пишете? И на чем?
Допустим, писали всю жизнь фронт на модных фреймворках. Сколько времени вам потребуется чтобы выйти на тот же уровень, но в какой-нибудь промавтоматизации чтобы писать на С/С++ что-то низкоуровневое на уровне OS API?
Или забросила жизнь в мир мейнфреймов — IBM i/IBM z, CL/RPG и т.п…
Про программирование всяких микроконтроллеров где еще и в железе надо неплохо ориентироваться уж молчу.
И куча специфических областей — нейросети, машинное зрение, гд кроме собственно программирования еще математика требуется.
Так что насчет «универсального программиста» не согласен. Да, перейти из одной области в другую вполне возможно. Но это потребует некоторого времени (несколько месяцев, год...) для выхода на тот же уровень, который был в предыдущей области.
Представьте прекрасный мир, в котором для того чтобы пересесть с написания вебфронта на промавтоматику или микроконтроллеры не нужно менять ваш основной ЯП. Представили? Согласитесь, теперь «невозможность существования универсального программиста» уже не выглядит столь однозначно?
Думаю, примерно к этому индустрия и придёт вместо специализации на железе и среде. Потому что обучение программиста слишком дорого обходится чтобы складывать все яйца в одну нишевую «корзину».
Думаю, примерно к этому индустрия и придёт вместо специализации на железе и среде. Потому что обучение программиста слишком дорого обходится чтобы складывать все яйца в одну нишевую «корзину».
Представьте прекрасный мир, в котором для того чтобы пересесть с написания вебфронта на промавтоматику или микроконтроллеры не нужно менять ваш основной ЯП. Представили?
Не могу такого себе представить. Ибо работал в близкой к промавтоматике области (распределенная система мониторинга инженерного оборудования заданий), а сейчас работаю в бэкенде финтеха на уровне ядровых функций АБС на мейнфрейме IBM PowerS9 на платформе IBM i.
Это настолько разные миры. Там все разное. И требования очень разные. В той же промавтоматике вы не напишете верхний уровень (интерфейсные клиенты) на голом С, но и при этом не запихнете модные фреймворки в промконтроллер на STM32 (который очень ограничен по памяти и процессору, ставить туда что-то мощное — цена на систему взлетит до небес или даже в нашей не очень большой системе количество промконтроллеров измерялась тысячами, в более развитых системах это десятки и сотни тысяч узлов и даже экономия в стоимости одного узла на 5-10 долларов уже очень ощутимо сказывается на цене всей системы).
Думаю, примерно к этому индустрия и придёт вместо специализации на железе и среде. Потому что обучение программиста слишком дорого обходится чтобы складывать все яйца в одну нишевую «корзину».
Для мелких конторок — наверное да. Для серьезных компаний, которые работают на серверах по несколько сотен тысяч долларов обучить и оплачивать грамотных разработчиков, способных писать высоконадежный и высокоэффективный код под конкретную платформу не проблема.
И я не могу себе представить «универсальный ЯП», который одинаково хорошо подходил бы как для коммерческих вычислений (например, нативная поддержка типов и арифметики с фиксированной точкой), так и для прямой работы с железом (порты, регистры и т.п.). Также нет единой платформы, которая была бы оптимизирована как для работы в режиме реального времени (а большинство задач промавтоматизации именно так и работают), так и для минимизации накладных расходов (скажем, переключения контекста) при одновременном выполнении десятков тысяч заданий на одном сервере.
И я не могу себе представить «универсальный ЯП», который одинаково хорошо подходил бы как для коммерческих вычислений (например, нативная поддержка типов и арифметики с фиксированной точкой),Эти (и ещё тыща других штук) не нужны когда есть шаблоны и интроспекция.
так и для прямой работы с железом (порты, регистры и т.п.). Также нет единой платформы, которая была бы оптимизирована как для работы в режиме реального времени (а большинство задач промавтоматизации именно так и работают), так и для минимизации накладных расходов (скажем, переключения контекста) при одновременном выполнении десятков тысяч заданий на одном сервере.Звучит как описание языка D (dlang.org)
Эти (и ещё тыща других штук) не нужны когда есть шаблоны и интроспекция.
Да? И как шаблоны помогают сходимости рекуррентного соотношения Мюллера?
В теории многие вещи выглядят красиво и изящно. Пока дело не доходит до суровых реалии жизни и практического применения.
Звучит как описание языка D (dlang.org)
Наверное. Мы использовали обычный С (кросс-компилятор для STM32) и вполне успешно.
Но пусть будет D. А теперь скажите — можно его портировать на AS/400 (чтобы компилятор генерировал TIMI код) и работать с ним с БД DB2? Можно в него (прямо в код) встраивать SQL команды и получать результат SQL прямо в коде? Поддерживает он генерацию operational descriptors для аргументов функции?
А как у него с HTML?
Боюсь, что всего этого нет. Т.е. микроконтроллеры на нем программировать можно, но вот сайт уже не напишешь и на банковский сервер тоже ничего не напишешь…
И так со всеми языками. Каждый имеет свою область применения и свои особенности. А создание «универсального ЯП» — это утопия. Как и универсальной платформы на все случаи жизни.
НА тех же промконтроллерах даже операционка зачастую не нужна. Там постоянно крутится одна задача — обтряхнуть порты и выкинуть результат наверх (в другой порт). И даже на верхнем уровне там не так много задач крутится.
А в банке на сервере одновременно тысячи процессов работают. Это совсем другой коленкор. Там скорость переключения контекста между процессами уже может катастрофически влиять на производительность.
можно его портировать на AS/400 (чтобы компилятор генерировал TIMI код) и работать с ним с БД DB2?
Без понятия, но он может использовать LLVM в качестве бэкенда и соответственно компилироваться во всё, что умеет LLMV.
Можно в него (прямо в код) встраивать SQL команды и получать результат SQL прямо в коде?
Можно.
Поддерживает он генерацию operational descriptors для аргументов функции?
Не понятно, что это.
А как у него с HTML?
Всё с ним хорошо.
сайт уже не напишешь и на банковский сервер тоже ничего не напишешь
Вполне себе напишешь и даже понравится.
LLMV у нас нет. Зато есть ILE — интегрированная языковая среда.
Все компиляторы (CL, C/C++, COBOL, RPG) являются частью системы. Любой компилятор генерирует т.н. «модуль» — это аналог объектного файла. Можно создать несколько модулей из разных языков, а потом собрать их (bind) в один программный объект.
Т.е. где удобно, пишем на RPG. Где RPG неудобен, пишем функцию на C/C++ и потом вызываем ее из RPG программы. Или наоборот. Плюс полноценная интеграция SQL в код.
operational descriptors это такая хитрая системная штука. Если включить их генерацию, то внутри функции можно получить информацию о любом ее аргументе. Тип, размер… Например, в С-шную функцию 3-м параметром передается char* А на что именно указывает это char*? Вот тут и работают opdesc — вызываем системную апишку CEEDOD и видим что на самом деле это указатель на буфер размером 1024 байта.
Это очень удобно для связи C/C++ <-> RPG Например, имеем
это объявление С-шной функции с генерацией opdesc
Чтобы вызвать ее из RPG описываем ее прототип
Это означает что фактически мы можем вызывать эту функцию с разными вариантам параметра — это может быть строка любой длинны, это может быть *omit (т.е. передается NULL) или вообще без параметра. Все это (наличие параметра, его фактический размер) определяется уже внутри С-шной функции.
В реале выглядит примерно так:
И на RPG стороне
Вызывать теперь ее можно разными способами:
Batch_CreateWorker(ResendCount: RecieveTimeout: Error);
где Error может быть любой длины
или
Batch_CreateWorker(ResendCount: RecieveTimeout: *omit);
или
Batch_CreateWorker(ResendCount: RecieveTimeout);
Это чисто системная вещь на платформе где «все есть объект» на уровне ОС. Т.е. любая переменная это не просто кусок памяти, но объект, имеющий некоторый набор свойств (тип, размер...), которые мы можем получить.
Сама процедура — это тоже объект, получающий в качестве аргументов список других объектов.
И вот зачем мне какой-то монструозный «универсальный ЯП», когда я могу использовать несколько специализированных ЯП для построения одной программы?
Все компиляторы (CL, C/C++, COBOL, RPG) являются частью системы. Любой компилятор генерирует т.н. «модуль» — это аналог объектного файла. Можно создать несколько модулей из разных языков, а потом собрать их (bind) в один программный объект.
Т.е. где удобно, пишем на RPG. Где RPG неудобен, пишем функцию на C/C++ и потом вызываем ее из RPG программы. Или наоборот. Плюс полноценная интеграция SQL в код.
operational descriptors это такая хитрая системная штука. Если включить их генерацию, то внутри функции можно получить информацию о любом ее аргументе. Тип, размер… Например, в С-шную функцию 3-м параметром передается char* А на что именно указывает это char*? Вот тут и работают opdesc — вызываем системную апишку CEEDOD и видим что на самом деле это указатель на буфер размером 1024 байта.
Это очень удобно для связи C/C++ <-> RPG Например, имеем
extern "C" void C_Func(char* pArg);
#pragma descriptor (void C_Func(""))
это объявление С-шной функции с генерацией opdesc
Чтобы вызвать ее из RPG описываем ее прототип
dcl-pr C_Func extproc('C_Func') opdesc;
str char(32767) options(*varsize : *omit : *nopass);
end-pr;Это означает что фактически мы можем вызывать эту функцию с разными вариантам параметра — это может быть строка любой длинны, это может быть *omit (т.е. передается NULL) или вообще без параметра. Все это (наличие параметра, его фактический размер) определяется уже внутри С-шной функции.
В реале выглядит примерно так:
extern "C" char Batch_CreateWorker(int nReSndCnt, int nRcvTmOut, char *error);
#pragma descriptor (void Batch_CreateWorker(void, void, ""))
char Batch_CreateWorker(int nReSndCnt, int nRcvTmOut, char *error)
{
char indResult = '0';
_INT4 parm, desctype, datatype, descinf1, descinf2;
_INT4 errorlength;
_FEEDBACK feedback;
bool bError = false;
if (error != NULL){
parm = 3;
CEEDOD(&parm, &desctype, &datatype, &descinf1, &descinf2, &errorlength, &feedback);
if (feedback.MsgSev == 0 && feedback.MsgSev == 0) {
memset(error,' ',errorlength);
bError = true;
}
}
...
return indResult;
}
И на RPG стороне
dcl-pr Batch_CreateWorker ind extproc(*CWIDEN : 'Batch_CreateWorker') opdesc;
ResendCount int(10) value;
RecieveTimeout int(10) value; // msec
Error char(1024) options(*varsize : *omit : *nopass);
end-pr;Вызывать теперь ее можно разными способами:
Batch_CreateWorker(ResendCount: RecieveTimeout: Error);
где Error может быть любой длины
или
Batch_CreateWorker(ResendCount: RecieveTimeout: *omit);
или
Batch_CreateWorker(ResendCount: RecieveTimeout);
Это чисто системная вещь на платформе где «все есть объект» на уровне ОС. Т.е. любая переменная это не просто кусок памяти, но объект, имеющий некоторый набор свойств (тип, размер...), которые мы можем получить.
Сама процедура — это тоже объект, получающий в качестве аргументов список других объектов.
И вот зачем мне какой-то монструозный «универсальный ЯП», когда я могу использовать несколько специализированных ЯП для построения одной программы?
operational descriptors это такая хитрая системная штука. Если включить их генерацию, то внутри функции можно получить информацию о любом ее аргументе.
А, compile time reflection? В D оно, конечно, тоже есть.
И вот зачем мне какой-то монструозный «универсальный ЯП», когда я могу использовать несколько специализированных ЯП для построения одной программы?
Чтобы не тратить такты на интеркоммуникацию. Все эти "процедура как объект" сильно ограничивают компилятор в возможностях оптимизации.
Чтобы не тратить такты на интеркоммуникацию. Все эти «процедура как объект» сильно ограничивают компилятор в возможностях оптимизации.
Вы не поняли. Это суть AS/400. Все это к компилятору никак не относится вообще. Это происходит на уровне системы.
И с чего Вы решили что где как ограничивает? Вы с этой системой хоть раз сталкивались? Что-то под нее писали? Или просто Вам так показалось?
Чтобы не тратить такты на интеркоммуникацию
И опять ничего не поняли… :-(
Вот смотрите. Вы пишете программу myprog.exe Собираете ее из двух исходников — myprog1.cpp и myprog2.cpp. Это нормально?
Я точно также делаю. Но у меня один из исходников на одном языке, а другой на другом. Но все это в рамках одной программы. Какая там инетеркоммуникация? Между чем и чем? Между вызовами двух функций в рамках одного программного объекта? Вы вообще о чем сейчас?
Вы вообще насколько широким практическим опытом обладаете в плане разработки задач разной тематики и под разные платформы? Чтобы так уверенно рассуждать об «универсальном ЯП».
За себя скажу что с 1988-го года (когда более-менее плотно пришлось заниматься программированием) немножко научными расчетами приходилось заниматься (еще на CM-4, которая клон PDP-11) — численные методы, линейная и нелинейная оптимизация, машинное моделирование (молекулярная динамика). Потом PC — DOS/Windows (от 3.11 до 10) — там очень широкий спектр задач от обработки данных до построения распределенных систем мониторинга оборудования. Немного (самым краем) зацепил микроконтроллеры (atmel, stm32). Сейчас вот AS/400 (IBM i) — PowerS9. Тут финтех — базы, обработка данных и т.п.
И вот даже на основе этого небольшого зоопарка могу сказать что нет ни универсальной платформы на все случаи жизни, ни универсального языка, который покрыл бы все потребности и был бы одинаково эффективен всегда и везде.
Давайте не будем измерять размеры наших писюнов. Я сейчас не достаточно возбуждён, чтобы показать достойный результат.
Накладные расходы тут есть по следующим причинам:
В разных языка разный набор идиом. Если какой-то идиомы в каком-то языке нет или она устроена иначе, необходимы адаптеры или конвертация данных.
В разных язык могут быт разные соглашения о вызовах. В результате, чтобы из одного языка вызвать функцию на другом, приходится перетряхивать регистры.
Для компилятора код на другом языке является чёрным ящиком, который он не то что заинлайнить, а даже просто сделать какие-то предположения о его ограничениях не может (например, что функция чистая или что объект безопасен для межпоточного взаимодействия).
Вы очень зашорены. Не все системы представляют из себя сборную солянку, где компоненты приходится подгонять друг к другу напильником и кувалдой.
Есть концептуально цельные платформы. Где все эти моменты продуманы разработчиками.
Почитайте вот на досуге — многие вопросы отпадут сами собой. Но там много. ILE Concepts
Есть концептуально цельные платформы. Где все эти моменты продуманы разработчиками.
Почитайте вот на досуге — многие вопросы отпадут сами собой. Но там много. ILE Concepts
По настоящему другой язык, а не только с чуть иным синтаксисом, вы в ILE не утромбуете.
«По настоящему другой» — это как?
Я дал Вам ссылку — потрудитесь ее прочитать. Хотя бы основы.
Для ILE достаточно чтобы стыковался порядок передачи параметров в стеке. Ну и некоторые возможности согласования типов данных. Все. Больше там ничего не нужно.
Здесь все компиляторы являются частью самой ОС. Условно говоря, все они «пишутся одним человеком» и пишутся сразу под ILE. И посему стыкуются без особых проблем, включая оптимизацию вызовов и передачи аргументов. И что в нем должно быть «совсем другого» чтобы его нельзя было интегрировать в ILE? И, главное, какой профит может быть от использования этого «совсем другого» языка?
Программа собирается из модулей (аналог link из obj файлов, только здесь вместо obj — модуль, а вместо термина lnk используется bind) командой CRTPGM:
Для создания модулей на разных языках свои команды.
Т.е. написать один модуль на коболе один на С++ и собрать их в одну программу не проблема. Каждый модуль будет содержать набор экспортируемых функций, которые можно вызывать из других модулей. Это позволяет для каждой подзадачи использовать то язык, котрый наиболее эффективен для ее решения.
Скажем, есть у меня некая батчмашина, реализующая параллельную обработку большого количества однотипных данных. Я пишу одну головную программу, которая запускает заданное количество программ-обработчиков (в фоновых заданиях), потом готовит им пакеты данных для обработки и раздает для обработки. И хочется мне чтобы головная задача с обработчиками общалась датаграммами через Unixsockets. Так вот все работа с данными проще пишется на RPG в нашем случае, а работа с сокетами проще реализуется на С/С++. И это не проблема. Модули работы с сокетами будут на С++, обработка — на RPG. В принципе, и запуск обработчиков мне проще на С написать через spawn чем вызывать из RPG системную команду SBMJOB (Submit Job)…
Я дал Вам ссылку — потрудитесь ее прочитать. Хотя бы основы.
Для ILE достаточно чтобы стыковался порядок передачи параметров в стеке. Ну и некоторые возможности согласования типов данных. Все. Больше там ничего не нужно.
Здесь все компиляторы являются частью самой ОС. Условно говоря, все они «пишутся одним человеком» и пишутся сразу под ILE. И посему стыкуются без особых проблем, включая оптимизацию вызовов и передачи аргументов. И что в нем должно быть «совсем другого» чтобы его нельзя было интегрировать в ILE? И, главное, какой профит может быть от использования этого «совсем другого» языка?
Программа собирается из модулей (аналог link из obj файлов, только здесь вместо obj — модуль, а вместо термина lnk используется bind) командой CRTPGM:
The Create Program (CRTPGM) command creates a program object from one or more previously created modules and, if required, one or more service programs. You can bind modules created by any of the ILE Create Module commands, CRTRPGMOD, CRTCMOD, CRTCBLMOD, or CRTCLMOD.
Для создания модулей на разных языках свои команды.
Т.е. написать один модуль на коболе один на С++ и собрать их в одну программу не проблема. Каждый модуль будет содержать набор экспортируемых функций, которые можно вызывать из других модулей. Это позволяет для каждой подзадачи использовать то язык, котрый наиболее эффективен для ее решения.
Скажем, есть у меня некая батчмашина, реализующая параллельную обработку большого количества однотипных данных. Я пишу одну головную программу, которая запускает заданное количество программ-обработчиков (в фоновых заданиях), потом готовит им пакеты данных для обработки и раздает для обработки. И хочется мне чтобы головная задача с обработчиками общалась датаграммами через Unixsockets. Так вот все работа с данными проще пишется на RPG в нашем случае, а работа с сокетами проще реализуется на С/С++. И это не проблема. Модули работы с сокетами будут на С++, обработка — на RPG. В принципе, и запуск обработчиков мне проще на С написать через spawn чем вызывать из RPG системную команду SBMJOB (Submit Job)…
LLMV у нас нет. Зато есть ILE — интегрированная языковая среда.
Все компиляторы (CL, C/C++, COBOL, RPG) являются частью системы.
Вам хватает 4 компиляторов для всего? А если Rust или Go нужно использовать то что делать?
Можно в него (прямо в код) встраивать SQL команды и получать результат SQL прямо в коде?
В более общем виде это называется «интерполяция строк».
То есть, во всех языках, куда это завезли так сделать можно. В D не завезли пока что, хотя обсуждение ведётся.
Я для этого в настоящее время использую обычный генератор SQL, в принципе всё устраивает и без интерполяционного сахарка.
Ну как не завезли…
https://code.dlang.org/packages/scriptlike#string-interpolation
В более общем виде это называется «интерполяция строк».
Нет. Это сложнее. Там специальный препроцессор. Он добавляет в код SQLCA (SQL communication area) и SQLDA (SQL descriptor area) которые используются при построении динамических параметризированных запросов с использованием хост-переменных как на вход, так и на выход. В результате там получается на 100% полноценный SQL внутри кода — сколь угодно сложные запросы, вызов встроенных процедур (кстати, ваша программа тоже может использоваться как встроенная процедура в SQL), курсоры (в том числе и двунаправленным перемещением вперед-назад, блочным чтением в массив), резалтсеты (ваша программа может возвращать наверх резалтсет) и еще очень много всякого сахара.
И поверх всего еще оптимизатор отрабатывает.
Так что это очень сильно не «интерпретатор строк». Он позволяет в программе «на лету» сформировать SQL строку, из нее создать курсор, открыть его, читать данные и тут же их как-то обрабатывать.
Нет. Это сложнее. Там специальный препроцессор.
Да. В других языках (с интерполяцией) он базируется на ней. У меня в D он даже отработает во время компиляции.
Так что это очень сильно не «интерпретатор строк».
«Интерполяция строк»
Он позволяет в программе «на лету» сформировать SQL строку, из нее создать курсор, открыть его, читать данные и тут же их как-то обрабатывать.
Да, всё верно, это можно делать на любом языке где есть шаблоны и интерполяция.
Да? И как шаблоны помогают сходимости рекуррентного соотношения Мюллера?Они позволяют спрятать реализацию всякой хитрой арифметики в библиотеке и использовать её где угодно без оверхеда, хоть в веб-сервере хоть в контроллере.
А когда завтра изобретут очередной математический выкрутас не нужно будет переписывать спецификацию языка.
Они позволяют спрятать реализацию всякой хитрой арифметики в библиотеке и использовать её где угодно без оверхеда, хоть в веб-сервере хоть в контроллере.
А при чем тут оверхед?
dcl-s fVar float(8); // обычный float
dcl-s pVar packed(15:2); // десятичное с фиксированной точкой, аналог DECIMAL в SQL
dcl-s zVar zoned(15:0); // еще один вариант десятичного с фиксированной точкой, аналог NUMERIC в SQL
и где тут оверхед?
Больше скажу — эти типы объектов на данной платформе поддерживаются на уровне самой системы (т.е. работа с ними идет ниже SLIC). Так что любые шаблоны и библиотеки по сравнению с этим — это уже оверхед
Я говорю об аналогичном отсутствии оверхеда в любом ЯП где есть нормальные шаблоны.
Что делать если будут введены новые типы? Переписывать спецификацию языка и компилятор? Какой-то порочный подход.
Это заблуждение.
Больше скажу — эти типы объектов на данной платформе поддерживаются на уровне самой системы
Что делать если будут введены новые типы? Переписывать спецификацию языка и компилятор? Какой-то порочный подход.
Так что любые шаблоны и библиотеки по сравнению с этим — это уже оверхед
Это заблуждение.
Что делать если будут введены новые типы? Переписывать спецификацию языка и компилятор? Какой-то порочный подход.
Какие новые типы Вы можете придумать? Они все будут базироваться на ограниченном количестве уже существующих. Чем, собственно, и занимаются шаблоны (которые суть просто мнемоника для «нового типа»).
Вот дополните набор типов чем-то принципиально новым, тем, что нельзя описать в рамках уже существующего:
целое (знаковое или беззнаковое, разной длины)
с плавающей точкой (знаковое, беззнаковое, разной длины)
с фиксированной точкой (знак, длина, количество знаков после запятой)
строка (как массив символов, одно- или двухбайтовых).
Все, что Вы придумаете будет производным от этих базовых типов и описываться ими. Тот же varchar, к примеру, это просто структура содержащее целое (фактическая длина) и строку.
Или bool в С++ — это тот же int (а на платформе AS/400 это системный объект, называемый «индикатор» и и являющийся 1 символом со значениями '1' — *on или '0' — *off)
И никаких новых типов уже не будет. И никакого переписывания компилятора тоже.
Ваша проблема в том, что вы не видети дальше (глубже) ЯП и фреймворка. Тут уже приводился пример что такое «базовое образование» —
Хорошая «база» выстраивает в мозгу нейросеть, которая выучена оперировать сложными причинно-следственным связями (приблизительно говоря, «когда я нажимаю на педаль газа, она тянет тросик, который поворачивает залонку в карбюраторе, в результате чего изменяется состав поступающей в цилиндры двигателя газовоздушной смеси, в результате чего та начинает взрываться сильнее, в результате чего образовавшиеся газы начинают толкать поршни сильнее, в результате чего увеличивается вращательное усилие на оси, в результате чего согласно закону F=M*а увеличивается ускорение, в результате чего машина начинает разгоняться (до тех пор, пока возросшие силы трения и сила сопротивления воздуха не скомпенсируют эту возросшую силу) и будет ехать бытрее»). А без базы возможно только выученное «нажал педаль — машина едет быстрее» — а почему, они не знают: наверное, по волшебству.
Так вот по Вашим рассуждениям видно, что все, что глубже уровня ЯП и фреймворка с шаблонами для Вас сплошная «магия». Хотя на самом деле все это опирается на набор системных API, а они, в свою очередь, на возможности той платформы, на которой все это работает. И не понимая как устроена платформа, Вы никогда не напишете действительно эффективный код.
За сим прощаюсь. Дальше уже неинтересно становится.
Какие новые типы Вы можете придумать? Они все будут базироваться на ограниченном количестве уже существующих.
Да нет же! У нас в компиляторах, которые не покрылись мхом, есть intrinsics, которые позволяют нам использовать преимущества любой архитектуры на полную. Пусть хоть в ней будут 3-битные float реализованы.
Когда оппонент отвечает только на удобные ему сообщения то, действительно, неинтересно.
Вот дополните набор типов чем-то принципиально новым, тем, что нельзя описать в рамках уже существующего
BitArray
Все, что Вы придумаете будет производным от этих базовых типов и описываться ими.
Я могу, конечно, сказать, что всё в конечном счёте будет представляться битами, но это деструктивный подход.
Как вы опишете в рамках своих типов, например, ассоциативный массив (он же hash map, он же dictionary, он же unordered_map)? Его свойства не укладываются ни в один из этих базовых типов, а отличия достаточно принципиальны, чтобы работать с ним совсем иначе и думать в первую очередь о проблемах распределения ключей, ресайза, правильности хэширования и отсутствия конфликтов между хэш-числом и равенством. Или его регулярный компаньон map (с упорядочением ключей)...
Кстати, вообще-то, ни обычного массива, ни его обобщения в виде универсальной последовательности (названный вами же result set вы будете представлять в виде числа или строки?), ни структуры (C) / записи (Pascal) у вас нет (а одна строка result set это у вас что, текстовая строка?), несмотря на то, что каждый вводит новое качество… вы уверены в своих громких утверждениях?
Ваша проблема в том, что вы не видети дальше (глубже) ЯП и фреймворка.
Кажется, вам самое время посмотреться в зеркало и оценить, насколько вы заклинились в мышлении на фреймворке под названием AS/400 и его специфике. И как при этом даже в его пределах вы упускаете принципиальное, что в нём уже есть — как те же последовательности структур.
Раньше вас читать было полезно, но тут вы грубо и тупо перегнули палку.
За сим прощаюсь. Дальше уже неинтересно становится.
:))
Как вы опишете в рамках своих типов, например, ассоциативный массив (он же hash map, он же dictionary, он же unordered_map)?
Точно также, как он описывается в любом фреймворке, где он существует.
Написать реализацию таких «типов» можно на любом языке. С той или иной степенью эффективности и удобства.
Когда Страуструп придумывал С++ никаких мапов и хешей там не было. Сейчас есть stdlib (и прочие фреймворки и библиотеки) где все это реализовано.
У меня есть свои «типы» — SkipList, Set, написанные на С++ и используемые в программах на RPG. Которые позволяют мне мыслить в рамках примитивов с определенными свойствами, не задумываясь (уже) о том, как эти примитивы реализованы внури.
Но все это не является базовыми типами. Все это опирается на некоторый набор базовых типов + комплекс доступных операций над ними.
Я могу, конечно, сказать, что всё в конечном счёте будет представляться битами, но это деструктивный подход.
Это не деструктивный подход. В конечном итоге все сводится к битам. С той или иной степенью эффективности.
названный вами же result set вы будете представлять в виде числа или строки?
ResultSet это, вообще-то, из SQL. Когда некоторая процедура возвращает не значение, а выборку (фактически это аналог SELECT, но реализованный в виде процедуры с достаточно сложной внутренней логикой). Более того, такая процедура может вернуть не одну выборку (resulset), а несколько — 2, 3, 5…
Кажется, вам самое время посмотреться в зеркало и оценить, насколько вы заклинились в мышлении на фреймворке под названием AS/400 и его специфике.
Это не фреймворк. Это платформа. Состоящая из железа и ОС. А привожу ее в пример потому что она очень сильно отличается от привычного мира Win и *nix. Я бы сказал радикально отличается. Во всем.
А рассказываю про нее тут исключительно с целью (отмотайте назад) дать пример того, что универсальный язык (фреймворк, платформа) невозможны. Каждый из них создавался для максимально эффективного решения определенного круга конкретных задач. Где он будет действительно хорош. Но в других задачах он не будет так хорошо потому что не предназначен для них.
Написать реализацию таких «типов» можно на любом языке. С той или иной степенью эффективности и удобства.
Можно. Но если вы будете на этом писать такие базовые средства, то их эффективность будет заметно ниже, чем при реализации на языке, на котором пишется сама реализация VM (скорее всего это таки C).
Но я в основном не об этом, а о том, что вы в своём полемическом задоре упустили даже банальный массив. А, ну ещё и объектные ссылки, которых может быть тоже несколько видов (уже деление на сильные и слабые ссылки достаточно важно для такой среды).
Когда Страуструп придумывал С++ никаких мапов и хешей там не было. Сейчас есть stdlib (и прочие фреймворки и библиотеки) где все это реализовано.
В случае C++ мы имеем дело с мультипарадигменным языком, который позволяет всё вплоть до прямого доступа к железу. Сравнение с ним тут некорректно. Сравнивайте с JVM или дотнетом.
Это не фреймворк. Это платформа. Состоящая из железа и ОС. А привожу ее в пример потому что она очень сильно отличается от привычного мира Win и *nix. Я бы сказал радикально отличается. Во всем.
Да, отличается. Но для 90% точности для тех, кто в Windows и Unix, подходит описание в виде: единая JVM/.NET растянутая на весь компьютер (виртуалка-LPAR, где есть), с разделением прав и защитой доступа, готовыми библиотеками для БД и объектным хранилищем вместо FS с теми же правами, и с половиной терминов заменённых на локальные IBMʼовские мемы.
Различие платформа/фреймворк тут неважно для всех, кроме админов и узкой прослойки системщиков; остальным пофиг, будет эта среда одна на машине или их несколько, будет она на спец. железе или это будет специализированный сервер на банальном x86, и так далее.
дать пример того, что универсальный язык (фреймворк, платформа) невозможны
Верно. Но дальше вы начинаете доказывать универсальность в пределах этой платформы — и вот тут уже начинаются некорректные упрощения. Например, если потребуется ограничить допустимость инстанциации какого-то шаблона типами с определённым свойством, вы не сможете протащить определение такого шаблона между разными языками. Если будет введён hash map на уровне рантайма, вам его придётся описывать раздельно для каждого языка. А если кто-то захочет притащить на AS/400, например, Idris, ему придётся повторить и всю логику языка, и проекцию на специфический рантайм.
А вот эта реплика вообще была непонятна:
А как у него с HTML?
У вас в ILE прямая работа с HTML, или как? Если нет — то какая разница, пока язык умеет работать со строками и с сокетами?
Боюсь, что всего этого нет. Т.е. микроконтроллеры на нем программировать можно, но вот сайт уже не напишешь и на банковский сервер тоже ничего не напишешь…
И так со всеми языками. Каждый имеет свою область применения и свои особенности. А создание «универсального ЯП» — это утопия. Как и универсальной платформы на все случаи жизни.
А Раст?)))
Индустрия к этому уже приходила. Ну, так многим казалось, во всяком случае. И даже не раз. IBM/360, потому что 360 градусов, платформа для всего вокруг. PL/I, потому что первый язык воистину программирования, все можно написать, не переучиваясь. Ну и дальше по списку и википедии. А мы, однако, все там же все с теми же обсуждениями :-)
Возможно, на тот момент не было достаточно серьёзной необходимости в этом — программисты были дешевле, а кода было мало.
Сейчас, когда дефицит кадров и зарплаты выросли в разы такая необходимость назрела и нам начали завозить такие языки. (И системы сборки всего этого, кстати! Cм. «The Meson Build system».)
Сейчас, когда дефицит кадров и зарплаты выросли в разы такая необходимость назрела и нам начали завозить такие языки. (И системы сборки всего этого, кстати! Cм. «The Meson Build system».)
IBM/360, потому что 360 градусов, платформа для всего вокруг.
Потом она стала еще более вокруг (IBM/370) и совсем вокруг (IMB/390) пока наконец не отребрендилась в IBM z.
И параллельно с ней развивалась другая платформа: System/36 -> System/38 -> Advansed System (AS)/400 -> IBM i. Которая не похожа вообще ни на что в плане архитектуры (это объектная система — там все есть объект). Я ее тут привожу в пример именно потому что она вообще не вписывается ни в какую «универсальность»
А мы, однако, все там же все с теми же обсуждениями :-)
Ну приходит новое поколение и им кажется, что вот они-то уж точно философский камень откроют.
Которая не похожа вообще ни на что в плане архитектуры (это объектная система — там все есть объект).
Что не мешает программировать её на универсальном и «вражеском» языке C. (Он вообще из другой экосистемы изначально.)
Я ее тут привожу в пример именно потому что она вообще не вписывается ни в какую «универсальность»
См. выше.
Что не мешает программировать её на универсальном и «вражеском» языке C.
Да нет, как раз здорово мешало.
Но, обратите внимание — сдохли мейнфреймы, а не C.
Они не сдохли, они превратились из общеупотребительного инструмента в нишевое решение. То же самое, в общем, случилось и с Си. И то же самое случится и с остальными «универсальными языками» и вообще «универсальным» всем. Это случилось даже с материально-технической базой построения коммунизма :-) Люди склонны изобретать новые потребности, которые авторам разных панацей даже в голову не приходили.
На TIOBE C стабильно входит в тройку самых популярных языков. А вот мейнфреймы сдохли вполне неиллюзорно.
Да, я тоже прочитал только что опубликованную на хабре статью :-) В которой призывается мой любимый Си наконец убить :-) Но популярность это же не то же самое, что универсальность. А Ваш изначальный пойнт был именно в универсальности. Вообще, TIOBE же «is not about the best programming language or the language in which most lines of code have been written». Ну и были времена, когда Visual Basic был самым популярным языком в мире. И что?
Может, неверно сформулировал.
Думаю что там выше отписались люди у которых в голове «вендорлок IBM»: любая задача подсознательно раскидывается под решение на мейнфрейме, и всё что в эту схему не укладывается объявляется невозможной ересью.
Это ровно тот подход, который критикуется в обсуждаемой тут статье, кстати.
А вот опровергнуть возможность универсальности не вышло, эти вопросы были просто проигнорированы.
Принесу канистру бензина к костру Си :-)
Попробуйте Dlang betterC — вам понравится!
Думаю что там выше отписались люди у которых в голове «вендорлок IBM»: любая задача подсознательно раскидывается под решение на мейнфрейме, и всё что в эту схему не укладывается объявляется невозможной ересью.
Это ровно тот подход, который критикуется в обсуждаемой тут статье, кстати.
А вот опровергнуть возможность универсальности не вышло, эти вопросы были просто проигнорированы.
В которой призывается мой любимый Си наконец убить :-)
Принесу канистру бензина к костру Си :-)
Попробуйте Dlang betterC — вам понравится!
А вот опровергнуть возможность универсальности не вышло,
Так и подтвердить пока не у кого не вышло. О том и речь. В настоящее время это вопрос веры, а не знания. Можно до посинения спорить. Просто прошлый опыт намекает, что скорее нет. Но это не должно мешать Вам или кому-нибудь еще иметь смелые планы и большие надежды.
Ну как сказать. При известной точке зрения можно считать весь датацентр целиком одним таким большим мейнфреймом.
Не сдохли. Просто если раньше это был основной инструмент — в отсутствие персональных ПК люди были вынуждены работать в терминальном режиме на мейнфреймах, то сейчас это специализированный инструмент для решения тех задач, которые требуют одновременной работы множества процессов. И их архитектура строится таким образом, чтобы минимизировать накладные расходы при переключении контекста процессоров (та же перезагрузка сегментных регистров)
А так они более чем живы — IBM i и z живут и развиваются постоянно (еще пару лет назад мы сидели на PowerS8 и i5/OS 7.2, сейчас PowerS9 и i5/OS 7.3, а есть уже и 10 и 7.4). Если погуглить те же AS/400, iSeries — вылезет очень много ресурсов. В одном только LinkedIn несколько групп (вполне себе живых и активных) по от 10000 до 30000 участников, посвященных AS/400 в тех или иных аспектах.
А есть еще конкурирующие системы от Sun, HP и еще у кого-то…
Понятно что это не массовое решение. И недешевое. Это не масс-сегмент ни в железе ни в разработке. Но «слухи об их смерти сильно преувеличены» (с)
А так они более чем живы — IBM i и z живут и развиваются постоянно (еще пару лет назад мы сидели на PowerS8 и i5/OS 7.2, сейчас PowerS9 и i5/OS 7.3, а есть уже и 10 и 7.4). Если погуглить те же AS/400, iSeries — вылезет очень много ресурсов. В одном только LinkedIn несколько групп (вполне себе живых и активных) по от 10000 до 30000 участников, посвященных AS/400 в тех или иных аспектах.
А есть еще конкурирующие системы от Sun, HP и еще у кого-то…
Понятно что это не массовое решение. И недешевое. Это не масс-сегмент ни в железе ни в разработке. Но «слухи об их смерти сильно преувеличены» (с)
Сдохли.
То что ошмётки где-то ещё теплятся ни о чём не говорит. Иначе получится что и Кобол не сдох, и любые вообще языки никогда не умрут. Как латынь.
То что ошмётки где-то ещё теплятся ни о чём не говорит. Иначе получится что и Кобол не сдох, и любые вообще языки никогда не умрут. Как латынь.
С латынью хороший пример. Она мертва в том смысле, что дети уже не учат ее сами по себе, общаясь с родителями. Но совсем не так мертва, как ее сосед этрусский, про который мы только и знаем, что он был, и буковки похожие.
Угу. Только не все об этом знают. Но Вам виднее, конечно.
Ну вообще-то это преувеличение. Сдохло то, что не развиваются. Обе эти специфические IBMʼовские линии развиваются и даже задумчиво растут в количестве (точных цифр у меня нет, но я оцениваю на глаз и наугад парк обеих в 30000 установок по миру). Количество же людей, которые с ними плотно работают, надо считать ну например 10 на каждую. Это таки очень много.
Но вот принципиальная нишевость — фактор, который никуда не девается — более того, её устранение явно не входит в планы IBM...
System/36 -> System/38 -> Advansed System (AS)/400 -> IBM i.
Там еще iServer вроде в цепочке был. Но я как раз тогда уже окончательно от этой темы отключился.
Спасибо за интересную статью!
UFO just landed and posted this here
Какой-то неумный (и неуместный) поток сознания; видимо, автор проводит куда больше времени, сочиняя идиотские «эссе» (не могу назвать это эссе в прямом смысле; это лишь болезненный «поток сознания»), нежели чем программируя.
Мне 51 год, у меня есть все, положенное для данного возраста, а, возможно, и чуть больше: отличная семья с чудесными детьми, прекрасный (и уже выплаченный) дом, долговременные инвестиции на $500K+, «дежурные» 100 штук на savings-е (на всякий случай). И я по прежнему, как и раньше, очень люблю программировать, кодировать, возиться с «железом»; выше этого в приоритетах (из хобби) только чтение. И у меня нет проблем с заключением контрактов даже в это трудное время на $100/h и выше, но, помимо, я еще и делаю скромные «халтурки» на UpWork, неа небольшие суммы (<$1000), just for fun (ну, и тоже небольшой доходец).
«Стариком» себя не ощущаю от слова «вообще», и вовсе не собираюсь им становиться. Я в курсе «модных, молодежных трендов» (хотя отнюдь и не следую им), и могу еще поучить «современному мышлению» или применению agile in real life любого «миллениала» (ой, а какие тупые идиоты попадаются, трудно представить или даже поверить!).
P.S. Речь идет о США (как и у этого Эдама Дэвиса).
Мне 51 год, у меня есть все, положенное для данного возраста, а, возможно, и чуть больше: отличная семья с чудесными детьми, прекрасный (и уже выплаченный) дом, долговременные инвестиции на $500K+, «дежурные» 100 штук на savings-е (на всякий случай). И я по прежнему, как и раньше, очень люблю программировать, кодировать, возиться с «железом»; выше этого в приоритетах (из хобби) только чтение. И у меня нет проблем с заключением контрактов даже в это трудное время на $100/h и выше, но, помимо, я еще и делаю скромные «халтурки» на UpWork, неа небольшие суммы (<$1000), just for fun (ну, и тоже небольшой доходец).
«Стариком» себя не ощущаю от слова «вообще», и вовсе не собираюсь им становиться. Я в курсе «модных, молодежных трендов» (хотя отнюдь и не следую им), и могу еще поучить «современному мышлению» или применению agile in real life любого «миллениала» (ой, а какие тупые идиоты попадаются, трудно представить или даже поверить!).
P.S. Речь идет о США (как и у этого Эдама Дэвиса).
Если честно, перевод ужасный, меня аж укачало, не возможно дочитать до конца
Черт его знает. С одной стороны, я 25+ лет в профессии; но с другой, код, написанный тогдашними 40-45-летними во времена, когда я только начинал, не может заставить меня усомниться в определенном рациональном зерне эйджизма :)
Но ведь тогдашние 40-45 летние это те кто программировал в НИИ СССР майнфреймы на перфокартах и они был больше математиками, чем программистами. Да собственно вся профессия кардинально поменялось.
Это как квантового физика заставить переучится на фронтенд программиста — с большой вероятностью он будет программировать фигово (но вот физиком может быть очень хорошим).
Это как квантового физика заставить переучится на фронтенд программиста — с большой вероятностью он будет программировать фигово (но вот физиком может быть очень хорошим).
Тем любопытнее после 60 будет послушать мнение о себе со стороны нынешнего молодняка. Профессия-то, как мы видим, крайне нестабильная во взглядах на то, что такое модно.
Это как квантового физика заставить переучится на фронтенд программистаЯ работал с китайским Ph.D. в физике (ранее работавшим в CERN на LHC, под руководством своего учителя, Нобелевского лауреата), переквалифицировавшегося в IT (он был у нас project manager/team lead/senior software engineer и «затычка за все про все»), так вот, со 100% «вероятностью» программировал он отлично! Хорошая «база» значит очень много, вероятно, «миллениалам» и «жертвам ЕГ» просто не понять.
Хорошая «база» значит очень много, вероятно, «миллениалам» и «жертвам ЕГ» просто не понять.
Соглашусь. Сам по образованию физик. Физтех. Еще «тот», советский, доЕГЭшниый, минсредмашевский. Физмат база часто помогала. Да и мозги неплохо выстроили. Несмотря на то, что ITшного образования тогда не было — два семестра «вычтехники» (писали что-то на бланках на Fortran IV, относили на ВЦ, потом забирали распечатки выполнения на ЕС-1033) ну и потом курсовой считали на Искра-1256…
Хорошая "база" выстраивает в мозгу нейросеть, которая выучена оперировать сложными причинно-следственным связями (приблизительно говоря, "когда я нажимаю на педаль газа, она тянет тросик, который поворачивает залонку в карбюраторе, в результате чего изменяется состав поступающей в цилиндры двигателя газовоздушной смеси, в результате чего та начинает взрываться сильнее, в результате чего образовавшиеся газы начинают толкать поршни сильнее, в результате чего увеличивается вращательное усилие на оси, в результате чего согласно закону F=M*а увеличивается ускорение, в результате чего машина начинает разгоняться (до тех пор, пока возросшие силы трения и сила сопротивления воздуха не скомпенсируют эту возросшую силу) и будет ехать бытрее"). А без базы возможно только выученное "нажал педаль — машина едет быстрее" — а почему, они не знают: наверное, по волшебству.
Но они не хотят вашего отзыва. Они хотят, чтобы вы кивнули и сделали всё, что они просят.
Знакомая ситуация: "Мы не хотим говорить тебе что делать, иначе это снизит твою мотивацию, но результат твоего анализа не соответствует нашим ожиданиям, вникать в детали анализа мы не хотим".
Менеджеры говорили мне в обзорах эффективности, что со мной «трудно работать».
То же знакомая ситуация: "Ты не идёшь на компромис. Потому что сделал не всё так, как я хотел, хоть я и не настаивал."
Но идея о том, что я никогда не должен давать никакой функциональной обратной связи по дизайну самого приложения, ну… это просто невежество.
И тут история из жизни. Дали мне доступ к отрисованному согласованному дизайн макету, ну я конечно назадавал там вопросов по поведению, думая, что делаю хорошее дело, помогаю выявить проблемы. Но все мои комментарии просто удалили и попросили больше ничего не писать.
UFO just landed and posted this here
Да пошли вы… сюда: https://fallacy.hyoo.ru/#search/selected=social/filter=selected
Выходит я старый(((
В 40 уже старый…
В 40 уже старый…
Как я понял, автор пишет о том что ему не нравится:
1) когда им манипулируют
2) когда игнорируют его профессиональное мнение.
Вряд ли это кому-то нравится. Мне точно нет. И чем старше — тем сильнее.
От статьи осталось четкий привкус: «все пид******, а я Д'Артаньян».
Человек не умеет работать в коллективе, одиночка. Возможно специалист, но скорее всего не такой крутой, как сам себя хвалит.
Если ты не спец-круче всех, тогда не бывать тебе Д'Артаньяном :) Поэтому и менеджмент особо не ценит.
Этот человек родился не в той стране. Явно видно, что этот человек в душе из страны советов.
«Я хочу всем советовать как надо делать, но при этом ни хочу ни за что отвечать» это ж прям классика русскоязычных форумов. Где каждый как минимум физик-ядерщик, профессор медицины и профессиональный разработчик в одном лице.
Человек не умеет работать в коллективе, одиночка. Возможно специалист, но скорее всего не такой крутой, как сам себя хвалит.
Если ты не спец-круче всех, тогда не бывать тебе Д'Артаньяном :) Поэтому и менеджмент особо не ценит.
Большинство людей в моем положении не просто знают, как писать код. Они знают, как построить приложение лучше. Они знают очень много о том, что работает, а что вызывает кошмары конечного пользователя. Сейчас у меня нет никакого желания быть бизнес-аналитиком или менеджером проекта.
Этот человек родился не в той стране. Явно видно, что этот человек в душе из страны советов.
«Я хочу всем советовать как надо делать, но при этом ни хочу ни за что отвечать» это ж прям классика русскоязычных форумов. Где каждый как минимум физик-ядерщик, профессор медицины и профессиональный разработчик в одном лице.
Возможно специалист, но скорее всего не такой крутой, как сам себя хвалит.
www.spotifytoolz.com/home
Есть горячее стремление немедленно взять автора вот этого на фронтэнд разработку? У меня нет. Но я не специалист, возможно, там какие-то скрытые достоинства, от меня ускользающие.
Явно видно, что этот человек в душе из страны советов.
«Playwright, painter, poet, programmer, professional alcoholic», «On nights and weekends, I am a poet and an aspiring novelist. When I am not writing, I am pursuing my personal quest to sample every beer on the planet. » — и это все о нем. Точнее, это он о себе. На советской интеллигентской кухне он бы прижился, это точно.
Сегодня моя реакция на этих людей всегда одна и та же. Я вежливо их выслушиваю. Даю любую немедленную обратную связь, которая может помочь правильно направить их. Но, как только они хотят подтолкнуть меня к тому, чтобы я выполнял работу — вне нормального конвейера разработки, — я вежливо, но твёрдо отказываюсь.Потому что корректный способ — не тратить время на объяснения, а отвечать «назначайте на меня таску в Джире, тогда и начнем разговаривать».
Это может звучать как «корректный» способ справиться с подобной ситуацией. Но я заметил, что, как только я говорю кому-то «нет», это имеет тенденцию сопровождаться всевозможными долгосрочными побочными эффектами.
Какая-то странная там у них организация рабочего процесса…
Какая-то странная там у них организация рабочего процесса…
Процессы тут (i.e. «там» — то-бишь у нас, в США; впрочем, как, наверное, и у вас) организованы (а, порой, и дезорганизованы) по «очень разному», но в данном конкретном случае речь идет лишь о субъективном восприятии этих процессов бездельником и лузером, который, впрочем, считает себя «талантливым разработчиком», так, что можете списать это на «словонедержание» данного «характерного экземпляра» ;)
Недавно у меня была работа, где несколько руководителей были откровенными, неистовыми расистами. И женоненавистниками. И антисемитами
То есть, у автора была отличная работа с великолепными, думающими СЕО, не прогнувшимися под всякие левые ценности, но автору больше по душе BLM? Я полагаю, с этого и надо было начинать статью — тогда многие здравомыслящие люди попросту не стали бы ее читать.
Как сказал один умный человек «как только я исключил понятие „совесть“ из рабочих отношений — я стал работать вдвое меньше, а зарабатывать втрое больше».
Я не совсем согласен. Совесть терять не надо. Самоуважение, да и репутация в конце концов. Но упомянутое в статье «взятие на слабо», энтузиазм, и прочие эмоции — однозначно вон!
Ну речь идет скорее про взятие на слабо и обещание призрачных перспектив в обмен на ненормированную работу (не подкрепленные пунктами контракта), а не про то, чтобы вести себя как свинья. Вести себя всегда нужно профессионально и корректно.
Однажды мне при увольнении не выплатили отпускные и просто отправили в игнор. Очень вежливый емейл с указанием нарушенных пунктов контракта и законов и копией владельцу конторы решил вопрос мгновенно :)
Однажды мне при увольнении не выплатили отпускные и просто отправили в игнор. Очень вежливый емейл с указанием нарушенных пунктов контракта и законов и копией владельцу конторы решил вопрос мгновенно :)
Потому что некоторые глупости, с которыми я сталкиваюсь ежедневно, иногда вызывают у меня сильную депрессию.
Рекомендую книгу «Тонкое искусство пофигизма» должно стать чуть проще.
Когда я был помоложе, я делал свои скудные предложения. А иногда клиенты даже слушали. Но если они полностью игнорировали меня, мне было всё равно. Я просто делал всё именно так, как просили клиенты.
Но я признаю, что в данный момент моей жизни меня чертовски расстраивает, когда клиент просит о чём-то, что, как мне известно, потерпит неудачу, или продукт нужно будет изменить сразу после релиза, но, если я поднимаю этот вопрос любым способом, в их голосе ощущается раздражение.
Вообще, общение разработчика напрямую с клиентом не самый лучший вариант. Опытного BA бы туда, его работа выделить нужное и отсеять не нужное. А Разработчик должен качественно реализовать требования. Всем было бы проще.
Меня тоже удивил этот фрагмент в конце. Человек говорит что у него много опыта и управленца и кодера, при этом жалуется на то, что его нанимая кодером требуют выдать код, а все свои гениальные идеи и виденье — придержать. Помоему опытному специалисту должно быть это привычно и очевидно. Взяли повара ватрушки печь — пеки ватрушки и не лезь меню составлять. Хоть тебе и кажется будто в чайнатауне лучше воки делать вместо ватрушек.
Sign up to leave a comment.
Я уже стар, и мой опыт мешает мне в работе, или Почему немолодым людям трудно работать программистами