Я уже стар, и мой опыт мешает мне в работе, или Почему немолодым людям трудно работать программистами

Original author: Adam Nathaniel Davis
  • Translation
Я старый. При этом я в ладу с собой. Я не лежу ночью, беспокоясь о своей старости. Но прекрасно понимаю, что я определённо стар — по крайней мере в смысле программирования. Большинство непрограммистов посмеялись бы над мыслью о старости. Во многих сферах в середине пятого десятка лет означает, быть на вершине профессиональных навыков. Но в разработке программного обеспечения любой человек старше 40 часто рассматривается с некоторым подозрением. Люди старше 50 часто выпадают из пула резюме. Человеку за 60 хорошо иметь очень прочную стратегию выхода на пенсию. Но это статья не об определении «старости» или о предвзятости к старикам. Эта статья о том, что «более опытным» разработчикам часто труднее приспособиться к конкретной работе, задаче или среде.





Это не просто предубеждение. Это реальность. Я испытал это на себе. Я видел это у других. Я почувствовал это в своей душе. Не знаю, поможет ли эта статья кому-нибудь. Как-нибудь. Но чувствую себя обязанным назвать некоторые причины, по которым старикам вроде меня становится всё труднее просто вписаться в работу, не говоря уже о том, чтобы преуспеть в ней.

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

Усталость от политики


Когда я был моложе, я был доволен всеми стандартными корпоративными политическими играми. Чёрт возьми, иногда я даже наслаждался ими. Но сейчас… Ну, скажем так, я стал полярной противоположностью политического игрока — и моё нежелание «подыгрывать» часто вызывает ощутимые проблемы в работе.

Раньше я работал в управлении. В какой-то момент у меня было 60 разрабов, организованных в 6 команд, которые всё докладывали мне. В то время я был гораздо больше занят тем, чтобы излагать своё словоблудие «правильно». Я гораздо больше был склонен к тому, чтобы часами писать отчёты (о которых я знал, что они не будут прочитаны) и ставить галочки в окошках для аудита (о которых я знал, что они никого не заботят).

Около 5 лет назад я сознательно ушел из руководства. Я хотел снова стать просто кодером. Как можно дальше уйти от политики, позволив себе передозировку кода. Но на моём пути к просто кодеру случилась забавная вещь. Политика, похоже, последовала за мной.

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

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

Я совершенно счастлив разговаривать с «бизнесом», «клиентами» или «заинтересованными сторонами». И я обычно могу разговаривать с ними так, чтобы избежать техноболтовни и никого не унижать. Люди могут спрашивать меня о всяких сомнительных результатах — и я спокойно объясняю им, дилетантам, какие они могут иметь неприятные непредвиденные последствия в будущем. В течение нескольких недель или даже месяцев эти взаимодействия не доставляют мне никаких проблем. Затем случается это…

Это — тот момент, когда кто-то хочет, чтобы вы сделали что-то в коде, буквально совершенно бессмысленное.

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

Когда я был моложе, мне было гораздо легче проглотить свои возражения в подобных случаях. А сейчас? Мне легко избежать оскорблений или конфронтации, но нелегко сформулировать обратную связь в робких выражениях, чтобы воротилы обманули себя и полагали, что я поддерживаю их идею.

Я ни на кого не кричу. Не использую непрофессиональную лексику. Но вам лучше поверить: если вы спросите меня, что я думаю об идее, которая действительно эпически глупа, я скажу совершенно чётко, что это ужасная идея. Удивительно, как часто эта простая склонность вновь и вновь вызывает неприятности в работе.



Неприятие текучки


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

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

Если фанат — какой-нибудь малоуважаемый парень прямо из колледжа, его иррациональные страсти, скорее всего, не вызовут никаких реальных проблем. Но фанаты могут быть где угодно. Ваш менеджер может быть фанатом. Архитектор башни из слоновой кости, который дружит с CIO, может быть фанатом. Парень, который работает в компании последние 20 лет, может быть фанатом. Чёрт возьми, даже CEO может быть фанатом!

И как только фанат решит, что он ненавидит технологию, с которой вы работаете (технологию, в которую вы, вероятно, вложили тысячи часов), и как только его слова достигнут ушей тех, кто принимает решения, только вопросом времени становится факт, когда вы всё перепишете или когда станете искать новую работу.

Эта текучка относится не только к технологиям верхнего уровня. Она применима, например, к пакетам NPM. Или к руководствам по стилю. Или… к любому тривиальному аспекту нашей работы. И как только мнение в вашем отделе «эволюционирует», вы обнаружите, что вам придётся радикально изменить подход к выполнению работы или искать новую работу.

Хотите знать, почему нечто столь банальное, как табуляция и пробелы, может и по сей день приводить людей в ярость? Это происходит потому, что среди вас есть люди, которые программировали, используя табуляцию или пробел многие годы, и это никогда не было проблемой. И вот однажды кто-то заходит и говорит: «О! Не могу поверить, что вы всё ещё пользуетесь табуляцией/пробелом!» Довольно скоро вы будете вынуждены следовать за толпой в любом тривиальном решении, которое было принято для вас. Или будете искать новую работу.

Пожалуйста, не думайте, что я не хочу изучать новые технологии (или техники). Погружаясь во что-то, что обещает решить проблему, я взволнован так же, как и программист рядом со мной. Но я не в восторге от переключения с языков/фреймворков/инструментов и т. д. только потому, что старый способ — якобы «тупооой», а на замену, предположительно, придёт новое навороченное, блестящее решение.



Цинизм опыта


Я могу вспомнить много случаев, когда в начале карьеры моя наивность была почти… внутренним активом. Видите ли, иногда я был слишком глуп, чтобы осознать, что меня используют. Но в процессе «использования» я также приобрёл ценный опыт. Или произвёл впечатление на людей, которые видели, как я ломал свой хребет, чтобы всё получилось.

В мои 20 лет любое малейшее предположение о необходимости дополнительной работы привело бы к тому, что я провёл бы 24-часовой марафон кодирования. Или работал бы в выходные. Любое предположение, что мы используем какую-либо (контрпродуктивную и плохо поддерживаемую) технологию, привело бы меня к тому, что я нырял бы с головой в процесс изучения и внедрения этой технологии. Любой намёк на опционы на акции или будущие IPO заставил бы меня задуматься о том, что я работаю на следующий Google и смогу работать на себя почти до смерти — потому что… я буду богат!

А сегодня? Ну, давайте просто скажем, что я стал более взыскательным к своими усилиям.

Я буду (и часто) работать сверхурочно. Но как только почувствую, что моей готовностью работать сверхурочно злоупотребляют, мы немного поболтаем. И если наша команда кого-то потеряет и «решение» компании заключается в том, чтобы просто распределить работу по остальным сотрудникам — сохраняя при этом все сроки выполнения, то гарантирую — я очень чётко скажу всем, что не буду полностью брать на себя чужую рабочую нагрузку.

Я уже не в восторге от пустых обещаний большинства компаний (особенно стартапов). Если пакет компенсации включает в себя некоторые опционы на акции, то это здорово. Но если вы ожидаете, что я буду рассматривать эти варианты как основной компонент, то я предлагаю вам начать набор в местных колледжах. У меня есть ипотеки (здесь множественное число). У меня есть счета и обязательства. И даже если мне понравится ваша компания, она не понравится мне настолько, чтобы я был готов отказаться от зарплаты по рыночному курсу.

Вот ещё одна ситуация, где мой опыт (цинизм) может иногда создавать мне проблемы:

Как только вы приобретёте репутацию в организации как опытный программист, который действительно может сделать что-то, вы можете внезапно обнаружить, что у вас на руках множество просьб о неофициальной работе. Я говорю о тех ситуациях, когда кто-то за пределами конвейера вашей команды подходит и начинает говорить что-то вроде: «Насколько трудно сделать маленькое изменение в этом приложении??».

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

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

Сегодня я редко балую людей, обратившихся ко мне с такими просьбами. Вы знаете их. Это люди, которые считают, что они могут полностью разрушить конвейер разработки, подлизавшись к одному из программистов напрямую. У меня были руководители, которые пытались сделать это со мной (они, тем не менее, были полностью вне моей субординации). У меня были молодые леди, которые пытались сделать это со мной, сидя рядом со мной ближе естественной дистанции и улыбаясь мне больше, чем улыбается кто-то искренний.

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

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

На самом деле, удивительно видеть ошеломлённые взгляды на лицах каждый раз, когда я говорю профессиональным и бесстрастным тоном: «Нет. Я не буду этого делать», или «Вам придётся поговорить об этом с менеджером проекта», или «Вам нужно будет обсудить этот приоритет с клиентом напрямую».

Для некоторых людей не имеет значения, насколько вы профессиональны или справедливы. Они всё равно затаят злобу, если посметь отказать им.



Небольшая терпимость к двусмысленности


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

Для ясности: я понимаю, что у корпораций есть общеупотребительные обороты. Меня не беспокоит, когда кто-то говорит, что мы должны «прикоснуться к базе в оффлайне» [прим.перев. — touch base offline — восстановить контакт с кем-то на короткое время через реальную встречу]. А «мыслить нестандартно» — избитая (и почти бессмысленная) фраза, но, когда кто-то произносит эти слова, я догадываюсь, что они пытаются передать.

Но если вы скажете мне, что нам нужно сделать некоторые «правильные размеры» [прим. перев. — right-sizing — сокращение размеров компании за счёт сокращения штата], меня немного затошнит. Если вы продолжаете проповедовать мне о том, что надо быть «разрушителем» [прим. перев. — быть человеком, который идёт против системы], я знаю, что ваша идея «разрушения» заключается в том, чтобы я работал по ночам и в выходные, чтобы реализовать ваше видение приложения.

Если вы просите меня принять «мероприятие», это тонкий способ попытаться дать мне новую работу без учёта текущих приоритетов проекта. Я мог бы продолжать, но вы уже поняли суть. Я действительно возненавидел эту непрекращающуюся потребность поддерживать неприятные идеи в какой-то расплывчатой форме «новой речи».

Это расстройство особенно бросается в глаза, когда кто-то хочет, чтобы я согласился с предложением — и это предложение не имеет никаких оправданий. Я могу довольно много говорить о большинстве потенциальных идей. Но если идея просто лишена смысла… Я так и скажу. И вот тут-то люди начинают говорить обо мне, как о каком-то ворчливом старом медведе, которого невозможно переубедить.



Знание своей ценности


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

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

Недавно у меня была контрактная работа, где вся моя команда работала удалённо, но они хотели, чтобы я приходил в офис каждый день. Итак, я пробыл там недолго. Недавно у меня была работа, где несколько руководителей были откровенными, неистовыми расистами. И женоненавистниками. И антисемитами. Итак. Я пробыл там недолго. Однажды у меня была работа, где меня заставляли выполнять нелепую, сложную и трудоёмкую работу, чтобы удостовериться в безопасности моего кода (включая множество контрольных флажков, которые ничего не делали для реальной защиты приложения). Но когда я показал, с какой лёгкостью могу взломать базу данных сотрудников (и любой другой за пределами компании может сделать то же самое), — им было всё равно… Я пробыл там недолго.

Вообще говоря, такого рода гипермобильность является активом. Я имею в виду, кто хочет застрять на работе, где какой-то её аспект стал обременительным?? Но обратная сторона в том, что становится очень трудно оправдать общение с чьим-либо дерьмом — даже в течение короткого времени. Опять же, как правило, это хорошо. Но я встречал других стариков, таких же, как я, которые просто не могут сесть и построить прочную историю с какой-то одной компанией, потому что эти компании всегда делают что-то грубое, непрофессиональное или просто откровенно глупое. Пройдите по этой схеме через 3, 4 или более работодателей, и вскоре у вас будет репутация этого капризного старика, который просто не может «вписаться».



ПО как обрезка теста


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

Слушайте, это понятно всем. Разработка программного обеспечения трудна. И сложна. И дорогá. И отнимает много времени. И я также понимаю, что организации постоянно ищут новые способы упрощения этих (по сути сложных) проектов.

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

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

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

Когда я был помоложе, я делал свои скудные предложения. А иногда клиенты даже слушали. Но если они полностью игнорировали меня, мне было всё равно. Я просто делал всё именно так, как просили клиенты.

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

Я даже, кажется, слышу, как они думают: «Почему бы этому парню не заткнуться и просто не создать приложение именно так, как мы его попросили??» Пройдите этот процесс с достаточным количеством клиентов и вы поймаете себя на том, что удивляетесь, почему вы вообще занимаетесь тем, чем занимаетесь.

Заключение


Я мог бы написать в том же духе еще 100 000 слов. Но пост уже становится довольно длинным. Сейчас я просто хотел изложить некоторые причины, по которым старые программисты действительно могут иметь проблемы с «современными» отделами разработчиков. Не потому, что они «застряли». Не потому, что не могут понять новейшие технологии. Часто это происходит потому, что их собственный опыт в некотором смысле работает против них. Я часто замечал это, когда смотрел на себя. Я ловлю себя на мысли: «Сколько ещё я могу продолжать это делать?» Потому что некоторые глупости, с которыми я сталкиваюсь ежедневно, иногда вызывают у меня сильную депрессию.

image



Рекомендуемые статьи


SkillFactory
Школа Computer Science. Скидка 10% по коду HABR

Comments 144

    +22
    В мои 20 лет любое малейшее предположение о необходимости дополнительной работы привело бы к тому, что я провёл бы 24-часовой марафон кодирования. Или работал бы в выходные.

    Реальный мир. Я лет 10 назад стал задумываться об возрастных ограничениях в некоторых вакансиях. Тогда закралась мысль, что опытным людям работодателю сложнее морочить голову обещаниями.
      +9
      Те-же впечатления. Только так было всегда. Ещё со времён СССР. Молодых и горячих легче взять на слабо, на лесть и на «даёшь!». Поэтому им будет приоритет при приёме на работу, — им можно платить меньше, а вынуждать работать больше.
        +28
        — Самуил Маркович, вы же сильный, вы справитесь!
        — Яша, я — умный, я даже не возьмусь.
      +10
      Статья сама по себе прекрасна, но лучше читать ее в оригинале.

      мы должны «прикоснуться к базе в оффлайне».
      vs
      we should «touch base offline»

      нужно сделать некоторые «правильные размеры»
      vs
      we need to do some «right-sizing»
        +11
        Я действительно возненавидел эту непрекращающуюся потребность поддерживать неприятные идеи в какой-то расплывчатой форме «новой речи».

        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.

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

          +1
          Может переводчик просто не читал «1984» и не понял о чём речь.
          +3

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

        +9

        Программисты в этом не уникальны. Так почти в любой профессии. С возрастом пропадает желание "быть частью команды" за печеньки и кофемашину, вместо этого появляется здоровая меркантильность. С возрастом вырабатывается скептическое отношение к новинкам, потому что в прошлом опыте этих новинок было слишком много и каждая из этих новинок обещала изменить рынок. Обо всём этом и говорил Писатель в "Сталкере" Тарковского.

          +2

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

            +5

            Да. Первые 3 года работы.

              +2
              Зависит от размера этой части. Я бы променял тысячу рублей в месяц, за безлимитный доступ к кофе.
                +2

                Вы не поняли. Печеньки и кофемашина это и есть зарплата.

                0
                «В наших краях это большая редкость, но они есть».
              +1

              Все по кругу. Это так.
              Как говАривал опытный Россини начинающим композиторам: интересное у вас не ново, а новое не интересно.
              Я уже тоже с 10 ок лет смотрю на всю эту вакханалию. Если раньше получение каких либо знаний было сопряжено с усилиями поиска книг, статей и тд, их прочтения и проб, то сейчас одни онлайн курсы и прочие видосики. Самое хорошее имхо уже стать нештатным консультантом. А если хочешь писать код и что то новое изучать — заведи хобби из параллельной области. Например микроконтроллеры программируй.

                +2

                Например микроконтроллеры программируй.


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

                  0
                  да, или можно написать бота для той игры, которая интересна, но в силу старости не стать киберспортсменом, например, старкрафт )
                • UFO just landed and posted this here
                    +4
                    Ну что же… Этот «я» станет сам постарше и тогда в соответствии с его теперешними представлениями ему останется тихо отойти в сторону
                    Смех конечно…
                    Отчасти это проистекает из ремесленности современного IT. Есть очень большое количество сортов гранита, добываемого в разных местах средств, фреймворков и прочего. Только находясь в относительно молодом возрасте можно с удовольствием в этом рыться. Потом приходит понимание, что это, говоря современным жаргоном, неимоверный оверхед.
                      +2
                      Я бы назвал это не оверхедом, а несколько иначе — с возрастом начинаешь больше ценить время.

                      Любой фреймворк (язык программирования, IDE, etc) требует времени на изучение и приобретение опыта работы с ним. Но быстротечность современных технологий такова, что пока осваиваешься с одним фреймворком, ему на смену уже идет другой. В результате ты, потратив немало времени на изучение предыдущего фреймворка, не успеваешь его применить для достижения конкретных практических целей (business value). Потому что вынужден снова тратить время на изучение нового фреймворка (языка программирования, IDE, etc).

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

                      С годами человек становится мудрее. И всё отчетливее начинает понимать, что деньги можно заработать, здоровье поправить, а вот время уходит безвозвратно. Поэтому и начинаешь ценить его больше всего.

                      Я не против саморазвития как такового. Но, как и в других областях, о доле здорового консерватизма здесь забывать не стоит.

                      «Мера должна быть во всем.» — Гораций
                        +1

                        С возрастом время течёт субъективно быстрее.
                        Чисто из айтишных наблюдений — релизы убунты.
                        Раньше с энтузиазмом ставил и осваивал каждый новый релиз.
                        А нынче поставил свежий LTS, не успел глазом моргнуть — уже вышел следующий, а затем текущий (так до конца и не освоенный) уже потерял поддержку...

                          0
                          Эх, молодежь! В моей молодости про убунту и не слышали. Это были релизы RedHat Linux. :-)
                            0

                            Да всякое было. Просто на модемном интернете в молодости нужно было много терпения. А так — и Alt Linux, и Mandrake ставший позднее Mandriva, и OpenSuse — чего только не было… А потом вдруг замаячила убунта, которую не надо было скачивать; достаточно было оставить заявку и совершенно бесплатно присылали полсотни дисков обычной почтой (полсотни — это чтоб друзьям раздать). Правда, и работала она с русской локалью как-то не очень...

                              0

                              До utf8 с локалью всегда были проблемы, еще и от монтирования виндовых флешек.


                              Тоже начинал с мандрейка в школе)

                              0
                              У меня начиналось с локализации Red Hat — Красная Шапочка
                              https://www.go-electronic.com/?p=627
                            0
                            «здоровье поправить» — посмею заметить, что далеко не всегда
                          +2
                          Там какой-то несерьёзный текст. Но иногда бывает такое мнение, когда позиционируют себя как «мы — молодой коллектив, средний возраст сотрудников — 30 лет» и начинается трансформация в «геймификации, ачивки и мемчики». Становится стыдно работать.
                            +2
                            Нет, не стыдно. Просто вызывает недоумение: «Неужели нельзя просто работать? Именно за это мне платят деньги». Но приходится всю эту лабуду поддерживать.
                          +9
                          Мне уже за 60. Ещё в 45, когда меня позвали в новый большой проект, я пошёл с условием, что программировать — не буду. И не ошибся. Не то, чтобы мне не хотелось программлять (потому скрипты для себя пишу, но сугубо для себя), но понимание того, что эту работу молодые сделают быстрее и лучше, только крепло со временем. А, раз так — лучше уйти из этой ниши.
                          К счастью, проект относится к реальности, не внутри-айтишный, так что сейчас уже третье поколение проекта, и как-то я в нём живу. Обнаружилось, что понимание предметной области, с одной стороны, и понимание людей как юзеров, с другой — вполне себе ценность. Так что как непосредственный проектировщик (не верхнеуровные картинки, а именно «как это сделать») — пока лучше окружающих, а то бы и это бросил. Плюс как менеджер невысокого (к счастью) уровня лучше понимаю, кому именно какую работу дать с учётом не столько даже квалификации, а характера.
                          Кроме того, сугубо программисткие навыки на удивление константны. Молодые программеры, освоив (признаюсь, уже недоступные мне) технологии, часто упускают банальности, что ведёт к отдалённым неприятным последствиям. Так что мои осторожные (не хочется всё же выглядеть идиотом-старпёром) советы иногда воспринимаются как открытие :-)
                            +16
                            >понимание того, что эту работу молодые сделают быстрее и лучше
                            А я вот продолжаю. И могу пока что четко сказать, что нет, не делают — ни быстрее, ни лучше. Ну или так — синьоры, которым самим скажем под 40, возможно делают, но не всегда. А молодежь — чаще нет, чем да. Это в общем ничего не значит, кроме того, что бывает по-разному.

                            >понимание предметной области, с одной стороны, и понимание людей как юзеров
                            Это понимание совершенно не мешает попутно кодить. И умение проектировать тоже.

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

                              Это сугубо личное. Один коллега старше меня года на четыре, и он активный и очень хороший программист, молодым фору легко дает. Зато поручать ему приложение в целом — не стоит. Нужен кто-то, кто сделает толковый техпроект.

                              +13
                              эту работу молодые сделают быстрее и лучше,

                              40+. "Быстрее" — может быть. "Лучше" — хммммм… Если под "лучше" понимается "с такими дырками в безопасности, что шагающий экскаватор пройдёт", то таки да. Потому что молодежь считает, что "программа готова, когда она делает то, что сказали", а то, что правильный критерий — это "программа НЕ делает того, что НЕ сказали" — это им надо долго и упорно вдалбливать. Потому и имем дырявые Госуслуги, дырявые гуглмапс, постоянные глюки с Убером/Яндекс.такси/и т.п. (буквально вчера пинался с ними на тему привязки карты: банк говорит "у нас всё нормально, звоните в Я.т", в Я.т говорят "у нас всё нормально, звоните в банк", так ни к чему и не пришли).

                                +3
                                Вы как-то уж очень в гуманитарную область переводите, в эмоции. Я не готов так обсуждать.
                                  –4

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

                                    +5
                                    Продолжаете нагнетать эмоции? Попробуйте написать что-то внятное и со смыслом, тогда отвечу. Иначе, извините, не вижу смысла продолжать.
                                      +2
                                      Простите, чисто ради интереса — Вы случайно не миллениал?
                                      Мне уже за 60.
                                      Не миллениал. Бумер.
                                  +2
                                  По моему опыту — Один опытный солдат стоит трех новобранцев, если считать вместе и soft и hard скиллы, а небольшое замедление умственных способностей с возрастом с лихвой компенсируется опытом
                                    0
                                    Во-первых, как я уже писал — это очень личное, у каждого процесс идёт по-своему.
                                    Во-вторых, в действительно сложных задачах реализация опыта занимает настолько много времени, что собственно кодирование бывает лучше переложить на «молодых и рьяных», и без того есть, чем заняться. Лучше не один или трое, а команда. И в команде лидеру собственное программление мешает реализовывать опыт через других. ПОтому как через других — труднее, и подсознательно человек прячется, «у меня есть собственные срочные задания, вот сейчас их добью — и займусь остальными».
                                    И, в третьих, снова повторюсь: в разных областях по-разному. В чисто ITшных задачах «внешний» опыт значит меньше, если же задача соприкасается с реальностью — гораздо больше.
                                      +1
                                      в действительно сложных задачах реализация опыта занимает настолько много времени, что собственно кодирование бывает лучше переложить на «молодых и рьяных»


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

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

                                      Сам всю жизнь занимался бэкендом на уровне системных апи. Т.е. никаких фреймворков. В 52 резко поменял и предметную область и платформу (очень специфическую, совершенно непохожую на то, с чем имел дело раньше) и основной язык разработки. Было очень тяжело, но справился. И даже смог трансформировать значительную часть накопленного опыта под новые условия.

                                      Убедился что опыт разработчика достаточно универсален и накопленное водной области вполне может найти применение в другой. И на одном энтузиазме далеко не уедешь.

                                      К фреймворкам отношусь… В своей области достаточно скептически. Где-то «наверху» оно наверное и помогает. Но хорошо сделать «низ», на который все опирается, чтобы он эффективно работал и выдерживал большую нагрузку — тут надо понимать основы работы той платформы, на которой этот «низ» установлен. И уметь эффективно ее использовать.

                                      Фактически мы разрабатываем те самые «фреймворки» для среднего и высокого уровня.
                                        0
                                        Увы, не всегда возможно. В большинстве случаев такое перекладывание выльется в то, что просто будешь сидеть рядом с молодым и пошагово ему объяснять что где и как делать. Тут проще сделать самому.
                                        Ровно то, о чём я и писал — программеру-лидеру мешает организовать работу то, что «легче сделать самому».
                                        Для того и полезен (в моём случае, надеюсь) лидер, не занимающийся непосредственным кодированием. Он должен и задачу группе поставить, и организовать процесс подтягивания «молодых» так, чтобы это не мешало общему темпу.
                                        всю жизнь занимался бэкендом на уровне системных апи
                                        Чуть ли не самая простая область, повезло :-) Простая в смысле внешних условий, главное — собственно свою часть сделать хорошо (что, конечно, не так просто).
                                        Вообще сугубо IT-шные вещи меньше сталкиваются с реальной жизнью и потому гораздо проще и красивее устроены.
                                        опыт разработчика достаточно универсален
                                        Можете нам набросать модуль быстрой динамики для энергосистем? Всего-то нужно пару сотен тысяч разных (типов силового оборудования не один, да разных автоматик с сотню типов учесть) дифуров считать в темпе реального времени.
                                          +2
                                          Для того и полезен (в моём случае, надеюсь) лидер, не занимающийся непосредственным кодированием.


                                          Это все есть. Есть аналитики, есть руководители направлений… Но когда дело доходит до распределения задач, все упирается в тот же вопрос — «а кто способен решить данную задачу качественно и в срок»?

                                          Чуть ли не самая простая область, повезло :-) Простая в смысле внешних условий, главное — собственно свою часть сделать хорошо (что, конечно, не так просто).


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

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

                                          Можете нам набросать модуль быстрой динамики для энергосистем? Всего-то нужно пару сотен тысяч разных (типов силового оборудования не один, да разных автоматик с сотню типов учесть) дифуров считать в темпе реального времени.


                                          А вот это уже не совсем IT. Это уже комплекс, требующий знания предметной области.

                                          Вам, к примеру, что-то говорит «6-12 ЛД»? :-) А я когда-то давно этим занимался… Молекулярная динамика, машинное моделирование, потенциалы взаимодействия, эффективное сечение рассеяния и т.п. Чтобы этим заниматься нужно еще на минуточку знать курс матанализа, дифуров, уравнений матфизики, статфизику, механику сплошных сред, термодинамику… И поверх всего этого быть еще неплохим разработчиком, умеющим писать быстрый и эффективный код.

                                          Но я о задачах чисто разработки. Что выбрать для построения батчмашины? Сокеты? Пайпы? *DTAQ? В каком случае что будет лучше работать скажем, на платформе AS/400? Что должна делать головная задача, а что отдать на откуп обработчикам? Еще держать в голове, что хотелки заказчика могут поменяться через год (только что с этим столкнулся — то, что удовлетворительно работало несколько лет, начало работать очень плохо после того, как заказчик захотел расширить набор обрабатываемых данных новыми сущностями, а изначальная архитектура задачи оказалась слишком жесткой для такого расширения и все пошло по не так) и нужно сразу закладывать на будущее такую архитектуру, которая предоставит возможности расширения без существенного переписывания кода (ну скажем, меняем только схему обработки одного кванта данных, или меняем только схему отбора квантов из общей кучи, но не меняем способ сбалансированного распределения кантов по обработчикам и систему контроля обработчиков и сохранения целостности данных).

                                          И еще приходится помнить что есть эффективность выполнения нашей задачи и есть еще несколько тысяч других задач, которые тоже в это же время выполняются на это же мейнфрейме и тоже обязаны получит свой кусочек машинного времени — нужно искать баланс между скоростью выполнения и объемом используемых ресурсов. А оптимально — иметь возможность регулировать этот объем хотя бы внешними настройками, меняющимися от запуска к запуску…

                                          Тут очень много вещей, которые нужно держать в голове. Сейчас я с некоторой ностальгией вспоминаю прошлые задачи, где я знал, что моя задача (пусть и работающая в условиях гарантированного времени отклика) была основной и могла брать столько ресурсов, сколько ей нужно. И где можно было сосредоточится только на «быстро», а не балансировать на лезвии между «быстро» и «экономно».
                                            0
                                            Это все есть. Есть аналитики, есть руководители направлений…
                                            Нет, эти слишком отчуждены от разработчиков. Нужен свой, как рулевой в лодке. Не гребёт — но сидит там же и за конкретную лодку отвечает вместе (и больше) с коллективом. Даже картинку вставлю:
                                            image
                                            А вот это уже не совсем IT. Это уже комплекс, требующий знания предметной области.
                                            Именно! В таких областях роль «рулевого» гораздо выше. В чисто айтишных можно без него и обойтись (привлекая образ лодки — и такие есть, парные четвёрки, например, рулит один из гребцов), потому что «очень много вещей, которые нужно держать в голове» — общие для всей команды.

                                            Но — это всё разнится в разных областях, моей — так, в Вашей — эдак. Это не хорошо и не плохо, а просто вот так.
                                              +2
                                              Нет, эти слишком отчуждены от разработчиков. Нужен свой, как рулевой в лодке.


                                              А вот это где как. У нас связка аналитик-разработчик очень плотная. Работа идет в паре и как аналитик может советоваться с разработчиком по поводу архитектуры задачи, так и разработчик советуется с аналитиком по поводу тонкостей реализации тех или иных алгоритмов. Аналитик ближе к предметной области, разработчик — к платформе на которой все это реализуется.

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


                                              Ну чисто айтишных команд я не видел (которые выдавали бы эффективный и востребованный продукт). Это примерно как «а вот напишем-ка вот такую фигню — мы не знает кому и зачем это нужно, просто вот на м в голову ударило. Это провальная позиция — такой продукт на 100% будет неудобен для пользователя т.к. он не учитывает его текущие потребности и не встраивается в его бизнес-процессы.

                                              Любая команда разрабатывает тот продукт, на который есть спрос (на него может не быть конкретного заказа, но неудовлетворенный спрос уже есть). И в любом случае разработка идет от спроса.

                                              Поэтому аналитик должен быть всегда. Тот, кто вникает в потребности потенциального или реального заказчика, его бизнес-процессы и разрабатывает концепцию. А дальше уже вместе с разработчиком разрабатывает конкретную архитектуру и алгоритмы.

                                              Тут возможны вариации в распределении обязанностей, но общая схема примерно такова.

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

                                              Но — это всё разнится в разных областях, моей — так, в Вашей — эдак. Это не хорошо и не плохо, а просто вот так.


                                              Да, согласен.
                                    0
                                    Мне 57, и я фрилансер DevOps. Все больше последние годы чувствую желание уйти от hands-on, но увы — боязно искать и нанимать команду.
                                      0
                                      Мне просто повезло. Сам работал удалённо с американцами. Правда, последние годы уже не фрилансером. Фрилансерство мне вообще не по характеру, даётся тяжело и невыгодно. Работал постоянно в приличной конторе, неплохой проект, неплохая зарплата…
                                      Пока однажды вечером ко мне домой не ввалилась весёлая поддатая компания и позвала в новый проект. Куда с удовольствием, несмотря на двукратную потерю в зарплате, и ломанулся. Повезло.
                                        0
                                        Рад за вас. Я как раз счастлив быть фрилансером — не нужно участвовать в политике, можно работать неполную ставку. У меня есть 1-2 постоянных заказчика на пару дней в неделю каждый.
                                        Но вот гоняться за технологиями я устал, да и скучно 90% быть hands-on.
                                          0
                                          Мне повезло ещё больше!
                                          не нужно участвовать в политике
                                          У нас небольшая частная компания, нет множества этажей управления, соответственно и политики практически нет. Плюс у меня табельный номер 3, и политика мало меня касается.
                                          счастлив быть фрилансером
                                          Это от характера зависит. Мне — никогда не нравилось, ни 20 лет назад, ни тем более сейчас.
                                          гоняться за технологиями я устал
                                          опять же, у нас продукт привязан к реальной жизни и бешеная смена it-поколений нас задевает только косвенно. Какое-то количество молодых набираем постоянно, этого достаточно.
                                    +2
                                    хорошая статья, а вот перевод стоило-бы «причесать»
                                      0
                                      Все в точку, вижу все то же самое в каждой новой конторе.
                                        +1
                                        Вообще 100% попадание. Прямо один-в-один моя ситуация. :)))
                                        +5
                                        С моей точки зрения с возрастом приходит лучшее понимание людей, и из-за этого возникают описанные проблемы, например к тебе приходит заказчик(начальник, сосед, да кто угодно) и просит тебя сделать что-то, ты видишь что с технической точки зрения это глупость(ошибка, неправильность) но также видишь что ему на это наплевать, ему нужно выделиться(подстраховаться, настоять на своем, подставить кого-то), но прямо сказать — это серьезный конфликт, и приходится тыкать носом в технические вопросы человека которому это безразлично, ему то важно совсем другое. И здесь ты либо овладеваешь помимо своей компетенции еще и навыками практической психологии, либо действительно прослывешь старым дураком. А практическая психология ничуть не проще программирования или конструирования
                                          +2
                                          А если человек хочет просто делать любимую работу, без корпоративных игрищ, которые отнимают кучу времени и нервов, и естественно никакого удовольствия не приносят? Или начальник, который со своими игрищами, пытается тобой манипулировать, и никаким win-win не пахнет? Т.е. делать вид, что не понимаешь и ждать, что на тебя вывалят ушат помоев в последствии, но зато ты будешь «свой»? Когда ты раз за разом выворачиваешься из подобных ситуаций, и начальник чувствует себя после этого дураком, то контракт быстро заканчивается.
                                            +3
                                            Я с Вами согласен, я просто имел в виду, что для того, чтобы выкручиваться из подобных ситуаций без ущерба нужно овладеть еще одной компетенцией, а это во первых сложно а во вторых противно
                                              0
                                              Да. Я вашу мысль понял. И я не знаю как этому научится. Но я точно знаю, что если я буду этим заниматься, я буду тратить на «это» больше времени, чем на работу.
                                              Спрашивается, зачем я пришёл на эту работу, если я ею не занимаюсь? Что я тут делаю?
                                              Ситуация проигрышная как для нанимателя, так и для меня. Зато все кто хотел, поиграли в игру престолов, за счёт работодателя.
                                                0
                                                А если еще к этому Вы и эмоциональный человек, то оно как то вообще неинтересно. Так же, как «учить людей жизни».
                                          +8
                                          Возраст под полтинник, шесть лет опыта относительно по делу, некислая самооценка. Конечно, ему трудно.
                                          Upd: и огромная любовь к словоизвержению.
                                            0
                                            так, вроде, человек прошелся по леснице вверх-вниз. А самооценка осталась соответственной верхней точке, как по мне, так правильно все…
                                              +1
                                              Paradigm shift должен случаться не только при переходе на управленческую работу, но и при уходе с нее. Да и не знаем мы, прошелся он вниз, или по ступенькам на заднице слетел. По тону очень похоже, что слетел.

                                              Кстати, в 20 лет он служил в ВВС техником по радарам, ну, или вольнонаемным был, так что лукавит он в статье.

                                              Но пойнт мой в том, что от программиста в его возрасте (он же примерно мой возраст) обычно ждут чего-то большего, чем шестилетний опыт невнятного перебрасывания дерьмокода через забор и пятнадцатилетний опыт командования удаленными индусами. Ну и уж учителем жизни по собственной инициативе вообще не стоит становиться, при любой специальности. Просто продемонстрируй, что жил, а не небо коптил, и к тебе сами придут и попросят жизни научить.
                                                0
                                                Опыт у всех разный но имхо он описал типичнейшую для индустрии ситуацию, все так и есть. острота индивидуальной реакции не делает неправдой все о чем он написал. Его вот раздражает, мне смешно, большинству пофиг. Не надо было ему уходить в individual contributors — как менеджер смог бы эффективней валенками на резинке швырятья в тех кто не так делает ).
                                                  +1
                                                  Большинство людей не годится ни украсть, ни посторожить. В этом плане ситуация типичнейшая. Просто непонятно, возраст-то тут при чем?
                                                  А чувак, конечно, крайне любопытный в определенном смысле. Этнографическом. Ультралевый(на американский манер, конечно же). Думаю, большинство здесь присутствующих тоже показались бы ему антисемитами, женоненавистникам расистами :-) Но, опять же, возраст-то тут при чем?
                                            +3

                                            В маркетинге ситуация 1:1.
                                            Мне сейчас 38 и я понимаю, что хватит меня не долго, максимум до 45.

                                              +1
                                              Ого! А можно примеры, как оно также в маркетинге?
                                              Нет, я подозреваю, что процессы везде похожи, но как там это проявляется? Покупается ненужная реклама за кучу денег вместо нужной, но не такой пафосной?
                                                +7
                                                1. Рекламные площадки Yandex и Google. Это и контекстная реклама и медийная и товарные предложения. Постоянно выходят обновления. Постоянно выходят платформы и сервисы, которые по идее должны упрощать управление рекламой, но в 90% являются шлаком. Но нужно потратить время на изучение сервиса, чтобы понять, что это шлак.
                                                  В том же Google одними только встроенными инструментами можно настроить автоматизацию так, чтобы та или иная реклама показывалась в зависимости от температуры на улице, идёт дождь или снег, либо рассвет или закат.
                                                  А ещё технологии сегментирования, локальный гипертаргетинг и много иной хрени, которая, например, в случае с Яндексом, нихрена не работает так, как должна работать.


                                                2. Реклама в соцсетях: даже если взять основные: vk, face, insta, ok, то в них регулярно обновления. Куча дополнительных сервисов, инструментов, задача которых по идее упрощать работу с рекламой, а по факту 90% из них бестолковые.



                                                В итоге, когда стоит задача настроить рекламу так, чтобы ROAS был свыше 100%, соответственно, нужно глубоко знать бизнес-процессы заказчика, его финансовые показатели и все вместе прикрутить с инструментами метрики, аналитики и рекламными каналами.
                                                И тут возникает вопрос: использовать старые технологии, с которыми знаком, либо сунуться в изучение новых платформ, сервисов, технологий, которые в теории должны дать большую эффективность, позволить получить больше клиентов в рамках существующего бюджета, либо снизить расходы на рекламу, без снижения количества клиентов.
                                                Показывать на сайте заказчика всем один и тот же контент, либо в зависимости от того, с какого рекламного канала пришёл пользователь, сколько ему лет, какого пола, какие интересы, показывать на одной и той же странице сайта другой контент?


                                                А ещё есть технологии отслеживания на сайте пользователя, выявление его потребностей и на следующей странице сайта показывать ему в дополнительных блоках те товары/услуги, которые могут его заинтересовать. Сделать так, чтобы куда бы он ни сунулся в интернете, ему показывались те товары/услуги, которые он потенциально может приобрести.


                                                И если ещё лет 8-10 назад ещё можно было быть универсальным маркетологом, умеющим хорошо работать со всеми каналами интернет-рекламы, то сейчас это уже в принципе невозможно, так же, как и быть универсальным программистом.


                                                И когда кто-то меня спрашивает, чем я занимаюсь, а я отвечаю: «маркетолог», а человек тут же мне задаёт вопрос:
                                                «- а, инстаграм ведёшь?»,
                                                хочется прибить человека нафиг!)

                                                  +1
                                                  И если ещё лет 8-10 назад ещё можно было быть универсальным маркетологом, умеющим хорошо работать со всеми каналами интернет-рекламы, то сейчас это уже в принципе невозможно, так же, как и быть универсальным программистом.

                                                  Не согласен: считаю что универсальным программистом быть возможно.
                                                    0
                                                    считаю что универсальным программистом быть возможно.


                                                    Уверены?

                                                    Вот лично вы что пишете? И на чем?

                                                    Допустим, писали всю жизнь фронт на модных фреймворках. Сколько времени вам потребуется чтобы выйти на тот же уровень, но в какой-нибудь промавтоматизации чтобы писать на С/С++ что-то низкоуровневое на уровне OS API?

                                                    Или забросила жизнь в мир мейнфреймов — IBM i/IBM z, CL/RPG и т.п…

                                                    Про программирование всяких микроконтроллеров где еще и в железе надо неплохо ориентироваться уж молчу.

                                                    И куча специфических областей — нейросети, машинное зрение, гд кроме собственно программирования еще математика требуется.

                                                    Так что насчет «универсального программиста» не согласен. Да, перейти из одной области в другую вполне возможно. Но это потребует некоторого времени (несколько месяцев, год...) для выхода на тот же уровень, который был в предыдущей области.
                                                      0
                                                      Представьте прекрасный мир, в котором для того чтобы пересесть с написания вебфронта на промавтоматику или микроконтроллеры не нужно менять ваш основной ЯП. Представили? Согласитесь, теперь «невозможность существования универсального программиста» уже не выглядит столь однозначно?

                                                      Думаю, примерно к этому индустрия и придёт вместо специализации на железе и среде. Потому что обучение программиста слишком дорого обходится чтобы складывать все яйца в одну нишевую «корзину».
                                                        0
                                                        Представьте прекрасный мир, в котором для того чтобы пересесть с написания вебфронта на промавтоматику или микроконтроллеры не нужно менять ваш основной ЯП. Представили?


                                                        Не могу такого себе представить. Ибо работал в близкой к промавтоматике области (распределенная система мониторинга инженерного оборудования заданий), а сейчас работаю в бэкенде финтеха на уровне ядровых функций АБС на мейнфрейме IBM PowerS9 на платформе IBM i.

                                                        Это настолько разные миры. Там все разное. И требования очень разные. В той же промавтоматике вы не напишете верхний уровень (интерфейсные клиенты) на голом С, но и при этом не запихнете модные фреймворки в промконтроллер на STM32 (который очень ограничен по памяти и процессору, ставить туда что-то мощное — цена на систему взлетит до небес или даже в нашей не очень большой системе количество промконтроллеров измерялась тысячами, в более развитых системах это десятки и сотни тысяч узлов и даже экономия в стоимости одного узла на 5-10 долларов уже очень ощутимо сказывается на цене всей системы).

                                                        Думаю, примерно к этому индустрия и придёт вместо специализации на железе и среде. Потому что обучение программиста слишком дорого обходится чтобы складывать все яйца в одну нишевую «корзину».


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

                                                        И я не могу себе представить «универсальный ЯП», который одинаково хорошо подходил бы как для коммерческих вычислений (например, нативная поддержка типов и арифметики с фиксированной точкой), так и для прямой работы с железом (порты, регистры и т.п.). Также нет единой платформы, которая была бы оптимизирована как для работы в режиме реального времени (а большинство задач промавтоматизации именно так и работают), так и для минимизации накладных расходов (скажем, переключения контекста) при одновременном выполнении десятков тысяч заданий на одном сервере.
                                                          +1
                                                          И я не могу себе представить «универсальный ЯП», который одинаково хорошо подходил бы как для коммерческих вычислений (например, нативная поддержка типов и арифметики с фиксированной точкой),
                                                          Эти (и ещё тыща других штук) не нужны когда есть шаблоны и интроспекция.
                                                          так и для прямой работы с железом (порты, регистры и т.п.). Также нет единой платформы, которая была бы оптимизирована как для работы в режиме реального времени (а большинство задач промавтоматизации именно так и работают), так и для минимизации накладных расходов (скажем, переключения контекста) при одновременном выполнении десятков тысяч заданий на одном сервере.
                                                          Звучит как описание языка D (dlang.org)
                                                            0
                                                            Эти (и ещё тыща других штук) не нужны когда есть шаблоны и интроспекция.


                                                            Да? И как шаблоны помогают сходимости рекуррентного соотношения Мюллера?

                                                            В теории многие вещи выглядят красиво и изящно. Пока дело не доходит до суровых реалии жизни и практического применения.

                                                            Звучит как описание языка D (dlang.org)


                                                            Наверное. Мы использовали обычный С (кросс-компилятор для STM32) и вполне успешно.

                                                            Но пусть будет D. А теперь скажите — можно его портировать на AS/400 (чтобы компилятор генерировал TIMI код) и работать с ним с БД DB2? Можно в него (прямо в код) встраивать SQL команды и получать результат SQL прямо в коде? Поддерживает он генерацию operational descriptors для аргументов функции?

                                                            А как у него с HTML?

                                                            Боюсь, что всего этого нет. Т.е. микроконтроллеры на нем программировать можно, но вот сайт уже не напишешь и на банковский сервер тоже ничего не напишешь…

                                                            И так со всеми языками. Каждый имеет свою область применения и свои особенности. А создание «универсального ЯП» — это утопия. Как и универсальной платформы на все случаи жизни.

                                                            НА тех же промконтроллерах даже операционка зачастую не нужна. Там постоянно крутится одна задача — обтряхнуть порты и выкинуть результат наверх (в другой порт). И даже на верхнем уровне там не так много задач крутится.

                                                            А в банке на сервере одновременно тысячи процессов работают. Это совсем другой коленкор. Там скорость переключения контекста между процессами уже может катастрофически влиять на производительность.
                                                              0
                                                              можно его портировать на AS/400 (чтобы компилятор генерировал TIMI код) и работать с ним с БД DB2?

                                                              Без понятия, но он может использовать LLVM в качестве бэкенда и соответственно компилироваться во всё, что умеет LLMV.


                                                              Можно в него (прямо в код) встраивать SQL команды и получать результат SQL прямо в коде?

                                                              Можно.


                                                              Поддерживает он генерацию operational descriptors для аргументов функции?

                                                              Не понятно, что это.


                                                              А как у него с HTML?

                                                              Всё с ним хорошо.


                                                              сайт уже не напишешь и на банковский сервер тоже ничего не напишешь

                                                              Вполне себе напишешь и даже понравится.

                                                                0
                                                                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 Например, имеем

                                                                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);

                                                                Это чисто системная вещь на платформе где «все есть объект» на уровне ОС. Т.е. любая переменная это не просто кусок памяти, но объект, имеющий некоторый набор свойств (тип, размер...), которые мы можем получить.

                                                                Сама процедура — это тоже объект, получающий в качестве аргументов список других объектов.

                                                                И вот зачем мне какой-то монструозный «универсальный ЯП», когда я могу использовать несколько специализированных ЯП для построения одной программы?
                                                                  0
                                                                  operational descriptors это такая хитрая системная штука. Если включить их генерацию, то внутри функции можно получить информацию о любом ее аргументе.

                                                                  А, compile time reflection? В D оно, конечно, тоже есть.


                                                                  И вот зачем мне какой-то монструозный «универсальный ЯП», когда я могу использовать несколько специализированных ЯП для построения одной программы?

                                                                  Чтобы не тратить такты на интеркоммуникацию. Все эти "процедура как объект" сильно ограничивают компилятор в возможностях оптимизации.

                                                                    +1
                                                                    Чтобы не тратить такты на интеркоммуникацию. Все эти «процедура как объект» сильно ограничивают компилятор в возможностях оптимизации.


                                                                    Вы не поняли. Это суть 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. Тут финтех — базы, обработка данных и т.п.

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

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


                                                                      Накладные расходы тут есть по следующим причинам:


                                                                      1. В разных языка разный набор идиом. Если какой-то идиомы в каком-то языке нет или она устроена иначе, необходимы адаптеры или конвертация данных.


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


                                                                      3. Для компилятора код на другом языке является чёрным ящиком, который он не то что заинлайнить, а даже просто сделать какие-то предположения о его ограничениях не может (например, что функция чистая или что объект безопасен для межпоточного взаимодействия).


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

                                                                        Есть концептуально цельные платформы. Где все эти моменты продуманы разработчиками.

                                                                        Почитайте вот на досуге — многие вопросы отпадут сами собой. Но там много. ILE Concepts
                                                                          0

                                                                          По настоящему другой язык, а не только с чуть иным синтаксисом, вы в ILE не утромбуете.

                                                                            0
                                                                            «По настоящему другой» — это как?

                                                                            Я дал Вам ссылку — потрудитесь ее прочитать. Хотя бы основы.

                                                                            Для 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)…
                                                                              +1
                                                                              Для ILE достаточно чтобы стыковался порядок передачи параметров в стеке.

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

                                                                    0
                                                                    LLMV у нас нет. Зато есть ILE — интегрированная языковая среда.
                                                                    Все компиляторы (CL, C/C++, COBOL, RPG) являются частью системы.


                                                                    Вам хватает 4 компиляторов для всего? А если Rust или Go нужно использовать то что делать?
                                                                      0

                                                                      Вы сначала почитайте про мейнфреймы IBM, пожалуйста. А потом вернитесь к своему вопросу и попробуйте понять, что с ним не так

                                                                        0
                                                                        Я знаю про мейнфреймы. Но что не так с моим вопросом?
                                                                  0
                                                                  Можно в него (прямо в код) встраивать SQL команды и получать результат SQL прямо в коде?

                                                                  В более общем виде это называется «интерполяция строк».

                                                                  То есть, во всех языках, куда это завезли так сделать можно. В D не завезли пока что, хотя обсуждение ведётся.

                                                                  Я для этого в настоящее время использую обычный генератор SQL, в принципе всё устраивает и без интерполяционного сахарка.
                                                                    0
                                                                      +1
                                                                      В более общем виде это называется «интерполяция строк».


                                                                      Нет. Это сложнее. Там специальный препроцессор. Он добавляет в код SQLCA (SQL communication area) и SQLDA (SQL descriptor area) которые используются при построении динамических параметризированных запросов с использованием хост-переменных как на вход, так и на выход. В результате там получается на 100% полноценный SQL внутри кода — сколь угодно сложные запросы, вызов встроенных процедур (кстати, ваша программа тоже может использоваться как встроенная процедура в SQL), курсоры (в том числе и двунаправленным перемещением вперед-назад, блочным чтением в массив), резалтсеты (ваша программа может возвращать наверх резалтсет) и еще очень много всякого сахара.

                                                                      И поверх всего еще оптимизатор отрабатывает.

                                                                      Так что это очень сильно не «интерпретатор строк». Он позволяет в программе «на лету» сформировать SQL строку, из нее создать курсор, открыть его, читать данные и тут же их как-то обрабатывать.
                                                                        0
                                                                        Нет. Это сложнее. Там специальный препроцессор.

                                                                        Да. В других языках (с интерполяцией) он базируется на ней. У меня в D он даже отработает во время компиляции.

                                                                        Так что это очень сильно не «интерпретатор строк».

                                                                        «Интерполяция строк»

                                                                        Он позволяет в программе «на лету» сформировать SQL строку, из нее создать курсор, открыть его, читать данные и тут же их как-то обрабатывать.

                                                                        Да, всё верно, это можно делать на любом языке где есть шаблоны и интерполяция.
                                                                      0
                                                                      Да? И как шаблоны помогают сходимости рекуррентного соотношения Мюллера?
                                                                      Они позволяют спрятать реализацию всякой хитрой арифметики в библиотеке и использовать её где угодно без оверхеда, хоть в веб-сервере хоть в контроллере.

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


                                                                        А при чем тут оверхед?

                                                                        dcl-s fVar float(8); // обычный float
                                                                        dcl-s pVar packed(15:2); // десятичное с фиксированной точкой, аналог DECIMAL в SQL
                                                                        dcl-s zVar zoned(15:0); // еще один вариант десятичного с фиксированной точкой, аналог NUMERIC в SQL

                                                                        и где тут оверхед?

                                                                        Больше скажу — эти типы объектов на данной платформе поддерживаются на уровне самой системы (т.е. работа с ними идет ниже SLIC). Так что любые шаблоны и библиотеки по сравнению с этим — это уже оверхед
                                                                          0
                                                                          Я говорю об аналогичном отсутствии оверхеда в любом ЯП где есть нормальные шаблоны.

                                                                          Больше скажу — эти типы объектов на данной платформе поддерживаются на уровне самой системы

                                                                          Что делать если будут введены новые типы? Переписывать спецификацию языка и компилятор? Какой-то порочный подход.

                                                                          Так что любые шаблоны и библиотеки по сравнению с этим — это уже оверхед

                                                                          Это заблуждение.
                                                                            0
                                                                            Что делать если будут введены новые типы? Переписывать спецификацию языка и компилятор? Какой-то порочный подход.


                                                                            Какие новые типы Вы можете придумать? Они все будут базироваться на ограниченном количестве уже существующих. Чем, собственно, и занимаются шаблоны (которые суть просто мнемоника для «нового типа»).

                                                                            Вот дополните набор типов чем-то принципиально новым, тем, что нельзя описать в рамках уже существующего:

                                                                            целое (знаковое или беззнаковое, разной длины)
                                                                            с плавающей точкой (знаковое, беззнаковое, разной длины)
                                                                            с фиксированной точкой (знак, длина, количество знаков после запятой)
                                                                            строка (как массив символов, одно- или двухбайтовых).

                                                                            Все, что Вы придумаете будет производным от этих базовых типов и описываться ими. Тот же varchar, к примеру, это просто структура содержащее целое (фактическая длина) и строку.
                                                                            Или bool в С++ — это тот же int (а на платформе AS/400 это системный объект, называемый «индикатор» и и являющийся 1 символом со значениями '1' — *on или '0' — *off)

                                                                            И никаких новых типов уже не будет. И никакого переписывания компилятора тоже.

                                                                            Ваша проблема в том, что вы не видети дальше (глубже) ЯП и фреймворка. Тут уже приводился пример что такое «базовое образование» —

                                                                            Хорошая «база» выстраивает в мозгу нейросеть, которая выучена оперировать сложными причинно-следственным связями (приблизительно говоря, «когда я нажимаю на педаль газа, она тянет тросик, который поворачивает залонку в карбюраторе, в результате чего изменяется состав поступающей в цилиндры двигателя газовоздушной смеси, в результате чего та начинает взрываться сильнее, в результате чего образовавшиеся газы начинают толкать поршни сильнее, в результате чего увеличивается вращательное усилие на оси, в результате чего согласно закону F=M*а увеличивается ускорение, в результате чего машина начинает разгоняться (до тех пор, пока возросшие силы трения и сила сопротивления воздуха не скомпенсируют эту возросшую силу) и будет ехать бытрее»). А без базы возможно только выученное «нажал педаль — машина едет быстрее» — а почему, они не знают: наверное, по волшебству.


                                                                            Так вот по Вашим рассуждениям видно, что все, что глубже уровня ЯП и фреймворка с шаблонами для Вас сплошная «магия». Хотя на самом деле все это опирается на набор системных API, а они, в свою очередь, на возможности той платформы, на которой все это работает. И не понимая как устроена платформа, Вы никогда не напишете действительно эффективный код.

                                                                            За сим прощаюсь. Дальше уже неинтересно становится.
                                                                              +1
                                                                              Какие новые типы Вы можете придумать? Они все будут базироваться на ограниченном количестве уже существующих.

                                                                              Да нет же! У нас в компиляторах, которые не покрылись мхом, есть intrinsics, которые позволяют нам использовать преимущества любой архитектуры на полную. Пусть хоть в ней будут 3-битные float реализованы.

                                                                              Когда оппонент отвечает только на удобные ему сообщения то, действительно, неинтересно.
                                                                                0
                                                                                Вот дополните набор типов чем-то принципиально новым, тем, что нельзя описать в рамках уже существующего

                                                                                BitArray

                                                                                  0
                                                                                  Все, что Вы придумаете будет производным от этих базовых типов и описываться ими.

                                                                                  Я могу, конечно, сказать, что всё в конечном счёте будет представляться битами, но это деструктивный подход.


                                                                                  Как вы опишете в рамках своих типов, например, ассоциативный массив (он же hash map, он же dictionary, он же unordered_map)? Его свойства не укладываются ни в один из этих базовых типов, а отличия достаточно принципиальны, чтобы работать с ним совсем иначе и думать в первую очередь о проблемах распределения ключей, ресайза, правильности хэширования и отсутствия конфликтов между хэш-числом и равенством. Или его регулярный компаньон map (с упорядочением ключей)...


                                                                                  Кстати, вообще-то, ни обычного массива, ни его обобщения в виде универсальной последовательности (названный вами же result set вы будете представлять в виде числа или строки?), ни структуры (​C​) / записи (Pascal) у вас нет (а одна строка result set это у вас что, текстовая строка?), несмотря на то, что каждый вводит новое качество… вы уверены в своих громких утверждениях?


                                                                                  Ваша проблема в том, что вы не видети дальше (глубже) ЯП и фреймворка.

                                                                                  Кажется, вам самое время посмотреться в зеркало и оценить, насколько вы заклинились в мышлении на фреймворке под названием AS/400 и его специфике. И как при этом даже в его пределах вы упускаете принципиальное, что в нём уже есть — как те же последовательности структур.


                                                                                  Раньше вас читать было полезно, но тут вы грубо и тупо перегнули палку.


                                                                                  За сим прощаюсь. Дальше уже неинтересно становится.

                                                                                  :))

                                                                                    0
                                                                                    Как вы опишете в рамках своих типов, например, ассоциативный массив (он же hash map, он же dictionary, он же unordered_map)?


                                                                                    Точно также, как он описывается в любом фреймворке, где он существует.

                                                                                    Написать реализацию таких «типов» можно на любом языке. С той или иной степенью эффективности и удобства.

                                                                                    Когда Страуструп придумывал С++ никаких мапов и хешей там не было. Сейчас есть stdlib (и прочие фреймворки и библиотеки) где все это реализовано.

                                                                                    У меня есть свои «типы» — SkipList, Set, написанные на С++ и используемые в программах на RPG. Которые позволяют мне мыслить в рамках примитивов с определенными свойствами, не задумываясь (уже) о том, как эти примитивы реализованы внури.

                                                                                    Но все это не является базовыми типами. Все это опирается на некоторый набор базовых типов + комплекс доступных операций над ними.

                                                                                    Я могу, конечно, сказать, что всё в конечном счёте будет представляться битами, но это деструктивный подход.


                                                                                    Это не деструктивный подход. В конечном итоге все сводится к битам. С той или иной степенью эффективности.

                                                                                    названный вами же result set вы будете представлять в виде числа или строки?


                                                                                    ResultSet это, вообще-то, из SQL. Когда некоторая процедура возвращает не значение, а выборку (фактически это аналог SELECT, но реализованный в виде процедуры с достаточно сложной внутренней логикой). Более того, такая процедура может вернуть не одну выборку (resulset), а несколько — 2, 3, 5…

                                                                                    Кажется, вам самое время посмотреться в зеркало и оценить, насколько вы заклинились в мышлении на фреймворке под названием AS/400 и его специфике.


                                                                                    Это не фреймворк. Это платформа. Состоящая из железа и ОС. А привожу ее в пример потому что она очень сильно отличается от привычного мира Win и *nix. Я бы сказал радикально отличается. Во всем.

                                                                                    А рассказываю про нее тут исключительно с целью (отмотайте назад) дать пример того, что универсальный язык (фреймворк, платформа) невозможны. Каждый из них создавался для максимально эффективного решения определенного круга конкретных задач. Где он будет действительно хорош. Но в других задачах он не будет так хорошо потому что не предназначен для них.
                                                                                      0
                                                                                      Написать реализацию таких «типов» можно на любом языке. С той или иной степенью эффективности и удобства.

                                                                                      Можно. Но если вы будете на этом писать такие базовые средства, то их эффективность будет заметно ниже, чем при реализации на языке, на котором пишется сама реализация VM (скорее всего это таки C).


                                                                                      Но я в основном не об этом, а о том, что вы в своём полемическом задоре упустили даже банальный массив. А, ну ещё и объектные ссылки, которых может быть тоже несколько видов (уже деление на сильные и слабые ссылки достаточно важно для такой среды).


                                                                                      Когда Страуструп придумывал С++ никаких мапов и хешей там не было. Сейчас есть stdlib (и прочие фреймворки и библиотеки) где все это реализовано.

                                                                                      В случае C++ мы имеем дело с мультипарадигменным языком, который позволяет всё вплоть до прямого доступа к железу. Сравнение с ним тут некорректно. Сравнивайте с JVM или дотнетом.


                                                                                      Это не фреймворк. Это платформа. Состоящая из железа и ОС. А привожу ее в пример потому что она очень сильно отличается от привычного мира Win и *nix. Я бы сказал радикально отличается. Во всем.

                                                                                      Да, отличается. Но для 90% точности для тех, кто в Windows и Unix, подходит описание в виде: единая JVM/.NET растянутая на весь компьютер (виртуалка-LPAR, где есть), с разделением прав и защитой доступа, готовыми библиотеками для БД и объектным хранилищем вместо FS с теми же правами, и с половиной терминов заменённых на локальные IBMʼовские мемы.


                                                                                      Различие платформа/фреймворк тут неважно для всех, кроме админов и узкой прослойки системщиков; остальным пофиг, будет эта среда одна на машине или их несколько, будет она на спец. железе или это будет специализированный сервер на банальном x86, и так далее.


                                                                                      дать пример того, что универсальный язык (фреймворк, платформа) невозможны

                                                                                      Верно. Но дальше вы начинаете доказывать универсальность в пределах этой платформы — и вот тут уже начинаются некорректные упрощения. Например, если потребуется ограничить допустимость инстанциации какого-то шаблона типами с определённым свойством, вы не сможете протащить определение такого шаблона между разными языками. Если будет введён hash map на уровне рантайма, вам его придётся описывать раздельно для каждого языка. А если кто-то захочет притащить на AS/400, например, Idris, ему придётся повторить и всю логику языка, и проекцию на специфический рантайм.


                                                                                      А вот эта реплика вообще была непонятна:


                                                                                      А как у него с HTML?

                                                                                      У вас в ILE прямая работа с HTML, или как? Если нет — то какая разница, пока язык умеет работать со строками и с сокетами?

                                                                            0
                                                                            Боюсь, что всего этого нет. Т.е. микроконтроллеры на нем программировать можно, но вот сайт уже не напишешь и на банковский сервер тоже ничего не напишешь…

                                                                            И так со всеми языками. Каждый имеет свою область применения и свои особенности. А создание «универсального ЯП» — это утопия. Как и универсальной платформы на все случаи жизни.

                                                                            А Раст?)))

                                                                        0
                                                                        Индустрия к этому уже приходила. Ну, так многим казалось, во всяком случае. И даже не раз. IBM/360, потому что 360 градусов, платформа для всего вокруг. PL/I, потому что первый язык воистину программирования, все можно написать, не переучиваясь. Ну и дальше по списку и википедии. А мы, однако, все там же все с теми же обсуждениями :-)
                                                                          0
                                                                          Возможно, на тот момент не было достаточно серьёзной необходимости в этом — программисты были дешевле, а кода было мало.

                                                                          Сейчас, когда дефицит кадров и зарплаты выросли в разы такая необходимость назрела и нам начали завозить такие языки. (И системы сборки всего этого, кстати! Cм. «The Meson Build system».)
                                                                            +1
                                                                            IBM/360, потому что 360 градусов, платформа для всего вокруг.


                                                                            Потом она стала еще более вокруг (IBM/370) и совсем вокруг (IMB/390) пока наконец не отребрендилась в IBM z.

                                                                            И параллельно с ней развивалась другая платформа: System/36 -> System/38 -> Advansed System (AS)/400 -> IBM i. Которая не похожа вообще ни на что в плане архитектуры (это объектная система — там все есть объект). Я ее тут привожу в пример именно потому что она вообще не вписывается ни в какую «универсальность»

                                                                            А мы, однако, все там же все с теми же обсуждениями :-)


                                                                            Ну приходит новое поколение и им кажется, что вот они-то уж точно философский камень откроют.
                                                                              0
                                                                              Которая не похожа вообще ни на что в плане архитектуры (это объектная система — там все есть объект).

                                                                              Что не мешает программировать её на универсальном и «вражеском» языке C. (Он вообще из другой экосистемы изначально.)

                                                                              Я ее тут привожу в пример именно потому что она вообще не вписывается ни в какую «универсальность»

                                                                              См. выше.
                                                                                0
                                                                                Что не мешает программировать её на универсальном и «вражеском» языке C.


                                                                                Да нет, как раз здорово мешало.
                                                                                  0
                                                                                  Но, обратите внимание — сдохли мейнфреймы, а не C.
                                                                                    +2
                                                                                    Они не сдохли, они превратились из общеупотребительного инструмента в нишевое решение. То же самое, в общем, случилось и с Си. И то же самое случится и с остальными «универсальными языками» и вообще «универсальным» всем. Это случилось даже с материально-технической базой построения коммунизма :-) Люди склонны изобретать новые потребности, которые авторам разных панацей даже в голову не приходили.
                                                                                      0
                                                                                      На TIOBE C стабильно входит в тройку самых популярных языков. А вот мейнфреймы сдохли вполне неиллюзорно.
                                                                                        0
                                                                                        Да, я тоже прочитал только что опубликованную на хабре статью :-) В которой призывается мой любимый Си наконец убить :-) Но популярность это же не то же самое, что универсальность. А Ваш изначальный пойнт был именно в универсальности. Вообще, TIOBE же «is not about the best programming language or the language in which most lines of code have been written». Ну и были времена, когда Visual Basic был самым популярным языком в мире. И что?
                                                                                          0
                                                                                          Может, неверно сформулировал.

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

                                                                                          Это ровно тот подход, который критикуется в обсуждаемой тут статье, кстати.

                                                                                          А вот опровергнуть возможность универсальности не вышло, эти вопросы были просто проигнорированы.

                                                                                          В которой призывается мой любимый Си наконец убить :-)

                                                                                          Принесу канистру бензина к костру Си :-)
                                                                                          Попробуйте Dlang betterC — вам понравится!
                                                                                            0
                                                                                            А вот опровергнуть возможность универсальности не вышло,


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

                                                                                          Ну как сказать. При известной точке зрения можно считать весь датацентр целиком одним таким большим мейнфреймом.

                                                                                        +2
                                                                                        Не сдохли. Просто если раньше это был основной инструмент — в отсутствие персональных ПК люди были вынуждены работать в терминальном режиме на мейнфреймах, то сейчас это специализированный инструмент для решения тех задач, которые требуют одновременной работы множества процессов. И их архитектура строится таким образом, чтобы минимизировать накладные расходы при переключении контекста процессоров (та же перезагрузка сегментных регистров)

                                                                                        А так они более чем живы — 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 и еще у кого-то…

                                                                                        Понятно что это не массовое решение. И недешевое. Это не масс-сегмент ни в железе ни в разработке. Но «слухи об их смерти сильно преувеличены» (с)
                                                                                          0
                                                                                          Сдохли.

                                                                                          То что ошмётки где-то ещё теплятся ни о чём не говорит. Иначе получится что и Кобол не сдох, и любые вообще языки никогда не умрут. Как латынь.
                                                                                            0
                                                                                            С латынью хороший пример. Она мертва в том смысле, что дети уже не учат ее сами по себе, общаясь с родителями. Но совсем не так мертва, как ее сосед этрусский, про который мы только и знаем, что он был, и буковки похожие.
                                                                                              0
                                                                                              Угу. Только не все об этом знают. Но Вам виднее, конечно.
                                                                                                0

                                                                                                Ну вообще-то это преувеличение. Сдохло то, что не развиваются. Обе эти специфические IBMʼовские линии развиваются и даже задумчиво растут в количестве (точных цифр у меня нет, но я оцениваю на глаз и наугад парк обеих в 30000 установок по миру). Количество же людей, которые с ними плотно работают, надо считать ну например 10 на каждую. Это таки очень много.


                                                                                                Но вот принципиальная нишевость — фактор, который никуда не девается — более того, её устранение явно не входит в планы IBM...

                                                                                        0
                                                                                        System/36 -> System/38 -> Advansed System (AS)/400 -> IBM i.


                                                                                        Там еще iServer вроде в цепочке был. Но я как раз тогда уже окончательно от этой темы отключился.
                                                                          –1
                                                                          Спасибо за интересную статью!
                                                                            –1
                                                                            Странная вещь, я за свою многолетнюю практику допаивания того, что кодеры криво недописывали в ассемблере, к своему полтиннику все же психанул, и построил свой No code, котором всегда, мечталось. Кодеры лбы рассекают ударяясь о невидимую грань того, что в ближайшие 10 лет может посадить их на забор. По сути есть лопата, которой в разы удобней и быстрей можно копать на приисках с вполне добротной продуктивностью в сравнении с классическими методами разработки в Real time.
                                                                            Тем не менее я в полном тупике как дальше с этим поступать не имея стратегии разворачивания продукта. По ходу здесь дело не в возрасте…
                                                                            +2
                                                                            Какой-то неумный (и неуместный) поток сознания; видимо, автор проводит куда больше времени, сочиняя идиотские «эссе» (не могу назвать это эссе в прямом смысле; это лишь болезненный «поток сознания»), нежели чем программируя.

                                                                            Мне 51 год, у меня есть все, положенное для данного возраста, а, возможно, и чуть больше: отличная семья с чудесными детьми, прекрасный (и уже выплаченный) дом, долговременные инвестиции на $500K+, «дежурные» 100 штук на savings-е (на всякий случай). И я по прежнему, как и раньше, очень люблю программировать, кодировать, возиться с «железом»; выше этого в приоритетах (из хобби) только чтение. И у меня нет проблем с заключением контрактов даже в это трудное время на $100/h и выше, но, помимо, я еще и делаю скромные «халтурки» на UpWork, неа небольшие суммы (<$1000), just for fun (ну, и тоже небольшой доходец).

                                                                            «Стариком» себя не ощущаю от слова «вообще», и вовсе не собираюсь им становиться. Я в курсе «модных, молодежных трендов» (хотя отнюдь и не следую им), и могу еще поучить «современному мышлению» или применению agile in real life любого «миллениала» (ой, а какие тупые идиоты попадаются, трудно представить или даже поверить!).

                                                                            P.S. Речь идет о США (как и у этого Эдама Дэвиса).
                                                                              +9

                                                                              У вас такая же нога и не болит, верно?

                                                                                +1
                                                                                Именно. И эта неболящая нога — отличный контрпример к статье с заголовком «я уже…, или почему всем… ».
                                                                              +2
                                                                              Если честно, перевод ужасный, меня аж укачало, не возможно дочитать до конца
                                                                                0
                                                                                Черт его знает. С одной стороны, я 25+ лет в профессии; но с другой, код, написанный тогдашними 40-45-летними во времена, когда я только начинал, не может заставить меня усомниться в определенном рациональном зерне эйджизма :)
                                                                                  +1
                                                                                  Но ведь тогдашние 40-45 летние это те кто программировал в НИИ СССР майнфреймы на перфокартах и они был больше математиками, чем программистами. Да собственно вся профессия кардинально поменялось.

                                                                                  Это как квантового физика заставить переучится на фронтенд программиста — с большой вероятностью он будет программировать фигово (но вот физиком может быть очень хорошим).
                                                                                    0
                                                                                    Тем любопытнее после 60 будет послушать мнение о себе со стороны нынешнего молодняка. Профессия-то, как мы видим, крайне нестабильная во взглядах на то, что такое модно.
                                                                                      0
                                                                                      Это как квантового физика заставить переучится на фронтенд программиста
                                                                                      Я работал с китайским Ph.D. в физике (ранее работавшим в CERN на LHC, под руководством своего учителя, Нобелевского лауреата), переквалифицировавшегося в IT (он был у нас project manager/team lead/senior software engineer и «затычка за все про все»), так вот, со 100% «вероятностью» программировал он отлично! Хорошая «база» значит очень много, вероятно, «миллениалам» и «жертвам ЕГ» просто не понять.
                                                                                        0
                                                                                        Хорошая «база» значит очень много, вероятно, «миллениалам» и «жертвам ЕГ» просто не понять.


                                                                                        Соглашусь. Сам по образованию физик. Физтех. Еще «тот», советский, доЕГЭшниый, минсредмашевский. Физмат база часто помогала. Да и мозги неплохо выстроили. Несмотря на то, что ITшного образования тогда не было — два семестра «вычтехники» (писали что-то на бланках на Fortran IV, относили на ВЦ, потом забирали распечатки выполнения на ЕС-1033) ну и потом курсовой считали на Искра-1256…
                                                                                          +1

                                                                                          Хорошая "база" выстраивает в мозгу нейросеть, которая выучена оперировать сложными причинно-следственным связями (приблизительно говоря, "когда я нажимаю на педаль газа, она тянет тросик, который поворачивает залонку в карбюраторе, в результате чего изменяется состав поступающей в цилиндры двигателя газовоздушной смеси, в результате чего та начинает взрываться сильнее, в результате чего образовавшиеся газы начинают толкать поршни сильнее, в результате чего увеличивается вращательное усилие на оси, в результате чего согласно закону F=M*а увеличивается ускорение, в результате чего машина начинает разгоняться (до тех пор, пока возросшие силы трения и сила сопротивления воздуха не скомпенсируют эту возросшую силу) и будет ехать бытрее"). А без базы возможно только выученное "нажал педаль — машина едет быстрее" — а почему, они не знают: наверное, по волшебству.

                                                                                      0
                                                                                      Но они не хотят вашего отзыва. Они хотят, чтобы вы кивнули и сделали всё, что они просят.

                                                                                      Знакомая ситуация: "Мы не хотим говорить тебе что делать, иначе это снизит твою мотивацию, но результат твоего анализа не соответствует нашим ожиданиям, вникать в детали анализа мы не хотим".


                                                                                      Менеджеры говорили мне в обзорах эффективности, что со мной «трудно работать».

                                                                                      То же знакомая ситуация: "Ты не идёшь на компромис. Потому что сделал не всё так, как я хотел, хоть я и не настаивал."


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

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

                                                                                        0
                                                                                        Вот я так думаю, если ты такой Эдам Дэвис умный, почему, к своим годам, что есть богатство, не накодил свою курочку Рябу, несушку золотых яиц, а сидишь и опусы строчишь. Видать такой ты посредственный был такой кодер, который никогда, как настоящий художник, не мечтал создать свой The Dark Side of the Moon.
                                                                                        И зря ты во всех своих проблемах старости ты обвиняешь свой опыт. Здесь полное противоречие. Вершин с неба не хватал, променял веселую жизнь кодера на администратора, учеников и последователей не взрастил, своего чего-то выдающегося не создал, теперь вот сыплешь пеплом седую голову…
                                                                                        0
                                                                                        Выходит я старый(((
                                                                                        В 40 уже старый…
                                                                                          +1

                                                                                          Как я понял, автор пишет о том что ему не нравится:
                                                                                          1) когда им манипулируют
                                                                                          2) когда игнорируют его профессиональное мнение.
                                                                                          Вряд ли это кому-то нравится. Мне точно нет. И чем старше — тем сильнее.

                                                                                            0
                                                                                            От статьи осталось четкий привкус: «все пид******, а я Д'Артаньян».
                                                                                            Человек не умеет работать в коллективе, одиночка. Возможно специалист, но скорее всего не такой крутой, как сам себя хвалит.
                                                                                            Если ты не спец-круче всех, тогда не бывать тебе Д'Артаньяном :) Поэтому и менеджмент особо не ценит.

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

                                                                                            Этот человек родился не в той стране. Явно видно, что этот человек в душе из страны советов.
                                                                                            «Я хочу всем советовать как надо делать, но при этом ни хочу ни за что отвечать» это ж прям классика русскоязычных форумов. Где каждый как минимум физик-ядерщик, профессор медицины и профессиональный разработчик в одном лице.
                                                                                              0
                                                                                              Возможно специалист, но скорее всего не такой крутой, как сам себя хвалит.


                                                                                              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. » — и это все о нем. Точнее, это он о себе. На советской интеллигентской кухне он бы прижился, это точно.
                                                                                              +1
                                                                                              Сегодня моя реакция на этих людей всегда одна и та же. Я вежливо их выслушиваю. Даю любую немедленную обратную связь, которая может помочь правильно направить их. Но, как только они хотят подтолкнуть меня к тому, чтобы я выполнял работу — вне нормального конвейера разработки, — я вежливо, но твёрдо отказываюсь.

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

                                                                                                Процессы тут (i.e. «там» — то-бишь у нас, в США; впрочем, как, наверное, и у вас) организованы (а, порой, и дезорганизованы) по «очень разному», но в данном конкретном случае речь идет лишь о субъективном восприятии этих процессов бездельником и лузером, который, впрочем, считает себя «талантливым разработчиком», так, что можете списать это на «словонедержание» данного «характерного экземпляра» ;)
                                                                                                0
                                                                                                Недавно у меня была работа, где несколько руководителей были откровенными, неистовыми расистами. И женоненавистниками. И антисемитами

                                                                                                То есть, у автора была отличная работа с великолепными, думающими СЕО, не прогнувшимися под всякие левые ценности, но автору больше по душе BLM? Я полагаю, с этого и надо было начинать статью — тогда многие здравомыслящие люди попросту не стали бы ее читать.
                                                                                                  +2
                                                                                                  Как сказал один умный человек «как только я исключил понятие „совесть“ из рабочих отношений — я стал работать вдвое меньше, а зарабатывать втрое больше».
                                                                                                    +1
                                                                                                    Я не совсем согласен. Совесть терять не надо. Самоуважение, да и репутация в конце концов. Но упомянутое в статье «взятие на слабо», энтузиазм, и прочие эмоции — однозначно вон!
                                                                                                      0
                                                                                                      Ну речь идет скорее про взятие на слабо и обещание призрачных перспектив в обмен на ненормированную работу (не подкрепленные пунктами контракта), а не про то, чтобы вести себя как свинья. Вести себя всегда нужно профессионально и корректно.

                                                                                                      Однажды мне при увольнении не выплатили отпускные и просто отправили в игнор. Очень вежливый емейл с указанием нарушенных пунктов контракта и законов и копией владельцу конторы решил вопрос мгновенно :)
                                                                                                        +1
                                                                                                        Вести себя всегда нужно профессионально и корректно.

                                                                                                        Абсолютно согласен. Я насчет фразы — ИМХО надо исключить не совесть, а наивность и прочий энтузиазм.
                                                                                                    0
                                                                                                    Потому что некоторые глупости, с которыми я сталкиваюсь ежедневно, иногда вызывают у меня сильную депрессию.


                                                                                                    Рекомендую книгу «Тонкое искусство пофигизма» должно стать чуть проще.

                                                                                                    Когда я был помоложе, я делал свои скудные предложения. А иногда клиенты даже слушали. Но если они полностью игнорировали меня, мне было всё равно. Я просто делал всё именно так, как просили клиенты.

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


                                                                                                    Вообще, общение разработчика напрямую с клиентом не самый лучший вариант. Опытного BA бы туда, его работа выделить нужное и отсеять не нужное. А Разработчик должен качественно реализовать требования. Всем было бы проще.

                                                                                                      0
                                                                                                      Меня тоже удивил этот фрагмент в конце. Человек говорит что у него много опыта и управленца и кодера, при этом жалуется на то, что его нанимая кодером требуют выдать код, а все свои гениальные идеи и виденье — придержать. Помоему опытному специалисту должно быть это привычно и очевидно. Взяли повара ватрушки печь — пеки ватрушки и не лезь меню составлять. Хоть тебе и кажется будто в чайнатауне лучше воки делать вместо ватрушек.
                                                                                                        0

                                                                                                        Потом к тебе же придут и скажут: ваши ватрушки недостаточно похожи на воки, мы вас брали как специалиста, а не тупого исполнителя, если видели, что ватрушки тут не уместны, то почему не сделали ватрушки со вкусом вока?

                                                                                                    Only users with full accounts can post comments. Log in, please.