Это сложная тема, которая периодически всплывает в среде IT-специалистов, об этом сказано уже немало, а вот для «неайтишников» многое может оказаться новостью. Как для тех, кто хочет «войти в IT», так и для тех, кто по роду своей деятельности вынужден работать вместе с IT-службами. Некоторые вещи будут очевидны для IT-специалистов, но не очевидными для других. Иногда из-за их непонимания люди допускают болезненные ошибки. Не только и не столько со своей карьерой, сколько в своём бизнесе делают ставку не на тех людей. Поэтому давайте разберём этот вопрос без эмоций и на понятном для неспециалистов языке.
Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний. Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Один из идеологов концепции IT~BP (партнёрство между IT и бизнесом).
Неверно было бы полагать, что дело в «молодости» области информационных технологий. Это не правда. Знаете, первое поколение программистов уже давно умерло от старости. Многие профессиональные программисты уже вышли на пенсию. Если вам хочется глубоко погрузиться в прошлое, то посетите страничку Владимира Орлова и прочитайте его статьи:
Владимир Орлов - это тот человек, который учился у первых программистов, а сейчас он пишет статьи о своём более чем пятидесятилетием опыте в отрасли. Разве можно называть такую область «молодой»?
Широко известная книга Фредерика Брукса «Мифический человеко-месяц, или Как создаются программные системы» издана в 1975 году и содержит ранее опубликованные журнальные статьи автора. Брукс родился в 1931 году, он ещё жив, сейчас ему 91 год.
Неверно было бы сказать, что область информационных технологий стала популярной лишь недавно. 10 марта 2000 года лопнул пузырь доткомов, в результате чего по мировой экономике был нанесен мощный удар. Еще в 90-е года XX-века рынок информационных технологий был перегретым.
Неправдой является и то, что это просто российский рынок является молодым. Нет, у нас все так же, как и у других. 6 декабря 2016 года Don Denoncourt написал статью On Getting Old(er) in Tech (доступна в переводе Как стареть в IT). 18 мая 2021 года Anupam Chugh написал статью When Do Programmers Retire? Is 35 the End? (доступна в переводе 35 лет – конец карьеры? Когда программисты выходят на пенсию?).
Тезис о том, что все дорастают до руководящих должностей, не выдерживает никакой критики. Дело даже не в том, что управление людьми - вещь непростая, так ещё руководящих должностей на всех не хватит.
Так в чём же дело? Неужели действительно в возрасте? Нет, не в нём. Всё дело в профессиональном выгорании. Программистом можно стать («войти в IT») и после 40 лет, вопрос лишь в том, сколько лет вы сможете продержаться.
Что же происходит и в чём дело?
Нужно постоянно учиться
В области информационных технологий, как в сказке про Алису в стране чудес, нужно очень быстро бежать, чтобы оставаться на месте. А если хочешь куда-то попасть, то надо бежать ещё быстрее. Вообще IT - это злая, жестокая и выматывающая сказка.
Работа в области информационных технологий - это не спринтерский забег, это марафонская дистанция. Нельзя просто взять и ворваться в IT. Лет через 5-10 ваши навыки и достижения обесценятся. Бежать придётся не только быстро, но и долго.
В IT вообще всё быстро меняется, появляются новые технологии, уходят старые технологии. Сегодня востребовано одно, завтра другое. Честно говоря, профессиональный программист может изучить новый для себя язык (близкий по стеку) за 2-4 недели. То есть через месяц человек выйдет на производительность среднего разработчика, но уже на новом языке.
На примере нашей компании. Как-то мы решили, что наши бэкенд разработчики (разработчики серверной части web-приложений) должны владеть PHP и Python одновременно. На освоение нового языка мы им давали как раз 2 недели.
Наши фронтенд разработчики (разработчики клиентской части web-приложений) все умеют разрабатывать на Flutter. То есть они умеют писать кроссплатформенные мобильные приложения (сразу под Android и под iOs). Flutter - хорошая технология, теперь у нас в компании нет разработчиков мобильных приложений на нативных языках (Java, Kotlin, Object-C, Swift), они проиграли конкуренцию по скорости и стоимости разработки.
Конечно, это не значит, что нативной разработки завтра вообще не станет. Иногда, но далеко не каждый день, нужно писать сложные приложения, где без нативных средств совсем никак, но такие задачи встречаются нечасто. Мобильное приложение обычной сложности можно написать и на Flutter. А простое - вообще без услуг программиста. В какой-то момент окажутся востребованы только самые сильные разработчики мобильных приложений на нативных языках, остальным придётся куда-то уйти.
Скажем честно, постоянно делать инвестиции в самообучение выходит не у каждого. Легко учиться, когда тебе 16-20 лет, затем учиться все тяжелее и тяжелее. В какой-то момент начинаешь замечать, как люди разделяются на тех, кто может постоянно переучиваться, и тех, кто начинает сдавать, не выдерживая темп.
У бегунов на марафонскую дистанцию есть понятие «марафонская стена». Это эффект, который происходит где-то на 25-30 километрах. В этот момент у организма исчезает вся энергия и многие люди останавливаются, не в силах преодолеть эту «стену». Эффект во многом психологический, физиологически же организм просто переходит с расщепления гликогена на расщепление жиров.
Вот в IT есть свой аналог «марафонской стены», когда человек её достигает, у него погасают глаза. Эффект тоже лишь психологический, дело не в «старости мозга». Посмотрите на учёных, мозг у них прекрасно работает до 60-90 лет, пока в целом организм не начнёт отказывать.
В качестве лирического отступления о психологии профессиональных IT-специалистов. Мы с моим коллегой по старой работе, как-то решили поучаствовать в туристической прогулке на 100 км за 24 часа. Мероприятие не очень сложное, нести с собой нужно было только воду и репеллент (шли по лесу вокруг города), каждые 25 км был привал, где нас кормили и можно было сойти с дистанции. Выходишь в субботу утром, приходишь в воскресенье утром.
Пошли мы без подготовки, как и многие другие. В целом, дистанция посильная для любого физически здорового человека. Только нужно психологически преодолеть себя. На 50-м километре у моего коллеги от ходьбы начало сильно болеть колено, поэтому следующие 50 километров он проделал лёгким бегом с той же скоростью, с какой я шёл. В прогулке с нами участвовал клуб альпинистов, в какой-то момент ребята начали употреблять обезболивающие. Последний их них потерялся где-то после 75-го километра. Я сам неверно подобрал обувь, пошёл без пластыря, стёр одну ногу в кровь, больно, конечно, было. Вопрос об остановиться мы как-то даже не рассматривали.
До финиша дошли лишь представители туристического клуба-организатора и мы вдвоём с коллегой. В понедельник я встал (достижение) и поехал (ещё большее достижение) на работу. Коллега отработал понедельник в удалённом режиме, встать не получилось.
Хотите в IT? Пробегите марафон. Именно такая психология у профессиональных «программистов». Понадобится.
По правде говоря, область информационных технологий в этом не уникальна. Хорошие врачи тоже учатся целую жизнь, учёные - тоже. Я всё ещё веду научную работу (численное моделирование сопряженного свободноконвективного теплообмена), поэтому могу сказать, что в научной среде тебя всегда окружают старые люди, а в IT - молодые. Барьер один и тот же, просто в IT есть постоянный приток новых людей, а в науку - нет.
Много случайных людей
Скажем прямо, у IT-специалистов хорошие доходы, это привлекает в отрасль множество людей. А их всё равно не хватает. Тут бы в пору заподозрить неладное и подумать почему так, но этим обычно мало кто себя обременяет.
Раньше это был поток в основном молодых людей, сейчас молодые закончились (кроме шуток, 90-е года XX века дают о себе знать), перешли на более старшие возрастные категории. Поэтому стали появляться истории про людей, которые «вошли в айти» после 40 либо даже 50 лет. Это возможно, но войти мало, нужно ещё и задержаться.
Когда я ещё учился в университете, на нём была программа «Программист за 1 год». Ежегодно профессиональную переподготовку проходило множество людей, которым рассказывали азы программирования. Но рынок ими почему-то не насыщался. Люди приходили на рынок, а потом куда-то исчезали с него.
Сейчас ситуация усугубилась. Появилось множество онлайн-школ, которые обещают, что через 6-9 месяцев обучения человек будет востребован в IT, после чего будет получать 100-200 тысяч рублей оклада в месяц. Их даже учат правильно составлять резюме и проходить собеседования.
Как-то мне наши рекрутеры сказали, что просмотрели где-то 600 (!!) откликов на вакансию, провели несколько первичных собеседований, но до второго этапа никто не дошёл. Причина - выпускники онлайн-школ.
Да, у нас несколько строже отбор, чем в крупные компании. Но сейчас 2022 год, год перемен, в который крупные компании «режут косты», то есть сокращают бюджеты на IT, причём резко и заметно.
Честно говоря, в отрасли давно знают непрофильные специальности, которые легко конвертируются в IT-специалистов. Это математики, физики, радиотехники и несколько иных направлений. В основном инженерные и естественнонаучные дисциплины, где у людей развивают системное мышление. Дефициту IT-специалистов же не один десяток лет, многие варианты уже перебрали.
Это новую технологию можно изучить за 1-6 месяцев, а вот системному мышлению приходится учиться 5-6 лет в университете. Быстрее не получается.
И тут надо было бы спросить, а зачем отрасли столько «случайных» людей? Всё просто, для выполнения несложных работ и участия в стартапах за небольшие (сравнительно) деньги. Пока у человека ещё горят глаза и не закончился энтузиазм. Помним, что спринтерскую дистанцию каждый пробежит с первого раза, а десяток километров - нет.
Есть ещё одна причина - эмоциональное выгорание, но об этом после.
Область информационных технологий жестока, если нового человека хватит на 5-10 лет рядовой работы, то почему бы нет? Кстати, именно с такой частотой в IT происходят кризисы, которые подчищают рынок. Чуть более подробно этот вопрос рассмотрен в статье «Саморегуляция в ИТ: минимально допустимая эффективность работы» (на Habr её ещё не публиковал).
Автоматизация
Знаете, очень интересная вещь. Программисты многое делают, чтобы автоматизировать свой труд, то есть чтобы было нужно как можно меньше программистов.
Хорошим примером является реализация информационных сайтов. Раньше для этого нужен был программист, а то и коллектив программистов. Нужно было вручную сделать вёрстку сайта, реализовать серверную часть, присоединить первое ко второму.
Потом появились MVC-фреймворки, которые давали каркасы web-приложений. Для реализации сайта стало хватать одного «full-stack» разработчика. То есть один человек делал серверную и клиентскую часть.
Затем пришли CMS (сontent management system - система управления содержимым). Для того чтобы создать сайт не нужно было заниматься программированием, хватало конфигурирования.
А под конец пришли сервисы типа Тильды. Это конструкторы сайтов, которыми могут пользоваться непрограммисты. Например, UI/UX специалисты уже могут создавать там новые шаблонные блоки, не прибегая к помощи разработчиков. А простой сайт может сконструировать из готовых блоков любой человек.
Куда делись те люди, которые ещё недавно разрабатывали сайты за 5 тысяч рублей на потоке? Правильно - были вынуждены искать новую работу.
Во многом аналогичное сейчас происходит с интернет-магазинами. Это несложная шаблонная работа, которую можно автоматизировать.
Кроме того, сейчас начали набирать популярность сервисы NoCode и LowCode, которые позволяют создавать несложные мобильные приложения в визуальном редакторе. Чуть поподробнее в «No-Code и Low-Code. Взгляд инженера и бизнесмена» (на Habr её не публиковал).
То есть сама отрасль лишает свой хвост работы, отбрасывая его. Очень плохая идея оказаться в хвосте. Это тоже сытая жизнь, только не очень надолго.
Крупные компании и устаревшие технологии
Здесь есть место для конфликта интересов IT-специалистов и крупным бизнесом. Первым нужно не отстать от рынка, для этого нужно постоянно бежать. Вторым нужно сокращать свои операционные и капитальные затраты. Бизнес не заинтересован в постоянном внедрении новых технологий. Бизнес заинтересован в технологических платформах, которые будут работать 10-20 и более лет. Стоимость внедрения новых платформ - очень большая.
Иногда бывают курьёзные случаи. Те, кто остаются в IT надолго, рискуют продолжить работать до самой смерти. В конце XX века всплыла «Проблема 2000 года», много программного обеспечения было неготово к работе после 2000 года. В том числе и банковского программного обеспечения разработанного на языке Cobol. Язык создан в 1959 году, программистов на нем мало. Пришлось привлекать к разработке даже тех людей, кто на тот момент были в домах престарелых. Самое смешное, что и в 20-х годах XXI века подумывают о программистах Cobol из дома престарелых.
Мне самому приходилось работать на старой и очень живучей платформе разработки систем документооборота. Шутки про Cobol у нас были скорее грустные, а не смешные. Мы понимали, что нас может ожидать.
То есть работа в крупной компании либо государственном секторе может обернуться для IT-специалиста застоем в освоении новых технологий и отставанием от отрасли на 10-15 лет. Это очень большая дистанция, при этом есть риски, что одним рывком её преодолеть будет невозможно.
Но это же и средство «консервации» IT-специалистов. Главное, чтобы от твоего технологического стека (набора) не отказались, когда тебе 40-50 лет. Сильные разработчики быстро переучатся на новый стек технологий, а другие уйдут с рынка.
Нужно любить своё дело
Невозможно выдержать длительную профессиональную гонку, когда не любишь то, чем занимаешься. Для тех людей, что представляют из себя профессиональное ядро отрасли, информационные технологии - это не только и не столько источник дохода. Это возможность самореализовываться в любимом деле.
Скорее всего, у таких людей будет профильное образование, либо близкая к профильной специальность. Хорошее образование и фундаментальная подготовка позволяют человеку понимать, что развитие технологий происходит по спирали. Концептуально разницы между мейнфреймом с терминалами и тонкими клиентами с облаком не так уж и много.
При достижении определённой глубины понимания отрасли, гонка технологий перестаёт быть гонкой, уходит необходимость постоянно переобучаться. Остаётся только любопытство и тяга к новым знаниями и инструментам, которые позволяют оставаться востребованным до конца своей трудовой жизни.
Именно эти люди решают сложные инженерные проблемы, создают новые технологии и методологии. Их мало, но именно в их присутствии IT начинает работать эффективно и надёжно, как хорошо отлаженный механизм.
Вместе с плюсами такая любовь к своему делу несет и большие риски. Если такой человек начинает заниматься никому не нужно работой, когда результатами его труда перестают пользоваться люди, наступает быстрое эмоциональное выгорание. Такие люди не смогут работать в стол.
Поэтому их редко можно увидеть в стартапах. Если человек в десятый раз делает новую социальную сеть, которая никогда не запустится, не потому, что она плохо написана, а потому, что она никому не нужна, и его всё устраивает, то это явно какой-то другой человек. Профессионал, скорее, реализует конструктор социальных сетей и будет продавать его, как услугу, любителям стартапов, чтобы они могли проверять свои гипотезы самостоятельно.
Конечно, иногда профессионалы участвуют в стартапах, но чаще они приходят в них, когда бизнес-идея подтвердилась и нужно строить устойчивое и гибкое технологическое основание.
Все мы понимаем, что торговать своей любовью долго не получится, даже за большие деньги.
Подводя итоги
На рынке информационных технологий одновременно присутствуют долгоживущие профессионалы и люди, которые попали в отрасль «случайно». Плюс некоторая прослойка, которая пришла в отрасль молодой, но не выдержат длительной гонки.
Если вы небольшой стартап и вам нужны люди ненадолго, то вам подойдут любые специалисты. Если вам нужны представители профессионального ядра отрасли, то внимательно посмотрите в глаза человека. Насколько они у него горят? Насколько он любит (по-настоящему) то дело, которым занимается? Как долго он сможет «бежать»? Насколько то, что вы делаете, интересно этому человеку? Ему тоже в это придётся вкладывать душу.
Помните, что дело не в возрасте. Человек может состояться, как профессионал и в 25-27 лет. Их просто нужно уметь отличить от тех, кто через 10 лет сойдёт с дистанции. Вообще, в области информационных технологий очень много психологии и технологий социальных. Это иная (скрытая) грань отрасли.
Что до вопроса, куда исчезают программисты после 40 лет? Профессионалы остаются востребованными и после 50-60 лет. Чаще всего это люди, которые очень глубоко понимают свою область, среди них много старших разработчиков и технических лидеров. Таких людей никогда не было много, рынок ими не перенасытится никогда. Некоторое число людей отрасль отдаёт на руководящие должности. Кадровый кризис в области руководства ещё более острый, чем среди IT-специалистов.
А остальные сходят с дистанции, кто-то совсем уходит из отрасли, кто-то продолжает работать в крупных и государственных организациях, выполняя несложную работу и получая оклад ниже средней по региону. То есть перестают соответствовать мифу о высокооплачиваемых и сверхвостребованных IT-специалистах, которые могут работать удаленно из любой точки мира.
Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.
Комментарии (214)
vdudouyt
29.10.2022 09:03+14Неверно было бы полагать, что дело в «молодости» области информационных технологий. Это не правда. Знаете, первое поколение программистов уже давно умерло от старости. Многие профессиональные программисты уже вышли на пенсию.
Так изначальный тезис, вроде бы, был о существенно меньшей распространенности IT-технологий 20-30 лет назад, а не о полном их отсутствии. И примеры Брукса или академика Ершова его никак не опровергают.
А под конец пришли сервисы типа Тильды. Это конструкторы сайтов, которым могут пользоваться непрограммист. <...>
Куда делись те люди, которые ещё недавно разрабатывали сайты за 5 тысяч рублей на потоке? Правильно - были вынуждены искать новую работу.
Перешли на Тильду. Я серьезно.
P. S. Так и не смог найти в статье ответа на вопрос, который содержится в ее заголовке. Senior COBOL developers из дома престарелых можно считать разве что только контрпримером :)
anka007
29.10.2022 10:22+6Да там и дальше можно продолжать разбирать по всем пунктам.
Нужно постоянно учиться: так программисты в этом совсем не уникальны. Врачам, ученым, юристам и многим другими профессиям тоже надо постоянно учиться, однако это не является поводом уйти из других профессий после 40.
Крупные корпорации с устаревшими технологиями: так как раз возможность взять паузу в такой сложной для автора гонке обучения не уходя из профессии, наоборот там рады тем кто за 40.
Нужно любить работу: ну так здесь разница только в том, что видимо айтишнику чуть проще сменить род деятельности, чем токарю. Может это кризис среднего возраста виноват, а не айти?
А как люди, проработавшие почти 20 лет могут быть случайными в профессии я не поняла. Случайными сорокалетними могут оказаться те, кто туда решил заглянуть в 35+. Ну так они в этом мало отличаются от тех, кто начал в 20, это не от возраста зависит.
aamonster
29.10.2022 12:17+4Айтишнику сменить род деятельности психологически сложнее, чем во многих других профессиях: скорей всего, это приведёт к сильному проседанию по зарплате, немногие готовы, особенно после 30-40.
anka007
29.10.2022 13:50+1А другие делают накопления для пассивного дохода и "ранней пенсии". Все же в нашей сфере мало кто живет от зарплаты до зарплаты, и накопить "подушку" на год нормальной жизни, пока идет становление в новой сфере более чем реально.
Source
30.10.2022 02:44+1Так изначальный тезис, вроде бы, был о существенно меньшей распространенности IT-технологий 20-30 лет назад, а не о полном их отсутствии.
В этом и есть ответ. Серьёзно. 10 лет назад о 30-летних программистах говорили в таком же контексте, как сейчас о 40-летних. Представьте, как тяжело было начать заниматься программированием в 90-х, когда компьютеры были роскошью, а интернета, можно сказать, вообще не было.
С удешевлением компьютеров и распространением интернета (довольно доступным он стал во второй половине нулевых) количество программистов увеличилось на порядки. И представителям этой первой массовой волны сейчас как раз где-то от 30 до 40 лет. И да, примерно половина из них это физики, математики и инженеры, по образованию с IT не связанные. В этом автор статьи прав.
PuerteMuerte
30.10.2022 09:46+4В 90-е годы начать заниматься программированием было куда легче чем сейчас. Не было развесистого древа технологий, где не знаешь, за что хвататься. Не было кучи библиотек для каждой платформы, и в целом онлайн для развития был не нужен. В 90-е годы ты выбирал язык программирования (что чаще всего означало "сложный" выбор между С++ и Паскалем/Delphi), потом покупал одну толстую книжку по выбранному инструменту, и по окончании прочтения в принципе уже мог что-то делать и даже продать. Естественно, не серьёзным компаниям, но и покупатели тогда были ничуть не избалованы навороченным софтом. Они зачастую были рады и консольной утилитке, которая при запуске делала какую-то нужную рутинную работу для них.
Source
30.10.2022 12:46+1По-моему вы с нулевыми путаете. Я по такому алгоритму в 2004-м начинал (с Delphi и C++, без доступа к интернету).
А в 90-х самым сложным был шаг - купить компьютер. Самый простенький PC стоил примерно 15 средних зарплат, т.е. около 1 млн рублей в пересчёте на текущие цены.
PuerteMuerte
30.10.2022 13:38+7В нулевых уже было куда больше вариантов - тут и веб-разработка, PHP, JavaScript, собственно Java уже была популярной, набирал обороты дотнет и т.д. Вы в 2004-м году начинали с Delphi, а я уже заканчивал, т.к. клиенты хотели дотнета, а восьмая Delphi под дотнет была совершенно невразумительной.
В 90-е я учился программировать на "Поиске" за сто баксов. Туда не поставишь Delphi, но все более-менее актуальные средства разработки под DOS, которая была актуальна чуть ли не до конца 90-х, там работали. Даже худо-бедно ворочались самые последние версии Борланд Паскаля и С++. И эта машинка была доступна, по сути, практически любому студенту-айтишнику. Ну или как вариант, почти любой советский х86 также годился, но у Поиска был бонус в том, что это конструктор, который можно было покупать по частям, как бюджет позволял.
Source
30.10.2022 14:06До веб-разработки дело только в 2006 году дошло, когда стало по карману покупать 100 Mb трафика в месяц)
а восьмая Delphi под дотнет была совершенно невразумительной
Это да. Ещё и C# Builder был))
В 90-е я учился программировать на "Поиске" за сто баксов.
Я даже не слышал про такое. Откуда он у вас появился? У нас в школе были Агаты, но они как-то не вызывали желания что-то подобное заиметь.
funca
30.10.2022 15:28+1Мне кажется у каждого свой инфопузырь, определяемый локальными условиями. В 2001 моя первая работа была связана с развитием Delphi+JS+IIS ASP, где в десктопные приложения встраивалось, как бы сейчас сказали web view (IE5 как компонент ActiveX). В 2003 бекенд переписал на LAMP и предпринимал попытки переделать формы Delphi на TCL/TK. В обоих случаях я не угадал, куда через 20 лет повернется индустрия. :)
Source
30.10.2022 21:02+2Мне кажется у каждого свой инфопузырь, определяемый локальными условиями.
Да, пожалуй, так и есть. Не было глобализации и массовости, поэтому у каждого был свой уникальный путь.
В обоих случаях я не угадал, куда через 20 лет повернется индустрия. :)
Ну, ставки на 20 лет - это дело неблагодарное. Впрочем, я пару лет работал на LAMP, а в 2008 году поставил на Ruby и эта ставка вполне успешно сыграла. В 2016-м поставил на Elixir. С ним не всё так бомбезно, как с Ruby развивается, но технология зрелая и качественная, так что в целом тоже не прогадал.
PuerteMuerte
30.10.2022 15:47+3Я даже не слышал про такое. Откуда он у вас появился? У нас в школе были Агаты, но они как-то не вызывали желания что-то подобное заиметь.
Поиск - это, как по мне, был самый распространённый советский x86 компьютер (тогда это называли "IBM-совместимый"). Он был жутко медленный, но при этом дешёвый, в базовой комплектации стоил как хороший Спектрум. Я просто купил его на радиорынке за 60 баксов у какого-то мужика (там было несколько "точек", где торговали именно Поисками и модулями расширения к ним), и через пару месяцев отдельно дисковод к нему.
До веб-разработки дело только в 2006 году дошло
Ну а как же хардкор - диалап, хомяк на народ.ру или геоситиз? :)
WVitek
30.10.2022 22:56+1В гор. Уфа "Поиски" продавались в ТЦ "Башкирия" в том же отделе, где и телевизоры. Самые крутые модели были с 286 процессором и EGA-видеокартой, но мне покупали, вроде в 1994 году, минимальный "Поиск 1.06" из позднесоветских комплектующих, он почти совместим был с PC XT и CGA-видеоадаптером, но без аппаратного знакогенератора, так что текстовый режим был весьма уныл))
Поскольку собирали их в Киеве, то клавиатура имела расширенную украинскими символами Ґ, Ї, Є кириллицу.
Дисковод тоже докупили позже отдельно, и тогда у меня появился доступ к Turbo Pascal 5.5 (можно сказать, ранний прародитель Delphi) и Turbo Assembler.Позже уже, когда на втором курсе универа учился, полноценный ПК взяли на CPU AMD 5x86. Обошелся он, вроде в 1996г, примерно в $1000, отцу за доллары и продали в магазине (но формально принимали только рубли)).
MixaSg
30.10.2022 17:48+7Не совсем так. Я покупал первый PC 17 августа 1998, за 500 баксов, из них половина рублями по курсу 6 рублей, просто приехал на Царицынский рынок прям к открытию и успел затариться. Выходя с коробками, видел мужика который несся по рядам и орал, чтоб никто ничего не продавал. То был P-200MMX, HDD 1,2 Gb, 16 RAM, S3Trio 64v+. Вполне рабочая машина. Оклад у меня был тогда 600 рублей - 100 баксов. В 2000 оклад у меня был 3000 - 80 баксов :)
Stanislavvv
30.10.2022 22:37+2Купить готовый - да. А собрать по частям - без проблем. Если не гнаться за последними пентиумами - максимум полгода (проверено личным опытом). Самая дорогая часть - монитор, могла быть заменена на какое-то время простой схемкой-переходником и телевизором (опять же опыт из 90-х).
addewyd
31.10.2022 13:56Да ладно… в90х я уже 3 компа сменил (ес184… ес1842 с винтом и цга) и к 2000 у меня уже 486 был, за 1000 баксов покупал, точно помню. Инет уже был кое-какой, и фидошный узел вовсю крутился. И да, где в 2000 я его и забросил (
K0styan
31.10.2022 11:10Тогда и пользователей - потенциальных покупателей - было сильно меньше. В моей институтской группе в 2000-м компьютеры дома были примерно у половины. Это в техническом вузе.
rukhi7
31.10.2022 15:34Так и не смог найти в статье ответа на вопрос, который содержится в ее заголовке
Смотрите глубже: я не смог найти даже обоснования корректности вопроса. На какую статистику опирается автор утверждая что после 40 какие то специалисты пропадают?
anonym0use
29.10.2022 10:13+33> Лет через 5-10 ваши навыки и достижения обесценятся. Бежать придётся не только быстро, но и долго.
Да, все предприятия возьмут и выкинут дружно всё что писалось до этого 20-30 лет на Java|C# чтобы переписать на очередной модный фреймворк(нет)
Rezzet
29.10.2022 11:50+46Работаю уже лет 20(с первого курса) и подхожу к заветной точке 40+, так вот первым моим языком был С++, первым большим фреймворком был Qt, не поверите, но все что изучал еще в школе до сих пор вполне актуально. А самое главное без этого не строится ни один большой проект, автор работает в очень специфичной сфере, судя по примерам, веб-сайты, интернет магазины, мобильные приложения на Flutter, это очень маленькие проекты, это даже не программы в полном смысле, аналоги сайтов визиток популярных в начале 2000. Напишите пожалуйста хотя бы мессенджер без с++ или натива. Только нет вот это я тут взял фреймворк где за меня разрабочики фреймворка прикрутили webrtc сделали обертки в js и меня вот звонок уже идет. Нет, сделайте хотя бы звуковой кодек без си/с++. Про всякую пену типа флеш, электрона, теперь флуттер, слышу уже много лет, сколько работаю столько и слышу. Ну и как программировал UI на Qt, так и программирую. Конечно все эти модные штуки возьмут себе какое-то место под солнцем, хотя флеш вроде сдулся совсем, но с++ никуда не денется очень, очень много времени. А самое приятное что можно вообще не тратить время на новое разрабатывая на с++, ну к примеру появился std::thread, но что системные потоки перестали работать? появилось время можно посмотреть новый стандарт, не появилось пиши как раньше, работать не перестанет. И по перфу готов на с++/qt соревноваться с любой модной штукой. И самое что интересное, уверен в том что на с++ и qt будет реализована любая сколь угодно сложная задача в полном объеме и не упрусь в технологию, в крайнем случае пойду дергать нативное апи системы, будь то андроид, winapi или ios.
"теперь у нас в компании нет разработчиков мобильных приложений на нативных языках" это означает что вы можете решать класс задач только тот который дает флуттер и не больше, обсер произойдет сразу как понадобиться работать с камерой и выжимать перф для нейросетей.
lexa
29.10.2022 12:21+23Коллега, я вот пишу на С++ уже более 30 лет и с ним случилась нехорошая метаморфоза: из достаточно простого и понятного С-с-классами получился чудовищно сложный, перетяжеленный язык, попытки исправить который делают только хуже (по причине возрастания сложности языка). Понятно что причина в legacy, код 30-летней давности должен собираться и работать.
Не знаю что с этим делать, замены C++/Qt действительно не вижу на сегодня, может быть плохо смотрел. Но она точно вот уже нужна.Rezzet
29.10.2022 13:07+7Мы используем из нового просто и понятное: optional, atomic, thread, filesystem, лямды, с новым стандартом появились хорошие библиотеки, например magic_enum. Вроде Rust развивается активно. С++ хорош тем что вокруг него есть миллиард библиотек и он работает почти везде.
lexa
29.10.2022 13:29+6Из C++ (текущего) вполне можно вырезать "простое и понятное", ну в некоторых пределах. Правда в разных случаях (командах, компаниях) эта вырезка будет сильно разной, то есть когда к вам приходит новый сотрудник - он будет долгое время переключаться на ваше, отчего будут всякие (решаемые) проблемы.
Проблема C++ в том, что сам язык слишком сложный, во всей его полноте его мало кто знает: для этого нужно прочитать и понять текущий (используемый) стандарт и все предыдущие и понимать чем вызвано конкретное изменение. Это делают не только лишь все, как следствие - знание языка у (большинства/всех) членов команды - фрагментарное и фрагменты эти не совпадают.
Причем, эта проблема ("слишком сложный язык") уже и 20 лет назад была, а с тех пор многократно усугубилась.Rezzet
29.10.2022 14:14+12Своей команде позволяю писать как хотят, мне все равно, могу читать почти любой код в любом стиле, друг друга пока понимаем, код ревью вести не сложно. Но люди особо и не пишут ничего сложного, никто не рвется писать трехэтажные шаблоны. Сам стараюсь писать максимально просто, остальным то же рекомендую. Когда долго программируешь все равно приходится лезть в чужие библиотеки и так или иначе в них разбираться, со временем становится все равно на код стайл и гайдлайны. Скажу крамольную вещь, у нас сейчас команда 10+ программистов и даже кодстиля нет ), когда приходят новички по началу спрашивают про код стиль, говорю пишите примерно как в коде написано, ну и как-то нормально. На мой взгляд самый лучший способ разработки это не мешать бюрократией и проектировать постфактум, перед реализаций быстро прикинул что как, обсудил минут за 10, потом когда уже функциональность написана и ее много, вот тогда делать проектирование и рефакторить. То есть условно процесс разработки можно построить на два этапа, первый это говнякать прототип, который может и в релиз уйти, а потом уже систематизировать написанный код, уже зная как он работает и какую задачу решает, систематизировать. Причем эти два процесса должны идти все время, так лично по моему опыту получается лучше и быстрее разрабатывать даже достаточно крупные штуки. Беда начинается когда менеджеры вмешиваются и не дают проводить систематизацию: "ну оно же не привезет новых функций зачем работу делать". Более того слишком большое проектирование вначале как правило заканчивается овериндженерингом, а самое неприятное что в процессе реализации как правило приходит понимание что не учли, но так ТЛД уже написано начинают костылить и получается по качеству примерно то же самое что просто наговнякать, все равно набор подпорок и костылей. Так давайте говнякать сразу а потом уже сделаем начисто.
Это все звучит очень спорно и вразрез с общепринятыми подходами, возможно оно работает только у меня и еще у пары коллег, а у других такой подход работать не будет.
lexa
29.10.2022 14:44+6Я не про говнякать и не про "проектировать постфактум". Наговнякать несложно.
Я именно про язык C++: он слишком сложный и его никто не знает на самом то деле. В этом проблема.
А наговнякать я могу и на фортране-4.
semennikov
29.10.2022 19:31+1Ну на Фортране это еще не показатель. А вот на Forth да с обратной польской нотацией :-). Впрочем я конечно стебусь.
Любой язык это прежде всего инструмент, и точно также как и с реальным инструментом плохо забивать гвоздь отверткой (но можно!) или завинчивать шуруп топором(а вот это не пробовал, но думаю что получиться)
victor_1212
29.10.2022 21:17+1> Я именно про язык C++: он слишком сложный и его никто не знает на самом то деле. В этом проблема.
начиная с C++11 вероятно можно было бы назвать "D", Stroustrup касается этого слегка, личной точки зрения не имею (дело не в названии), но такое мнение существует,
см.
lexa
30.10.2022 09:28Оторвать совместимость со старым кодом, остальное подчистить - будет так то неплохо. Но нет
YDR
31.10.2022 09:38я поддержу, сначала тоже пишу прототип, понимая, что все равно его переделывать. Для начала должно заработать, и нужно определиться, какие фичи нужны, а какие отпадут. Нет смысла проектировать, например, ГУИ на бумаге, проще сразу в коде.
Или прототип на python, а к 2-3 переписыванию - на C+Qt (но это будет лень)
кодстайл у вас просто описан в виде примеров. Повезло, что все пишут примерно одинаково.
Единственное - я не программист... По крайней мере, ищу скорее работу инженера-разработчика, инженера-исследователя, и чтобы не просто программирование, а с физикой, математикой, hardware, ... .
Тоже 40+, начинал в том числе с ассемблера 8080.
0xd34df00d
29.10.2022 19:45+5К сожалению, не получится взять из стандарта только optional, atomic и прочие variant, но не брать кучу UB и возможностей выстрелить себе в ногу.
checkpoint
29.10.2022 23:03-1Если Вы пишите многопоточный код, то пользуйтесь POSIX thread-ами и mutex-ами (напишите к ним простую обертку) вместо atomic, thread и прочих модных нововведений языкаю, и Вы никогда не выстрелите себе в ногу. А еще лучше не использовать нитей вообще. Запускайте процессы обработчики задач и организуйте диспетчерезацию заданий между ними. Этот старый дедовский метод прекрасно работает по сей день. Более того, он делает программу простой и понятной.
0xd34df00d
29.10.2022 23:36+6std::{atomic,thread,etc} куда лучше (и, кстати, безопаснее — как мне заблочить сразу несколько мьютекстов на pthreads в гарантированно одинаковом порядке?), но дело даже не в этом.
Можете сказать, не глядя в стандарт, нужно ли инициализировать переменную
xв коде ниже, или это UB?int x; memcpy(&x, src, sizeof(int)); if (x > 42) ...Запускайте процессы
Ух ты, прям питоновское отношение к производительности. Не ожидал такое от C-отцов!
Более того, он делает программу простой и понятной.
Простой и понятной программу делает STM, а не ковыряние мьютексов или методов синхронизации между процессами.
checkpoint
29.10.2022 23:54Можете сказать, не глядя в стандарт, нужно ли инициализировать переменную
xв коде ниже, или это UB?Если Вы работаете на симметричной многопроцессорной системе со строгой (strong) моделью памяти, то Вам ничего делать не нужно. Если же у Вас модель памяти слабая (weak), то потребуется барьер типа StoreLoad. Как это делается в "модных плюсах" я не знаю и знать не хочу. Могу сказать как это сделать на асcемблере для ARM.
Простой и понятной программу делает STM, а не ковыряние мьютексов или методов синхронизации между процессами.
Какие мьютексы и синхронизация в однопоточной программе ? Всё, что Вам потребуется это системный вызов select(), а так же read() и wrote() для раздачи заданий. Оставьте системе её работу, займитесь делом.
0xd34df00d
30.10.2022 00:30+5Если Вы работаете на симметричной многопроцессорной системе со строгой (strong) моделью памяти, то Вам ничего делать не нужно. Если же у Вас модель памяти слабая (weak), то потребуется барьер типа StoreLoad. Как это делается в "модных плюсах" я не знаю и знать не хочу. Могу сказать как это сделать на асcемблере для ARM.
Тут нет никакой синхронизации вообще, вопрос не про неё, а про инициализацию. Честный однопоток.
Корректный ли это код с точки зрения C++?
Какие мьютексы и синхронизация в однопоточной программе? Всё, что Вам потребуется это системный вызов select(), а так же read() и wrote() для раздачи заданий. Оставьте системе её работу, займитесь делом.
А, то есть, мне ещё гонять данные по локальным сокетам с их сериализацией туда-сюда и копированиями, а не дёргать какой-нибудь shmem (для доступа к которому синхронизация в том или ином виде понадобится), потому что сишники не осилили синхронизацию? Блин, классно!
Я хочу перемножить две матрицы. Это очень хорошо параллелизуемая задача. Можете рассказать, как и что вы тут будете гонять по select'ам, read'ам и write'ам? Вот прям куски матриц будете в сокеты пихать? Или если вам известных кушающих философов решить надо, то как вам тут поможет разбиение на процессы и
select?funca
30.10.2022 01:01-1Я хочу перемножить две матрицы.
Перемножайте на GPU, eсли у вас что-то серьезное. В остальных случаях решения отличаются плюс-минус чисто эстетически.
0xd34df00d
30.10.2022 01:24+6Не все задачи хорошо ложатся на GPU. Да и про какое-нибудь перемножение матриц знает больше людей, чем про построение random forest'а.
Олсо, когда я решал похожие задачи лет 5 назад, у нас в серверах тупо не было GPU, а код писать надо было.
funca
30.10.2022 01:50+25 лет назад и здесь толком этого не было. Но сейчас появились машинки с CUDA в облаке, которые те же задачи вывозят быстрее и за в разы меньше денег.
checkpoint
30.10.2022 01:30-1Тут нет никакой синхронизации вообще, вопрос не про неё, а про инициализацию. Честный однопоток.
Корректный ли это код с точки зрения C++?
С точки зрения какой версии стандарта C++ ? Этот код корректный с точки зрения C++98. С точки зрения С++11 - нет, так как стандант 11 и выше исходит из того, что Вы работаете на многопроцессорной системе с внеочередным исполнением команд и Вам требуется предпринять меры для синхронизации памяти (барьеры).
Инициализация имеет совершенно вторичное значение.
Я хочу перемножить две матрицы. Это очень хорошо параллелизуемая задача. Можете рассказать, как и что вы тут будете гонять по select'ам, read'ам и write'ам?
Рассказываю. Определяетесь с количеством вычислительных ядер которое Вы хотите пригрузить задачей. Запускаете требуемое количество процессов обработчиков (воркеров) системным вызовом fork() или vfork(), каждому выделяете свой блок shmem и перенапрявляете stdin/stdout в отдельный файловый дескриптор. Воркеры ожидают команды начала работы путем блокируемого чтения из stdin, системный вызов read(0). В основном процессе (диспетчере) разделяете задачу на куски и распределяете между воркерами путем записи в соответствующий блок shmem. Старт воркера - запись байта в соответствующий файловый дескриптор системным вызовом write(fd). В цикле делаете select() и ожидаете события об окончании работы одного или нескольких воркеров. Подбрасываете воркерам еще задачки до тех пор пока они не закончатся. Когда расчет всей матрицы закончен закрываете файловые дескрипторы воркеров и делаете waitpid() - воркеры нежно завершаются. Оверхед на запуск процессов в современных UNIX системах ничтожно мал. Вам не потребуется ни единого мьютекса, никаких atomic и прочей туфты - всю работу по синхронизации за Вас выполнит операционная система.
Данный метод легко масштабируется на кластер из вычислительных систем обьединенных в сеть и называется Message Passing Interface. Придуман в 1991 году и используется по сей день в высоконагруженных вычислительных системах.
0xd34df00d
30.10.2022 01:50+4С точки зрения какой версии стандарта C++? Этот код корректный с точки зрения C++98. С точки зрения С++11 — нет, так как стандант 11 и выше исходит из того, что Вы работаете на многопроцессорной системе с внеочередным исполнением команд и Вам требуется предпринять меры для синхронизации памяти (барьеры).
Я всё ещё не могу понять, где и по какому принципу вы вставляете синхронизацию. Где вы здесь нашли в ней необходимость?
Инициализация имеет совершенно вторичное значение.
Инициализация имеет совершенно первичное значение, потому что бранчинг по неинициализированной переменной — UB.
Определяетесь с количеством вычислительных ядер которое Вы хотите пригрузить задачей. Запускаете требуемое количество процессов обработчиков (воркеров) системным вызовом fork() или vfork(), каждому выделяете свой блок shmem и перенапрявляете stdin/stdout в отдельный файловый дескриптор. Воркеры ожидают команды начала работы путем блокируемого чтения из stdin, системный вызов read(0). В основном процессе (диспетчере) разделяете задачу на куски и распределяете между воркерами путем записи в соответствующий блок shmem. Старт воркера — запись байта в соответствующий файловый дескриптор системным вызовом write(fd). В цикле делаете select() и ожидаете события об окончании работы одного или нескольких воркеров. Подбрасываете воркерам еще задачки до тех пор пока они не закончатся. Когда расчет всей матрицы закончен закрываете файловые дескрипторы воркеров и делаете waitpid() — воркеры нежно завершаются.
Вы забыли как-то реагировать, например, на то, что воркер может сдохнуть — из-за бага ли, по OOM ли, неважно. Важно — что на это уже надо нетривиальным образом реагировать.
И, по-моему, в цикле подёргать std::thread будет попроще. Объясните, пожалуйста, зачем конкретно эти сложности? Чтобы что?
Дальше, когда-то давно я по фану писал одно приложение на плюсах. Там, среди прочего, нужно:
- Преобразовать аватарку, которая может быть произвольно большой, в аватарку поменьше, со сглаживанием, что потенциально занимает несколько десятков миллисекунд.
- Сгенерировать OTR-ключ, что может тоже занять некоторое немалое время (в зависимости от количества энтропии, например).
- Перебрать примерно 240 тыщ комбинаций некоторых символов и найти, на какие из них отвечает система.
- Распарсить 10-мегабайтный жсон в древовидную структуру с описаниями радиостанций.
- Отсортировать эти радиостанции по разным критериям в зависимости от настроек пользователя.
- Загрузить из БД аудиоколлекцию пользователя и преобразовать её в удобочитаемый вид.
- Сделать миниатюры album art'ов коллекции.
- Распарсить аудиофайлы taglib'ом.
- Отрендерить страницу pdf'ки. Если несколько страниц видно сразу, то можно рендерить их сразу несколько, по числу ядер.
- Распарсить и JIT-скомпилировать фильтры для adblock'а.
… и ещё пару десятков подобных вещей.
Всё это в главном цикле делать не комильфо. Вы всерьёз на каждый пункт писали бы по отдельному воркеру, который бы форкали, и следили бы за тем, что произойдёт, если его вдруг прибьёт ОС/его бинарник не будет найден/етц?
checkpoint
30.10.2022 03:15+1Я всё ещё не могу понять, где и по какому принципу вы вставляете синхронизацию. Где вы здесь нашли в ней необходимость?
Судя во всему, Вы программируете для систем со строгой моделью памяти (x86), поэтому о необходимости в барьерах можете и не знать. Смысл в том, что если одна и та же область памяти может быть использована в разных нитях на системах с множеством вычислительных ядер, то после каждой записи этой области перед чтением требуется барьер (синхронизация памяти), иначе возможна ситуация undefined behavior. Вот статья про барьеры. Как я уже упоминал, в языке C++11 и выше исходят из того, что любая программа потенциально может иметь много нитей и быть запущена на многопроцессорной системе. Поэтому в язык введено такое понятие как "модель организации памяти" (memory ordering model) и добавлены конструкции для работы с барьерами. Предполагаю, что "бранчинг по неинициализированной переменной" растет корнями отсюда же. Как я упоминал выше, я не являюсь специалистом по C++ последних редакций, меня вполне устраивает С++ в редакции от 98-го года, а все проблемы аппаратуры я предпочитаю возлагать на операционную систему - использовать POSIX thread-ы и mutex-ы вместо std::thread и atomic. Это позволяет продолжать программировать в терминах "Си с классами" и скипать все новомодные конструкции языка, которые, к тому же, постоянно находятся в движении - новые конструкции добавляют, старые отменяют, язык С++ перестал быть совместим сверху вниз. И как правильно заметил Страуструп, С++11 и выше уже пора перестать называть общим названием C++. :-)
Вы забыли как-то реагировать, например, на то, что воркер может сдохнуть — из-за бага ли, по OOM ли, неважно. Важно — что на это уже надо нетривиальным образом реагировать.
В случае отдельных процессов все эти проблемы как раз таки решаются тривиально - select() сообщит Вам о сдохшем процессе и диспетчер сможет его перезапустить или предпринять какие-то действия, в крайнем случае - оповестить пользователя о нештатной ситуации. В случае нитей - вся Ваша программа (процесс) будет молча снята с исполнения операционной системой.
И, по-моему, в цикле подёргать std::thread будет попроще. Объясните, пожалуйста, зачем конкретно эти сложности? Чтобы что?
Чтобы не городить огород из толпы мьютексов и не нарваться на deadlock, и не похоронить всю задачу в случае ошибки. Ну и дебажить такой код гораздо проще.
Если уж Вы так любите нити, то описанный алгоритм MPI ложится и на схему с нитями - вместо stdin используете pipe() для формирования канала управления, вместо shmem - обычный malloc или new. Важно, что бы каждая нить работала только со своим куском данных и никак не пересекалась с другими нитками, всё взаимодействие происходит только через диспетчера.
Всё это в главном цикле делать не комильфо. Вы всерьёз на каждый пункт писали бы по отдельному воркеру, который бы форкали, и следили бы за тем, что произойдёт, если его вдруг прибьёт ОС/его бинарник не будет найден/етц?
Я бы для начала посмотрел на всю задачу в целом и скорее всего не стал бы пихать все в кучу, а разбил бы на несколько крупных подзадач (процессов или нитей), каждая выполняла бы свой набор мелких задач последовательно. Возможно это было бы не максимально эффективно с точки зрения утилизации процессорного времени, но код был бы более понятен. Идея запускать на каждый пшик по отдельной нити ни к чему доброму не приведет Вас. В лучшем случае у Вас закончатся PID-ы. :-)
erdizz
30.10.2022 04:28+2"исходят из того, что любая программа потенциально может иметь много нитей и быть запущена на многопроцессорной системе" — это не так. В C++11 вам предоставляется возможность писать многопоточный код, опираясь на стандартную библиотеку и на модель памяти. Совершенно необязательно этой возможностью пользоваться. Программы C++98 корректны и с точки зрения C++11.
Писать корректный многопоточный код существенно сложнее и дороже. Ни одна компания не стала бы переходить на новые версии стандарта, если бы при этом надо было перерабатывать весь код с учетом "потенциальной" многопоточности.
0xd34df00d
30.10.2022 05:48+8Судя во всему, Вы программируете для систем со строгой моделью памяти (x86), поэтому о необходимости в барьерах можете и не знать.
О барьерах памяти я знаю чуть больше, чем хотелось бы, а вот вы, судя по всему, собираете код обычно с
-O0, ибо иначе глупый компилятор всё ломает, и не знаете, что барьеры памяти — они не только для процессора, но и для компилятора, и поэтому вставлять их неплохо бы независимо от модели памяти конкретной железки. Но это так, если вам очень хочется помериться длиной знаний, моделей памяти и прочего.Независимо от конкретного процессора, я уже два комментария назад написал, что программа однопоточная, никакого многопотока нет, о синхронизации думать просто не нужно. Если это звучит слишком абстрактно, то представьте себе, что программа сводится к
int main(int argc, char **argv) { char *src = argv[1]; int x; memcpy(&x, src, sizeof(int)); return x > 42; }и всегда запускается с как минимум одним аргументом нужной длины (то есть, проверять
argcи длинуargv[1]не нужно). Есть ли здесь UB?Надеюсь, здесь вы не найдёте причину вставлять синхронизации и барьеры памяти.
Предполагаю, что "бранчинг по неинициализированной переменной" растет корнями отсюда же.
Нет. Растёт корнями он ещё из C++98 и, скорее всего, из C (но по стандарту C я не спец, и отвечать за него не могу).
В случае отдельных процессов все эти проблемы как раз таки решаются тривиально — select() сообщит Вам о сдохшем процессе и диспетчер сможет его перезапустить или предпринять какие-то действия, в крайнем случае — оповестить пользователя о нештатной ситуации.
Ну вот у вас уже появился какой-то диспетчер, который должен иметь какую-то логику обработки этих случаев (пусть даже
abort()).В случае нитей — вся Ваша программа (процесс) будет молча снята с исполнения операционной системой.
Иногда это вполне желаемое поведение.
И, кстати, это вы всё рассуждаете в терминах C. Например, в том же хаскеле ошибка в одном из потоков выполнения (деление на ноль, например, или неполный паттерн-матчинг, и так далее) приводят тупо к киданию экзепшона в этот поток с возможностью вполне спокойно и штатно обработать его в любом
IO, его запустившем. И ничего ни на какие процессы бить не надо.Чтобы не городить огород из толпы мьютексов и не нарваться на deadlock, и не похоронить всю задачу в случае ошибки. Ну и дебажить такой код гораздо проще.
Ещё раз скажу, что если пользоваться STM, то нарваться на дедлок ещё более сложно, при этом STM композируется куда лучше, чем что мьютексы, что процессы.
Я бы для начала посмотрел на всю задачу в целом и скорее всего не стал бы пихать все в кучу, а разбил бы на несколько крупных подзадач (процессов или нитей), каждая выполняла бы свой набор мелких задач последовательно.
На нити это разбить тяжело, потому что X11, увы, по факту однопоточный, а на процессы — маршаллить чуть более сложные структуры данных и вызовы процедур между ними сложно. Но это совсем отдельная история, которую я лет 10 откладывал до появления рефлексии в языке (чтобы не писать все обвязки руками), а в итоге она что-то совсем перестала быть интересной.
Идея запускать на каждый пшик по отдельной нити ни к чему доброму не приведет Вас. В лучшем случае у Вас закончатся PID-ы. :-)
Ну да, с процессами-то такого быть не может.
lexa
30.10.2022 09:37+5Слушайте, ну MPI придумали от тоски, в смысле от того, что задача перестала влезать на одну ноду.
После чего сразу стали его ломать разными способами, только бы ускорить (RDMA очевидно же абсолютно не в парадигме MPI)
Пускать параллельные "тесно связанные" задачи внутри одной многопроцессорной системы на процессах и использовать средства ОС для синхронизации имеет смысл только если этой синхронизации у вас совсем немного и в реальности она на производительность практически не влияет и объемы передаваемых между процессами данных невелики.
Ну, или если производительность не интересует.
Moraiatw
30.10.2022 11:31Можете сказать, не глядя в стандарт, нужно ли инициализировать переменную
xв коде ниже, или это UB?Если это локальная переменная - не нужно.
Если это глобальная переменная в многопоточной программе, то нужна синхронизация доступа к ней.
F0iL
30.10.2022 13:23+2Автор вопроса в соседней ветке уже несколько раз отметил, что речь про однопоточную программу.
RabraBabr
29.10.2022 12:50+17Аналогично. Не знаю кто распускает все эти нелепые слухи про бежать быстро и долго. Успокойтесь никуда бежать не надо. Весь современный мэйнстрим в программировании родом из 80-ых, 90-ых. И в целом мало, что то меняется. Программист это не языки программирования и модные фреймворки, а структуры данных, алгоритмы и паттэрны проектирования. Если вы прекрасно знаете как оно под капотом работает, а работает оно поверте уже много лет примерно также, то разобраться в новомодной фигне не составит проблемы.
constantine_mitin Автор
29.10.2022 16:21+4Наверное, я в своей жизни провел уже несколько тысяч технических собеседований программистам. Я видел много людей, которые не смогли «добежать», из-за чего очень сильно отстали от отрасли. Здесь я с вами согласиться не могу.
А вот с тем, что многое из современных тенденций родом из 80-90 годов, я полностью согласен. Что-то является воплощением идей того времени, что-то просто повтором старого и хорошо забытого, но на новом уровне.
Но вот есть одна беда. Людей, которые реально понимают, как оно работает под капотом и почему оно работает именно так, очень немного. Да, эти люди будут востребованы «всегда». Только их процент от общего числа «программистов» сейчас очень небольшой. Собственно об этом я и написал.
omxela
29.10.2022 18:43+4Людей, которые реально понимают, как оно работает под капотом и почему оно работает именно так, очень немного.
Слава богу, сформулировали. Так может быть, в этом всё и дело? Именно в этом, а не в судорожном "изучении" всё новых языков и всё новых технологий, которые не вами придуманы? Постоянно бежать - это хорошо, но понимать, куда бежать в перспективе - ещё лучше. Вы приводили пример с наукой. Отличное сравнение. Вы не сможете работать в науке, если не понимаете, как оно там "под капотом" работает. В IT, так уж получилось (с лично моей берёзы глядя), набилось слишком много людей, которые довольно расплывчато разбираются в тех самых структурах данных, алгоритмах и паттернах проектирования. Я ужЕ не говорю об элементарных представлениях о том, как именно под этим самым капотом работает несчастный компьютер, в машинные коды которого транслируется всё то, что мужественные разработчики наваяли (скопипастив из интернета). Да простят меня те, кто понимает. Не это ли непонимание и служит причиной выгорания? Каково психологическое состояние человека, который вынужден день за днём выполнять работу, истинный смысл и внутренняя структура которой ему не понятны? Рано или поздно подсознание взбунтуется от такого насилия над природой.
constantine_mitin Автор
29.10.2022 18:59Если человек совсем ничего не понимает, то его век в IT будет недолгим. Беда наступает, когда человек зависает между поверхностными знаниями и глубоким пониманием. То есть он вроде и может, но через постоянное усилие над собой. Вот это усилие и выжигает людей, медленно, лет за 15-20.
В науке все где-то так же, но там немного денег, такого притока желающих нет. Поэтому остаются в основном те, кто может и любит свою работу. Плюс процесс защиты кандидатской и докторской очень долгие. Вот где-то к 40 годам человек будет считаться состоявшимся специалистом. Лишних людей почти не остается.
0xd34df00d
29.10.2022 19:49+3Вы не сможете работать в науке, если не понимаете, как оно там "под капотом" работает.
Куча людей успешно занимается какой-нибудь матстатистикой, или рассчитывает то, что там рассчитывают теоретические физики, без понимания и, тем более, интереса к основаниям математики, матлогу, теории типов и прочему.
Dikoy
31.10.2022 20:38Суть учёного в способности самостоятельно ставить и решать задачи. Диссертация и процедура её защиты, как квалификационной работы, основана на доказательстве именно этой способности. Причём для докторской - уже даже без научрука.
Если человек для кого-то что-то считает без понимания, он бухгалтер, но никак не учёный.
semennikov
29.10.2022 19:26+2На своей шкуре могу подтвердить, что если понимаешь что под капотом, то на каком языке написано глубоко фиолетово. Правда я занимаюсь только совсем низкоуровневым ПО, там где оно интенсивно взаимодействует с внешним миром
Moraiatw
30.10.2022 12:45Я видел много людей, которые не смогли «добежать»
Т.е. освоить флаттер и иже с ним?
У вас какое то узкое понятие отрасли. Многие сидят, годами делают один и тот же ентерпрайз на яве и хорошо зарабатывают. Они тоже "не добежали" и "жизнь не удалась"?
constantine_mitin Автор
29.10.2022 16:15+2К слову говоря, мы не считаем месенджеры какой-то сложной задачей. Если бы мне предложили реализовывать его на базе С++, я бы такое запретил. Скорость разработки медленная, поддерживается плохо, преимуществ перед web-сокетами нет никаких. Ей богу, у нас месенджер в одного реализует фронтендер, просто взяв Flutter для клиентского приложения и Node.js для сервера.
Кроме того, стоит заметить, что у Flutter нет никаких проблем в работе с камерой, а что такое выжимать производительность для нейросетей я себе очень плохо представляю. Может быть, просто нейросеть нормальную взять? И обучаете вы её, наверное, не на телефоне?
Нет, у меня были коллеги, которые извращались с С++ на мобильных устройствах, но это были задачи из разряда запуска навигационной программы на китайском убогом планшете, из-за этого приходилось вписываться в те ресурсы, что есть.
Кстати, первой из задач, что мы реализовали с использованием Flutter, это географически распределенная система на нестабильных каналах связи для пассажиров речных круизов. Мобильное приложение позволяло людям просматривать экскурсии, использовать аудиогид, смотреть контент из бортовой мадиа-библиотеки, делать заказы услуг, доступных на борту. Конечно, приложению приходилось работать с бортовым сервером, который при наличии связи соединялся с центральным сервером. В нашей стране мобильный интернет много где недоступен. Для нас это несложный проект.
Когда дело дойдет до реальных проектов, скорее всего, вы серьезно проиграете по производительности. По производительности (скорости) разработки, по скорости внесения изменений и раскатки обновлений. И скорости работы приложения, не потому что С++ медленный язык либо ему не хватает каких-то средств, просто есть еще архитектурный уровень, который тоже очень не простой.
P.S.
Я бы никогда не стал отождествлять потоки и процессы, это как путать работу над общим и раздельным полем памяти.Rezzet
29.10.2022 22:51+5" Если бы мне предложили реализовывать его на базе С++, я бы такое запретил. "
Это очень хорошо. Фактически чем больше будет людей разделяющих ваши взгляды тем выше будет моя зп.
0x131315
29.10.2022 19:56+3Думаю все эти модные штуки для отрасли в целом благо: разработка очень дорогая, всерьез ее себе могут позволить только крупные игроки.
Простые, доступные инструменты высокого уровня позволяют стартануть огромному количеству мелких игроков. Конечно время жизни бизнеса на таких технологиях будет коротким, но большего и не требуется - многие из таких игроков не переживут и года, к тому же каждый год приходят новые, это как бурлящий котел. Но их суммарная капитализация в разы, если не на порядок, превышает капитализацию крупных игроков. Это огромные вливания средств в отрасль в целом, и это для отрасли благо.
Для общества тоже большая польза: удешевление разработки привело к взрывному росту проникновения высоких технологий в общество.
Это банально удобно: доступные смартфоны, множество бесплатных или дешевых (читай доступных) приложений и сервисов, которые каждый из нас использует каждый день, которые в чем-то облегчают жизнь, конкуренция в конце концов. Множество мелких доступных бытовых девайсов - современные дома просто напичканы электроникой, прошивками, софтом, сервисами. Появилось множество сайтов, практически каждая мелкая кафешка имеет как минимум свой сайт с меню, а то и целый интернет-магазин с корзиной и доставкой, и пусть все это очень криво сделано, постоянно что-то глючит, какие-то проблемы, но суть в том что оно существует как явление, доступно даже очень мелкому бизнесу, и бизнес, пусть с проблемами, вполне себе живет.
А также это полезно: в том же смартфоне тебе и развлечения, и обучение, и организация своей жизни, и управление финансами, а иногда и работа. Не говоря уже про то, что связь по миру в принципе стала доступной штукой, можно очень дешево общаться с противоположным концом планеты, да еще и по видеосвязи - еще недавно это казалось фантастикой. Люди сегодня, пользуясь такими технологиями, обсуждают всякие бытовые, абсолютно бесполезные, темы, и это замечательно: все это настолько доступно, что даже на всякий мусор не жалко тратить ресурсы/трафик/время.
И все это обеспечено именно дешевой разработкой - она сделала информационные технологии доступными.
Даже закостенелые госаппараты оценили преимущества информационных технологий, в мире появляются цифровые госсервисы, системы связи/наблюдения/координации. Государства от обмена бумагой переходят к обмену данными по сети, цифровые архивы растут, все бумажное постепенно оцифровывается, упрощается взаимодействие. А те, кто не переходят на цифру, страдают, закапываясь в стопках бумаги, которые на каждый чих нужно перебирать вручную.
Ну и как следствие, большой приток мелкого бизнеса способствует росту крупного бизнеса: часть мелкого бизнеса со временем неизбежно отрастет до крупного. И вот тут и начинается самое интересное: дешевый процесс разработки для крупного бизнеса не подходит, дешевые высокоуровневые инструменты очень ограничены, и ограничивают развитие бизнеса, а выходить за пределы ограничений очень дорого, дешевых квалифицированных специалистов нет, а неквалифицированные не способны качественно решать сложные задачи, так что все это нарастает как ком, порождая все больше проблем, и бизнес вынужден переходить на нормальные инструменты, и привлекать соответствующих специалистов. Когда от софта зависит крупный бизнес, экономия обходится дорого.
Как итог приток мелкого бизнеса со временем увеличивает спрос на квалифицированных дорогих опытных специалистов - работы становится больше, и это хорошо. У каждого бизнеса свои потребности, свои требования, и множество сложнейших задач, которые кому-то надо решать.
funca
30.10.2022 16:35Простые, доступные инструменты высокого уровня позволяют стартануть огромному количеству мелких игроков
У меня на телефоне приложение от самого мелкого бизнеса это Navitel. Остальное написано гигантами типа Google, Microsoft и т.п. Доступность инструментов создаёт условия для пополнения рынка до какой-то степени обученными и замотивированными кадрами. Но выводить самим что-то на рынок становится только сложнее.
Порог входа с каждым годом лишь увеличивается. Если 10 лет тому назад основной проблемой для стартапа a'la аналог Фейсбука, было найти дешёвый хостинг и выстроить продвижение, то сейчас к этому добавилось бесчисленное множество требований со стороны различных локальных регуляторов - иначе рынки закрыты. Элементарная задача хранения фоток, если на них могут быть какие-то люди, теперь уже целый архитектурно-юридический танец с бубнами на много денег.
0x131315
30.10.2022 19:51+2Конкретно на смартфонах множество приложений буквально от одиночек, зачастую существующих только на рекламу, или вообще just for fun. От крупных игроков там не так много приложений. Но там есть целые фермы приложений - фирмы, которые клепают все подряд, в надежде что что-то выстрелит. Лучшая поддержка и обратная связь именно у одиночек/небольших команд: у них самая высокая мотивация на результат, многие предложения пользователей уходят в код, аудитория довольна. Сам пользуюсь несколькими такими мелкими приложениями, которые отлично выполняют свою задачу и не содержат скама и рекламы, и это именно продукт конкуренции, он отшлифован, он ценен лично мне, т.к. решает мои задачи, но с финансовой точки зрения такие приложения имеют мало смысла, сложно представить что такое выпустит какой-то крупный игрок.
В этом плане у мелкого бизнеса есть преимущество: он более эффективен. Не смотря на почти полное отсутствие финансирования, люди выдают очень неплохой результат. В то время как крупный бизнес, не смотря на огромное финансирование, разбивается о скалы бюрократии, из-за чего довольно простые задачи излишне переусложняются, и стоят многократно дороже. Это буквально так: в то время когда в мелкой команде какую-нибудь опечатку поправить минутное дело, в крупном бизнесе это целый квест с десятком промежуточных узлов, ответственных, специалистов разных уровней, где никто особо не заинтересован в результате, но их всех нужно оплатить. Т.е. мелкий бизнес более ориентирован на результат, быстрее цикл разработки, проще процессы, оперативнее связь внутри. Именно этот дисбаланс в пользу мелких дает им возможность конкуренции. Уже были случаи, когда такие одиночки клали на лопатки продукты с огромной капитализацией, и крупные фирмы противопоставить этому ничего не смогли - не смотря на всю рекламу, в конце концов люди выбирают что удобнее.
На рынок выйти безусловно сложно, как минимум из-за рекламных бюджетов: крупные фирмы просто грузовиками завозят средства на рекламу, скупают многих конкурентов, могут себе позволить. У мелких компаний в этом плане шансов почти нет. Тем не менее ситуация не безнадежная, отдельные приложения успешно пробиваются, отхватывая свою долю рынка, не смотря на все давление, т.е. конкуренция вполне себе работает, но отбор сегодня конечно куда более строгий, чем был когда все это только зарождалось.
Про порог входа - да, в каких-то сферах он растет, но в целом остается довольно невысоким. Собрать какое-то примитивное приложение можно без знаний и опыта - инструменты достаточно автоматизированы, чтобы это простить. Что-то с нормальный функционалом безусловно потребует знаний. В моем окружении мини-приложения даже админы клепают, для производственных нужд, для управления/мониторинга чего-нибудь мелкого, почти в личных целях, в свободное время. Тоже для себя пару простых делал - не так сложно, в смысле даже не пришлось погружаться в тонкости ОС, хватает и базовых знаний, а интерфейс вообще из готовых блоков собирается в визуальном редакторе. В этом плане гугл проделал большую работу, создав такие сложные инструменты, чтобы привлечь разработчиков для заполнения экосистемы.
Про бизнес - тут ничего не поделать, это рынок, кто первый того и тапки. Фейсбуки и гуглы стартовали на почти пустом рынке, сейчас там стартануть конечно намного сложнее, ниши уже заполнены и поделены. Но все еще возможно - если продукт предлагает что-то уникальное и более доступен/удобен, чем конкуренты, или нашел относительно свободную нишу, или конкуренты уже отмирать начали, у него хорошие перспективы. Расклад на рынке в конечном итоге определяют именно потребители. Опять же бюджеты сейчас часто закрываются инвестициями, многие этим пользуются, пусть это и палка о двух концах, т.е. и с ресурсами проблемы можно решить, если продукт действительно ценный и нужный.
LinearLeopard
30.10.2022 14:00> Работаю уже лет 20(с первого курса) и подхожу к заветной точке 40+, так вот первым моим языком был С++, первым большим фреймворком был Qt, не поверите, но все что изучал еще в школе до сих пор вполне актуально.
Добрый день, а не подскажете, что пишете? Действительно интересно, просто в последнее время ни с чем нативным не сталкивался. Даже рад, что JS ещё не целиком захватил мир.
vassabi
30.10.2022 22:02+2аутомотив вон бегает на С++ с Qt . (видел еще такую же связку в аудиосистемах, у которых больше 20 динамиков, и в распределительных системах электросетей дженерал электрикс)
игрушки для множества платформ на С++ пишутся (однажды довелось даже самому участвовать в проекте, когда код на С засовывали в эмскриптен и потом запускали в браузере !)
LinearLeopard
31.10.2022 15:16Спасибо
> игрушки для множества платформ на С++ пишутся (однажды довелось даже
самому участвовать в проекте, когда код на С засовывали в эмскриптен и
потом запускали в браузере !)
Слушал, что менюшки теперь тоже принято рисовать в электроне, а саму игровую графику в каком вулкане. Пожалуй, хорошо, что не все таким заняты.vassabi
31.10.2022 21:51ИМХО в игрушках - первична идея.
если игрушка "цепляет" то нет большой разницы на чем она написана.язык кода - влияет только на 1) скорость починки багов\лагов 2) количество платформ, на которые ее можно быстро портировать
Rezzet
30.10.2022 22:38+6Что пишу, в основном геймдев: движки, внутренние редакторы и различные утилиты. Геймплей, понятно, что это будет или скриптовый язык или квестовый граф, в общем то что можно быстро и легко переделывать, а вот различная работа с ресурсами, рендер, сеть и прочее это будет или натив или с++. Вот что-то такое и пишу, делаю все что бы гемплей командам жилось хорошо и беззаботно. В геймдеве работы много и она разная, можно менять специализацию при желании. Лично по-моему опыту уровень задач и их качество зависит от рук, а не от технологии, Языки, фреймворки все плюс минус одинаковое. Мне нравится связка C++/qt потому что более менее понимаю как этим пользоваться, плюс есть огромная поддержка с++ со стороны различных сторонних бибилиотек. Ну к примеру есть boost::graph мне не понятно что будут делать специалисты на флуттере если им нужно будет в графе найти остова, с помощью буста это решается щелчком пальца, а там что, сидеть самому писать алгоритмы? Или к примеру иногда приходится делать свой язык под задачу, берешь bison/flex и вперед можно antrl, а на флуттер что делать? Antrl может быть конечно уже и сделали биндинги в Дарт, не следил как-то. Но опять же мне Antrl парсеры меньше заходят, и bison уже умею пользоваться. Мне минимум два раза встречались задачи на использование шаблонизатора, первый раз лет 10 назад для генерации отчетов и печатных форм, второй раз вот совсем недавно что бы дать возможно аналитикам делать выборки по балансу для своих моделей, в обоих случая логично было бы прикрутить скриптовый язык, в одном случае пошел js в другом lua, плюс автоматизацию для тестировщиков писали в одном случае прикрутили биндинг в питон по парсенгу логов перфа с ночных билдов, во втором случае взяли ChaiScript и дали возможность писать тестовые сценарии для фермы мобильных клиентов, на скрипте описывались сценарии для всех устройств. Ну к примеру заходят в бой два клиента и дерутся по определенному сценарию, за бой снимаются логи по перфу и потреблению памяти, а так же насколько у нас баланс сходится. В случае отклонения от референсных значений - алерт. Короче задача скриптования встает очень часто, и для с++ есть куча готовых решений: питон, луа, chaiscript и т.д. Делаю игру мне нужен отладочный UI - беру imgui и вперед. В одном из проектов нужен был профилировщик, сели написали профилировщик, как на дарте вообще это сделать, сначала написать биндинги winapi в дарт потом писать профилировщик? А насколько это долго будет работать у нас 5 минут игры генерили примерно 10 Гб логов(не текстовых, а ETL).
Вот автор статьи говорит про вебсокеты, и зачем после их появления нужен tcp, ну сделайте на вебсокетах пробой NAT через STUN/TURN. Это нужно например что бы экономить сотни тысяч долларов на раздаче DLC для игры. WoT обновления через торрент протокол раздает.
Я про всякое разное убийцы с++ слышу... сколько работаю столько и слышу, сначала был .NET все c# сейчас все убьет, UI только на нем, WinForms лучшее, очень быстро, очень качественно, программирую на с++, потом Flash, все кроссплатформенно, очень низкий порог входа все игры будет писать на нем и программы то же, веб все захватит, программирую на с++, потом электрон, очень круто, очень много разработчиков, очень быстро, все UI только на нем, продолжаю программировать на с++, сейчас вот флуттер, все с++ хана все только на нем, ну... как бы мое отношение понятно ) Нет какую-то нишу себе флуттер займет, как заняли и все убийцы с++ до этого, но с++ никуда не денется еще очень очень очень долго.
0xd34df00d
30.10.2022 23:18+4Мне нравится связка C++/qt потому что более менее понимаю как этим пользоваться, плюс есть огромная поддержка с++ со стороны различных сторонних бибилиотек. Ну к примеру есть boost::graph мне не понятно что будут делать специалисты на флуттере если им нужно будет в графе найти остова, с помощью буста это решается щелчком пальца, а там что, сидеть самому писать алгоритмы? Или к примеру иногда приходится делать свой язык под задачу, берешь bison/flex и вперед можно antrl, а на флуттер что делать?
При этом на плюсах это всё неудобно, долго компиляется, ноги простреливаются, да и сообщения об ошибках так себе (особенно в случае буста — с BGL я тоже работал, да и для парсеров вы почему-то выбрали bison/flex/antlr, а не boost.spirit).
Флуттер — это всё-таки не единственная альтернатива для эффективного написания эффективного кода.
Rezzet
31.10.2022 11:40+2С компиляцией последнее время почти нет проблем, прекомпиленые хидеры это понятно, сейчас добавилась инкрементальная линковка. Плюс компилируется то что менялось, плюс появились очень многопоточные процессоры. Ну и мне даже иногда нравится задержка перед запуском программы, те 30-40 секунд что обычно работает компилятор хватает что бы подумать что будешь писать дальше. Еще в студии очень удобная фича компилировать только файл на котором курсор стоит.
"ноги простреливаются" проблема сильно преувеличена чем она есть на самом деле. Там вот выше чет про memcpy терли, даже вчитываться не стал, обычно такой код не пишется, обычно работа идет на несколько более высоком уровне, если есть данные они скорее всего хранятся в контейнере, а если нужно скопировать контейнер, std::copy, std::transform, да тонкие оптимизации так не сделаешь. Для тонких оптимизаций есть профилировщик и опять же в 90% случаев проблема будет в архитектуре или алгоритме. Но если у вас супер критичный код и прям вот надо выжать все, ну ок, почитай справку и сделай все аккуратно. Так то и до асма можно дойти при желании. С++ сильно мультипарадигменный. Опять же проблема современного программирования, приходится постоянно переключаться с разных языков, что-то на питоне сделать по автоматизации, что-то на нативе(objective c, java), пол игры вообще на lua написано, система сборки на cmake, держать в голове тонкости работы 5-6 языков не возможно, как минимум в моей, поэтому ок гугл, хау то... и поехали, все мы в той или иной мере фулстековерфлоу программисты.
BGL - кровь из глаз, кто же спорит, boost.spirit - ну нахер, апи curl - хочется пойти выйти в окно, но есть cpr. Подключить библиотеку - да сдохнуть можно было еще лет 10 назад, но появился cmake, а потом конан и vcpkg стало как-то очень полегче, но все равно, есть Tesseract, от которого много что зависит на тему распознавания, он начал под mac-arm64 собираться из коробки месяц назад, до этого приходилось патчить и до сих пор в vcpkg либ у которых в портфайлах !arm написано валом. Но понимаете в чем дело BGL то есть и он работает, и аналогов по спектру решения задач не особо много, скажем почти нет, а какая альтернатива в других языка? Сесть написать свои алгоритмы, а потом годами в них ловить ошибки на корнеркейсах?
Альтернатива это всегда хорошо, не было бы руби-на-рельсах, пипа, никто бы и не почесался в с++ на тему пакетного менеджера. Питон очень хорош для автоматизации и прототипов, даже если взять qt, я не буду больше никогда на виджетах ничего писать, скорее всего, потому что qml дает больше и лучше, а там с++ загнан под капот и вообще все на js. Альтернативы дают новые подходы которые заставляют развиваться мир с++ и самые успешные альтернативы дают тебе не замену с++, а дополнение с++. Они не вместо, а они вместе. Ни для кого не секрет что под капотом питона все так или иначе использует с++, у явы есть JNI.
putnik
29.10.2022 10:20+25Программисты после 40 всё так же продолжают работать. Просто надо учитывать, что двадцать лет назад их было намного меньше, а сами технологии были другими. Поэтому и работают они преимущественно не в молодых стартапах с дружным коллективом, а в куда более классических компаниях.
maldalik
30.10.2022 12:28+4+1. Вполне себе работаю мне уже скоро 50. И честно говоря не вижу чего-такого радикально нового появилось в SQL за эти 30 лет. Мне гораздо сложнее в предметную область въезжать.
Areso
30.10.2022 22:06+3Хранение сначала XML, потом JSON(б). Специальные типы данных и индексы для ГИС данных.
Самое главное, появился пласт No SQL решений и гибридных решений. А ещё появились DWH и задачи ETL с десятками разнообразных инструментов.
Red_Nose
30.10.2022 23:33От этого качество данных не изменилось в лучшую сторону. И вместо 50 строк SQL приходится писать 100500 :(
Оченно модные новые решения никак не помогают в переписывании всего древнего, что накопилось за 20 лет.Можно пользоваться всем этим умело, а можно - как всегда.
" XML, потом JSON " - угу, и потом 2 недели разбираться почему работает не стабильно. Как оказалось виноват свежий драйвер шины данных - он обрезал запрос до 512б.
Неужели DWH не является обыкновенной базой данных ? Неужели 3 простых правила что-то кардинально поменяли ?
" ...и задачи ETL с десятками разнообразных инструментов. " - достаточно плотно знаком с ODI, DataStage и NiFi - да, шЫкарные инструменты в "ровных" руках. Но если их дать пламенному нубу - бяда.
Вывод: неважно какой автомобиль, важно какой ВОДИТЕЛЬ
putnik
30.10.2022 23:52+1Мне пока ещё не сорок, хотя уже не так и далеко. Но вот мама у меня всё ещё работает и на седьмом десятке, хотя начинала ещё с перфокарт.
raspberry_pi_soft
29.10.2022 11:16+7Отличная статья, согласуется с моим опытом как руководителя программистов. Особенно, что хорошие программисты из радиотехников получаются. И про возраст правильно написано, если человек хороший специалист в молодости, то и после 60-ти отлично работает и новое осваивает.
a-tk
29.10.2022 11:47+35Помнится лет десять назад в аналогичных статьях вместо 40 было 30...
EmacsBrain
30.10.2022 09:49+1спасибо, что напомнили: действительно был фильтр 30 лет на программистском направлении в разделе "модно, стильно, молодёжно", как раз помогал подбирать в регионе персонал для работы в региональном офисе в федеральной команде. Был несколько смущён этим цензом, пока не увидел кучу людей, которые сдвигались от передней линии фронта чуть в сторону в энтерпрайз проекты без особых потерь. И сейчас в 40 точно так же вижу подобную картину: никуда после 40 народ из ИТ не исчезает, количество ниш для них в энтерпрайзах непрерывно разрастается.
saipr
29.10.2022 11:54+20Владимир Орлов — это тот человек, который учился у первых программистов, а сейчас он пишет статьи о своём более чем пятидесятилетием опыте в отрасли
Спасибо, что вспомнили о моей скромной персоне.
Не только пишет статьи, а продолжает программировать и много программировать:
удостоверяющий центр, утилита для работы с электронной подписью, наконец SVG-редактор и т.д.Да, и кроме упоминаемых автором трех частей, вышла и четвёртая часть:
Пятьдесят лет на стезе программирования. Часть IV. 4 ЦНИИ МО. Звёздные войны. 1983-1987 г.г
lexa
29.10.2022 12:04+1435 лет назад я получил первую зарплату за программирование. И продолжаю, не собираюсь прекращать....
vtal007
29.10.2022 12:09+2о, я как раз в 45 пытаюсь зайти в ойти (аналитику). Видимо надо стремится к пожилому дружному коллективу :)
Вы знаете, за 20 лет, люди все также считают медиану и среднюю, факторный и кластерный анализ. в ML конечно добавились методы, но это применяется достаточно редко
Теперь SPSS это фу, а вот питон с пандасом это круто (хотя на 90% делают ровно одно и то же)constantine_mitin Автор
29.10.2022 16:26Странно слышать от человека, который пишет про SPSS (ничуть не фу) и (кажется) понимает, что такое ML с точки зрения математики, о том, что он только-только собирается зайти в ойти.
Скорее всего, у вас уже есть фундаментальные знания и системное мышление. Остается только немного актуализировать знания по технологиям дата-сатанизма и найти нормальную команду (не стартап). В стартапе может не получиться с горящими глазами делать какие-нибудь глупости, а в серьезной компании будут интересные задачи.vtal007
29.10.2022 17:04не, к сожалению немного не так. Я пытаюсь зайти в аналитику данных. Почти прошел Excel, скоро надо будет проходить базу по Питон и SQL (может потом на платные курсы аналитика). А про ML общее представление. Штука интересная, но требует (если не обезьяничать, подключая "эскалёрн"), хорошее знание математики
pae174
29.10.2022 12:14+14Их даже учат правильно составлять резюме и проходить собеседования.
У вас в слове "только" несколько опечаток.
JPEGEC
29.10.2022 12:37+3На мой взгляд у автора профессиональный перекос, судит о пограмистах исключительно из своего окружения.
В реальности полно людей в возрасте продолжающих писать на прологе, фортране, дельфи, пиэльсекюле и прочем таком же старье.
Работа есть, деньги платят, всякое стильное/модное/молодежное оставленно хипстерам от программирования. Бежать нужно чтобы оставаться на острие процесса, так наверное справедливо, просто для сохранения статус кво это, зачастую, необязательно. Ну и хватает областей где к прогрессу отношение негативное а легаси обширное.
constantine_mitin Автор
29.10.2022 16:35В реальности у меня очень широкий круг общения, который захватывает большой спектр технологий.
Можно сказать, что на Fortran сейчас пишут всё меньше и меньше, даже в научной среде, которая занимается численным моделированием. Даже оттуда его вытесняет С++.
Для меня очень сомнительно, что на Prolog сейчас идет много разработок. Дело в том, что это отдельная парадигма программирования, которая имеет очень узкую нишу применения. Возможно, его еще где-то используют, но это должны быть специфичные задачи.
Если коснуться PL SQL, то могу сказать что его сейчас его все так же активно используют. Иногда слишком активно, за что приходится очень больно бить по рукам. Размещать слишком много бизнес-логики в базе данных - плохая идея и известными последствиями. Тем не менее, язык все еще востребован, причем, как для диалекта Oracle, так и для диалекта PostgreSQL.
А вот с Delfi все несколько сложнее. Нам приходилось консультировать компанию, которая реализовала внутри себя аналог 1С на Delfi, после чего людям захотелось упаковать это, как продукт. При таких инициативах всегда проводится анализ доступности разработчиков на требуемых языках. Нет программисты на Delfi есть, но стоят они меньше джуна на Python. Реалии рынка где-то такие.funca
29.10.2022 19:33+5Нет программисты на Delfi есть, но стоят они меньше джуна на Python. Реалии рынка где-то такие.
Есть программисты на Delphi. Кто помнит как называется язык стоят уже нормальных денег.
constantine_mitin Автор
29.10.2022 20:20Вот я сейчас посмотрел вилку зарплат (по вакансиям и резюме) по Новосибирску на HH.ru, для разработчика Delphi это 40-50 тысяч рублей. Вакансий мало, резюме - много.
funca
30.10.2022 00:42Я смотрел на Glassdoor, там предлагают $50K - $130K, что вполне сопоставимо со обычными цифрами по рынку. Понятно, что это не мейнстрим, вакансий мало и учить с нуля смысла нет. Но если уже есть навыки, то работу ещё можно найти.
alexey_public
31.10.2022 00:52Ну зависит от ситуации и опыта. Мне, к примеру, предлагали год назад порядка 400 тыс руб в Москве. Но там и разработка была достаточно высоконагруженной системы и опыт нужен был не только в Delphi.
vadimr
29.10.2022 21:50+3Я не далее как в текущем году в очередной раз заработал денег халтурой на фортране. Причём за фортран или, скажем, лисп платят намного дороже, чем за мейнстримные языки, ввиду дефицита исполнителей. За программу на Прологе тоже в текущем году предлагали заплатить, но я не взялся, не люблю эту парадигму.
Самая удельно дорогая моя программа состояла из 58 строк на языке REXX (включая пустые строки и комментарии) и обошлась заказчику вместе с документацией в 700 000 рублей. Это, конечно, больше исторический анекдот, но в целом иллюстрирует тенденцию, что не всегда обязательно впахивать, как раб на галерах, при правильном позиционировании на рынке.
При этом, если мне изредка надо что-то запрограммировать чисто для себя, я последнее время обычно пишу на питоне. Не то, чтобы я люблю именно сам язык питон, но под него много современных фреймворков на разные случаи жизни, и на нём гораздо быстрее тяп-ляп что-нибудь наваять, чем на C++. Но как питон-разработчик себя не позиционирую, рынок задемпингован бедными студентами.
А так вообще руководить выгоднее и интереснее. На данном этапе жизни какое-нибудь толстое ТЗ для соисполнителя я в большинстве случаев напишу с бо́льшим удовольствием, чем программу.
vadimr
30.10.2022 11:27+2Кстати, фортран сильно эволюционирует, поэтому нельзя сказать, что это такой уж путь для лентяев. Фортран IV (он же 66), который я учил в детстве, и Фортран 2008, который сейчас является стандартом де-факто (а есть уже и 2018) – это как K&R C и C++ 14, по существу разные языки с разной методологией кодирования.
semennikov
29.10.2022 13:01+6Мне 65 не знаю, можно ли меня назвать программистом, или электронщиком или физиком, но как делал устройства/приборы так и делаю. Языки — я знаю их больше 15, но реально — С, С++, Lua, ну и конечно же ассемблер(хотя и ре-е-едко). Когда делаешь новый прибор/устройство непонятно чего там больше — программного модуля, электроники или физики, и ни без чего не обойтись, везде новые проблемы, везде нужно смотреть, читать, ругаться с коллегами, запускать — и думать «Ну какой дурак это придумал???» (а потом смотреться в зеркало и вырывать остатки волос). Основная проблема — собрать команду, мотивировать ее и помогать, искать ошибки и давать идеи. Кодить конечно тоже надо, но в основном смотреть на стыки ПО и железа
Fafhrd
29.10.2022 13:27Так разработка ПАК -- всегда комплексная задача, всё нужно. Особенно если приходится колхозить на стыке ранее не использовавшихся совместно технологий.
constantine_mitin Автор
29.10.2022 16:42Наверное, вы все же разработчик. :о)
Из написанного вами у меня только один вопрос возник, почему Lua? Это ж еще тот «мопед», иначе и не скажешь. Самое ужасное то, что я сам его знаю и мы реализовали не нем высоконагруженный сервис. Сервисом мы гордимся (архитектура красивая, скорость работы высокая, надежность уникальная), а вот то, что он сделан на Lua никому не говорим.
А так, время идет, а проблемы остаются похожими друг на друга. Но для этого нужно достигнуть некоторого профессионализма в области, на это способны далеко не все.semennikov
29.10.2022 19:17+1Lua удобен чтобы делать маленькие примочки, например новую команду для робота. Просто как валенок, и удобно отлаживать
allcreater
29.10.2022 21:33+3а чем Вам Lua не угодил?
Отличный мультипарадигменный язык, чертовски простой в освоении, легковесный(официальный) интерпретатор идеально подходит для встраивания и работает на всем, начиная от микроконтроллеров. Для интерпретируемого языка это чудо еще и работает весьма быстро.
Насколько я понимаю, на чистом Lua, от и до, большие системы проектируют довольно нечасто, зато как средство расширения нативных программ, написанных на том же C и C++ - применяется очень широко.
constantine_mitin Автор
30.10.2022 09:54Ну, в какой-то момент мы начали писать на нем слишком сложную логику. А Lua неудобно отлаживать и как язык он, конечно, простой, но несколько обрезанный. Потом перенесли сложную логику на python.
А вот об активном применении Lua в робототехнике и для микроконтроллеров я даже как-то не знал. Там его «легковесность» вместе с интерпретируемостью действительно огромный плюс.
YDR
31.10.2022 11:06+1сделай публикацию на Хабре? И по делу интересно будет, и в карму можно будет добавлять >4.
(не личным сообщением, поскольку многие, кому хочу добавить в карму, ограничены числом 4 - всем вам актуально)
boopiz
29.10.2022 13:45+2Все так. Основная мотивация это интерес и самореализация в разработке. Сейчас уже, по прошествии многих лет занимаюсь этим как хобби. 24/7 уже не интересно. интересно что то делать руками. осваивать другие специалтности (и там применять подходы используемые в разработке) . но и изучать и осваивать что то новое, реализовывать то, на что в потоке не было времени тоже никуда не ушло.
вот учить молодёжь - не интересно. сколько ни пробовал.. смотришь в пустые глаза и понимаешь, что всё зря. нет той искры, желания учиться этой "магии". и не хочется тратить свое время на эту бесполезную возню.
semennikov
29.10.2022 19:20+3А это Вы не пробовали в специализированной школе, там конечно тоже есть пустые глаза, и много, но есть такие что еще и Вас за собой потащат
uhf
29.10.2022 13:50+16После 40, не то, чтобы сложнее учиться — сложнее заставить себя учить очередной
говнофреймворк, технологию, или язык программирования, инновации или преимущества которых тебе совсем не кажутся очевидными и бесспорными, на фоне предшествующего опыта. Как говорится, есть с чем сравнивать. Редко, что действительно увлекает — и тогда принуждать себя не надо, всё как в молодости.
Возможно, это просто стариковский консерватизм прогрессирует, а может быть, и нет. Сложно судить.
d_ilyich
29.10.2022 21:44Редко, что действительно увлекает — и тогда принуждать себя не надо, всё как в молодости.
Я недавно остался без работы (честнее будет сказать «отказался»), зато вновь ощутил то, чего давно не испытывал — удовольствие от процесса познания.
vadimr
29.10.2022 21:54+1Верное замечание. А также практически все паттерны проектирования уже хорошо известны, нет ничего нового в самой реализации кода. Подумать в принципе над алгоритмом решения задачи интересно, а расписывать этот алгоритм отдельными операторами – уже настолько забодало своей однообразностью, что проще поручить молодому сотруднику. Это как зумиться на отдельные пиксели, представляя себе в целом картинку.
slonoten
29.10.2022 22:01+2Если программировать по ТЗ однотипные задачи, то наверное все это в конце концов осточертеет. Если начать решать небанальные задачи бизнеса и выбирать соответсвующие технологии для их решения, то станет веселее. В 33 дорос до руководителя разработки коробочного продукта, в 35 ушел разработчиком на задачи обработки документов, где мы заменили кожанных мешков с приемлемым качеством и обработали за них миллионы документов, в 40 вкатился в ML и нейросети, несколько интересных проектов в области ИИ, в 45 вернулся в руководство командой, не зашло, возврашаюсь в разработку. По теме можно почитать статью Андрея Карпаты "Software 2.0".
Matshishkapeu
29.10.2022 15:16-3Всегда смешно читать как ИТшечка уникальна тем, что надо учиться и технологии быстро меняются. Взять довольно гуманитарную дисциплину продаж. Люди из итешечки, наверное, думают, что продажи как велись 20 лет назад с помощью платного объявления с рамочкой за 100 рублей в газете "Из рук в руки" так и ведутся. Сейчас и 10 лет назад даже лишние волосы в труднодоступных местах удаляют иначе. И всем причастным пришлось этому учиться. Даже просто ездить на развозном фургончике в среднем российском городе сейчас и 10 лет назад это две разных технологии.
Areso
30.10.2022 02:58объем данных. который необходимо освоить, не сравнить.
Да, появился планшет с программой, но освоить популярные 3-5 юзер сторей на новом инструменте это одно, а другое - освоить новую либу, фреймворк, а то и язык со всей его экосистемой.
Matshishkapeu
30.10.2022 21:07Изучить как в новом говнофреймворке создаётся круд формочка (90% вебдева) сильно сложнее чем перейти на новое поколение элементной базы в железячничестве, или понять каким именно образом нужно строить канал рекламы новой демографической группе с новыми предпочтениями в потребляемом контенте?
PuerteMuerte
31.10.2022 00:25+1Не знаю, у меня например нет статистики, только свой личный пример, и это не слишком представительная выборка но... я не раз брался за проекты, построенные на платформах, которые вижу в первый раз в жизни. Всё-таки четверть века опыта в смежных сферах позволяют легко разобраться практически во всём. Я всегда понимал, что надо делать, вопрос был только в том, "как сделать вот такую вещь на такой-то платформе", и ответ на него, как правило, всегда находился на первой же странице гугла. И тот же опыт позволял увидеть, правильный ли это ответ, или нет.
stas2s
31.10.2022 13:10+1Это немного не так работает. Любая нетиповая задача, заставляет что то покопать и что то изучить. А если вы сеньор, то типовых задач и формошлепств в целом не будет. Сама по себе работа и есть учеба, а учиться и напрягать мозг в целом сложно. Все эти спанье в офисе, печеньки бонусы и прочее появились в айти сфере, чтобы народ мог больше работать не выгорая. При этом лет после 25, мозг после нагрузок начинает гораздо медленней востанавливаться. Благо что для опытного мозга, то что раньше было затратной проблемой на недели, часто теперь легкая проблема на пару часов.
andres1
29.10.2022 15:2326 лет работаю с микроконтроллерами и DSP. Как был классический С, так и остался. Даже плюсы не пролезли. Естественно ассемблер.
Недавно пришлось писать на котлине. Так большая часть времени ушла на то, чтобы разобраться с классами хранения данных и понять, как из всего этого счастья вылезти. После этого эксперимента я в андроид не ногой. Тем более после того, как столкнулся с попыткой внедрить код старой версии андроид в приложение, написанное на новой.
Racheengel
29.10.2022 16:24-1Куда исчезают программисты после 40 лет?
Так в тимлиды, куда ж ещё. Или в продакты.
LilenSh
29.10.2022 16:44Интересные мысли. Я в начале карьеры так и думала, что рынок в России у нас молодой, поэтому так много спецов молодых, 40+ в нашей конторе было от силы процентов 5-7%, остальной был молодняк 23-33 лет в основном
Nasreddin_Hodja
29.10.2022 17:24-1Flutter - хорошая технология, теперь у нас в компании нет разработчиков мобильных приложений на нативных языках (Java, Kotlin, Object-C, Swift), они проиграли конкуренцию по скорости и стоимости разработки.
Как-то мне наши рекрутеры сказали, что просмотрели где-то 600 (!!) откликов на вакансию, провели несколько первичных собеседований, но до второго этапа никто не дошёл. Причина - выпускники онлайн школ.
Просто надо и бэкенд перевести на что-то флатероподобное, Django там или может ещё что-то с более низким порогом может есть))
Mirzapch
29.10.2022 17:28Упомянутая прогулка - "Удмуртский скороход"? Позвольте полюбопытствовать, в котором году ходили?
Интересное мероприятие, организуется туристическим клубом УДГУ...
sepulkary
29.10.2022 18:13@constantine_mitin, отдельное спасибо за иллюстрации. Такой шикарный уровень оформления и не в корпоративном блоге, даже удивительно. Вы сами рисуете или вам кто-то помогает?
yoshka
29.10.2022 19:36+1Кто-то еще расползается по смежным областям, кто-то уходит в консалтинг или в свой бизнес.
Еще чем ближе к 40, тем менее интересно вписываться в еще одну технологию. Просто потому что я уже знаю, каково это - изучить что-то новое за 2 недели. Been there, done that. А вот свой бизнес развивать уже интереснее, 100 км дистанцию пробежать интересенее, даже помидоры интереснее научиться выращивать, чем 100500 фреймворк осваивать.
lovermann
29.10.2022 19:49+1Вполне себе можно уходить туда, куда не может пойти молодёжь, а именно в консалтинг, архитектуринг и аналитинг. Да, составление ТЗ, сбор требований и маппинг процессов в компании, - это то, чему не научиться за пару лет, потому что нужен именно большой и долгий опыт. Конечно, BPMN, UML diagrams можно научиться и за пару месяцев, но без опыта этим не заработаешь.
Maccimo
29.10.2022 19:55+12исчезают программисты после 40 лет
Откуда вообще взялся этот шизофренический бред про «программисты исчезают»? Не конкретно в этой статье, а вообще. Это гимнастки после 20 лет исчезают, а программисты вечны.
victor_1212
29.10.2022 23:31+1согласен не исчезают, бывает что некоторые становятся известными, типа попадают в hall of fame, см https://www.rankred.com/greatest-computer-programmers/
получают почетные звания типа академиков, или например intel fellow, есть такая страница: https://en.wikipedia.org/wiki/List_of_programmers
в том числе для программистов из России:
https://en.wikipedia.org/wiki/List_of_Russian_IT_developers
ps
конечно последний список сильно не полный, кое с кем приходилось встречаться, но есть также достаточно много других людей, которые залуживают там быть
OGR_kha
30.10.2022 00:31+2Хм, у меня обратная ситуация - вошел в айти в 48: выучил на бесплатных онлайн курсах питон, фрилансю на Апворке, сейчас учу Постгрес. Плюс английский, естественно.
Вообще не понял смысл статьи.vadimr
30.10.2022 11:29+1Вопрос в том, что происходит после 20 лет непрерывной гребли на галере. Для Вас приобретёт актуальность в возрасте после 70, если ничем другим не будете заниматься.
funca
30.10.2022 01:13+1Как-то мы решили, что наши бэкенд разработчики (разработчики серверной части web-приложений) должны владеть PHP и Python одновременно. На освоение нового языка мы им давали как раз 2 недели.
Интересно, из каких соображений был выбран именно такой срок, и каковы были результаты через 2 недели? Только честно.
constantine_mitin Автор
30.10.2022 09:57+1Просто некоторая граница на освоение языка (можно же изучением заниматься бесконечно), многие справляются за неделю. Все же PHP и Python во многом похожи. Не в плане того, что у них под капотом, а в плане реального применения.
funca
30.10.2022 15:45Все же PHP и Python во многом похожи. Не в плане того, что у них под капотом, а в плане реального применения.
А что за предметная область и что и с чем сравнивали?
Gradiens
30.10.2022 01:30+1Да никуда мы не исчезаем! Как работали, так и работаем.
А то, что нужно вечно бежать чтобы остаться на месте - тоже некоторое преувеличение. Если просто найти нормальную работу, и просто работать на совесть (не на отвали, лишь бы не уволили, но и не сжигать себя, работая по ночам) то развиватсья будешь просто выполняя свои обязанности.
С возрастом, знаете ли, приходит осознание, что время - это не бесконечный ресурс. И если его оптималнее тратить, если научиться фокусироваться на наиболее важном, то и на работе будешь успешным, и в личной жизни ни себя, ни близких не обделишь.
Tresimeno
30.10.2022 19:31+1Если просто найти нормальную работу, и просто работать на совесть
... то для душевного спокойствия еще нужно держать всевышнего за гениталии и быть уверенным что в ближайшие 20-30 лет нормальная работа останется нормальной, а не продастся/не обанкротится/в нее не прилетит что-то с неба и т.д.
Gradiens
30.10.2022 23:0320-30 лет? Вот это горизонт планирования!
На мой взгляд, в среднем, 2-3 года стабильности вполне достаточно. А дальше, если что - можно просто найти еще одну нормальную работу. Мы же говорим о синьорах с 20+ годами опыта, не так ли? Поиск работы не должен стать проблемой.
К тому же, меняя работу (или должность) раз в 2-3 года вы, хотите того или нет, будете разносторонне прокачивать свой опыт.
Моя мысль не о том, чтобы найти себе теплое место и морально заранее превратиться в пенсионера.
Мысль в том, что вовсе не обязательно бежать впереди паровоза. Не надо бежать, чтобы остаться на месте. Все эти тренинги, конференции, курсы, самообразование, pet-projects, open source и прочее - это все очень хорошо, но вовсе не обязательно. Чтобы остаться на месте - достаточно просто работать на совесть и прыть по течению. Периодически менять работу, но не потому что "надо" а потому, что жизнь меняется.
Я вот сейчас осознанно стою на месте. Тимлидю в меру своих умений. В прошлом квартале намекали, что при моем желании можно из тимлида вырасти в техлида.
Но - нафиг, я хочу стоять на месте.
В этом квартале попал в топ-10% перформеров. Ок, спасибо, премия - это всегда приятно. Но я просто хорошо работаю. А вне работы заниматься повышением квалификации, изучением очередных модных библиотечек - не-не-не. Я буду заниматься семейными делами, хобби.
А в профессиональном плане буду просто стоять на месте. Я вышел на плато. Другие вершины покорять не собираюсь, потому что у меня помимо профессионального развития есть жизнь.
funca
30.10.2022 01:33Старую собаку не научить новым трюкам (я не про технологии, а про отношении к работе вообще). Кто жгет в 30, жгут и в 50, без относительно ролей. Кто в этом видит лишь способ заработка, продолжают решать свои однотипные задачи.
Если не идеализировать, то айти ни чем принципиально не отличается от других видов интеллектуального труда. Ощущения исключительности это сигнал, что пора расширить кругозор.
victor_1212
30.10.2022 16:12+2> Если не идеализировать, то айти ни чем принципиально не отличается от других видов интеллектуального труда. Ощущения исключительности это сигнал, что пора расширить кругозор.
исключительность IT вероятно себя исчерпала уже лет 30 назад, но принципиальная разница есть - это уровень стресса, реальность такова что интересного самостоятельного программирования становится все меньше, а работы с чужим плохо написанным кодом все больше, плюс средний уровень management (us) постепенно приближается к плинтусу , соответственно статус среднего программиста в средней компании получается чуть выше мебели, у начинающих программистов бывает много иллюзий на этот счет, но годам к 40 большинству все становится ясно, и конечно вызывает не самые приятные ощущения, разумеется есть исключения и в смысле нормальных компаний и грамотных руководителей, но это меньшинство, так что выбор вероятно на данный момент (в us) - либо работа на износ ради более-менее приличных денег например в Big 4, либо типа специалистом в узкой высокоприоритетной области например real time, которые всегда нужны, поэтому отношение будет другое, стресса меньше и работа интересней
niksite
01.11.2022 01:40Принципиально отличается спросом. Ни на какой другой интеллектуальный труд нет такого универсально высокого спроса почти в любой точке планеты.
Это, конечно, пройдет. Со временем. Но не факт что в этом веке.
nuald
30.10.2022 02:08+3Думаю, не помешали бы примеры, почему надо все время учиться, потому что видно, что есть недопонимание. Базовые вещи (алгоритмы) не особо поменялись (хотя, например, современный qsort - это уже не старый книжный, а модифицированный: https://awdesh.medium.com/dual-pivot-quick-sort-javas-default-sorting-algorithm-for-primitive-types-77342e1df5e5)
Просто приведу примеры тех технологий, которые использую по работе, и которых точно не было в прошлом веке:
zstd (2015) - использовать в наше время gz просто уже стыдно
linux kernel namespaces (2002)/cgroups (2007) - docker, LXC и в целом OCI
sponge functions (2007) - основа современных стандартов криптографии (SHA-3, и в этом году NIST выберет победителя для lightweight/hardware encryption)
SIMD (все это было и раньше, но SSE и NEON появлились только в этом веке)
сетевые протоколы (QUIC, DNS-over-HTTPS, WebRTC etc) - очень много появилось в последние два десятка лет.
И это надо знать - шифрование, сжатие данных, сети, контейнеры - это все входит в арсенал практически любого профессионального программиста. Если кому-то это не надо, то это очень узкий специалист.
0xd34df00d
30.10.2022 02:20+3но SSE и NEON появлились только в этом веке
SSE вышло с P3, который появился в 99-м. Да и до него был MMX ещё в первых пнях.
lexa
30.10.2022 21:44+1Мне сложно сказать про криптографию, не специалист.
Остальное перечисленное вами - ну была другая аббревиатура или другая реализация, но "что-то подобное" уже было в прошлом веке.
Да, последний пункт ("сетевые протоколы" поверх базовых TCP/UDP) - туда масса усилий вложено после 2000, но вот каковы принципиально новые концепции, которых не было известно 25-30 лет назад? Возможно они есть, но вот прям такие что прям вау?
От того что конкретная реализация (сжатия, simd) появилась недавно - это же не становится новой концепцией, правда?Areso
30.10.2022 22:17Websockets наделали много шуму.
Щас ещё gRPC
lexa
31.10.2022 11:31+1Цитато: "WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection." Че, реально?
gRPC - это еще одна реализация RPC, позволю себе процитировать wiki:Request–response protocols date to early distributed computing in the late 1960s, theoretical proposals of remote procedure calls as the model of network operations date to the 1970s, and practical implementations date to the early 1980s. Bruce Jay Nelson is generally credited with coining the term "remote procedure call" in 1981.[1]
Remote procedure calls used in modern operating systems trace their roots back to the RC 4000 multiprogramming system,[2] which used a request-response communication protocol for process synchronization.[3] The idea of treating network operations as remote procedure calls goes back at least to the 1970s in early ARPANET documents.[4] In 1978, Per Brinch Hansen proposed Distributed Processes, a language for distributed computing based on "external requests" consisting of procedure calls between processes.
Вот что действительно относительно новое - это что у каждого клиента мы можем ожидать работающую виртуальную машину (Java или Javascript), но тоже началось в 90е, хотя конечно не в таком развесистом виде как сейчас.Areso
31.10.2022 11:37+1Слушайте, если какой-то академик еще до моего рождения чего-то там придумал, не значит, что это использовалось в те же лохматые годы, особенно в том же виде, в котором мы это сегодня знаем.
А шум значит, что люди ринулись переписывать тонны кода.
lexa
31.10.2022 11:55Слушайте, ну RPC вовсю использовался так то (в NFS, например). Про bidirectional communications по одному соединению я и вовсе молчу.
Я ж спрашиваю про новые концепции, а не про новые реализации. Новые реализации конечно появились, еще бы.
funca
30.10.2022 22:42В теории теория и практика одно и то же, но на практике абсолютно разные вещи. Тот факт, что 30 лет тому назад нечто обсуждалось на уровне концепции, совсем не означает того, что вы сегодня сможете взять как технологию и применить в продакшн, не имея в этом ни какого опыта. Один и тот же функционал с availability 99.9 и с 99.999 архитектурно будут совершенно разными решениями, с разницей по стоимости на порядки. Да и сами технологии мутируют до неузнаваемости. Вон выше пишут, что с++ времён его изобретения и современный это по сути два разных языка.
lexa
31.10.2022 11:33Ну стоит знать историю, многие вещи 30 (и даже 50) лет назад не "обсуждались на уровне концепции" а были реализованы вполне.
Они могли не распространяться на прям весь интернет целиком, потому что медленно было, но локальным то сетям существенно больше лет.
YDR
31.10.2022 12:26каковы принципиально новые концепции, которых не было известно 25-30 лет назад? Возможно они есть, но вот прям такие что прям вау?
например, р2р-сети? Напстер где-то вблизи 2000 года появился, но это явно что-то новое.
Блокчейн (пусть вне криптовалют) - тоже существенно отличающаяся штука.
у нейронки основные принципы были известны достаточно давно, но мощно развиваться стали где-то с 2010
PuerteMuerte
31.10.2022 13:46+2например, р2р-сети?
В 2000-х их прикрутили для обмена музыкой и оно пошло в массы. Сама технология-то куда старше. Даже Фидонет, по сути, p2p-сеть :)
Блокчейн (пусть вне криптовалют)
Блокчейн - да, пожалуй сравнительно новая архитектура. Но я вряд ли ошибусь, если скажу, что за более чем десятилетие его существования разумных применений вне криптовалют для него не обнаружено. Под "разумным применением" я имею в виду такие задачи, которые с блокчейном можно решить быстрее/дешевле/эффективнее, чем без блокчейна.
у нейронки основные принципы были известны достаточно давно
А здесь требовалась аппаратная база - нейронки стали распространяться, когда в продаже появились доступные многопоточные вычислители.
lexa
31.10.2022 13:51+1ага, p2p, блокчейн, ML - нормальный список (с ML можно обсуждать что новое, что было, но там действительно есть серьезные новые достижения в 21 веке).
Я ж не говорю что прям совсем ничего нового нет, все-таки гигантская индустрия работает. Просто вот исходный обсуждаемый список, с SSE и NEON, он уж совсем примитивный какой-то.
plustilino
30.10.2022 07:08+1Ответ куда проще. После 35-40 лет сидеть по 8 часов к ряду - медленное самоубийство. До 30 у людей более высокая работоспособность.
funca
30.10.2022 16:06+2До 30 у людей более высокая работоспособность.
Главное, чтобы не было как в анекдоте про машинистку: могу печать со скоростью 400 знаков в минуту, но такая ерунда получается.
Въезжать в новую технологию, как правило, проще, чем в новую предметную область. Потому, что технология начинает бить по рукам за ошибки быстрее, и специалисты быстрее учатся их избегать.
Просчеты в дизайне со стороны архитектуры или бизнес домена при таком brute-force подходе становятся заметны лишь на этапах эксплуатации, а исправление обходится дорого. Если вам удалось собрать достаточно такого опыта и не выгореть к 30, вы счастливчик.
plustilino
30.10.2022 17:06+1Работоспособность - не скорость. Нередко надо удерживать много вещей в голове одновременно и легко между ними переключаться. Если человек вынужден вставать каждый час, он нормально не сконцентрируется. Если человек в зрелом возрасте, он быстро переключаться не может по физиологическим причинам. Он хорош только для анализа, прогноза, планирования. Но для них уже нужен большой предыдущий опыт.
funca
30.10.2022 22:23Умение переключаться это что-то из области темперамента. Мне всегда лучше удавалось писать код в состоянии потока, когда снаружи ни что не отвлекает. Поэтому часто работал по ночам. Трындеть же на митингах могу хоть весь день, на абсолютно разные темы.
Knightt
31.10.2022 13:22+2Если человек вынужден вставать каждый час, он нормально не сконцентрируется.
видел кучу программистов бегающих курить каждый час
PuerteMuerte
31.10.2022 13:56Если человек вынужден вставать каждый час, он нормально не сконцентрируется
Всё это индивидуально. Я, наоборот, постоянно переключаюсь между рабочим потоком и жвачкой до мозгов, у меня так наиболее продуктивно получается работать. И я в зрелом возрасте :)
Mikhail1972
30.10.2022 09:58очень большой наплыв программистов был в 1с 7.7. в связи с довольно простыми решениями , не большими запросами и прозрачностью кода, много людей могли освоить, с прявление 1с 8 версии люди стали исчезать, запрос 50 строк и 1000 строк большая разница, а даде 5 вложенных вызовов не каждый осилит , вот так прошел отсев. Бывших 7 ков можно много, где встретить с воспоминаниями о красоте решения. Но 1с 8 это просто другой уровень требует впервую очередь большое ОЗУ разработчика))
funca
30.10.2022 15:09Предыдущие 1С это локальная вариация на тему COBOL: такой же бизнес ориентированный DSL, и с такими же специфичными проблемами в плане сопровождения. Деление на сисмемных программистов и прикладных с узкой специализацией в своих предметных областях это не мейнстрим. Рынок подталкивает разработчиков к универсализации.
Mitch
31.10.2022 00:37+4Нло прилетело и выгрузило всех потерянных 40-летних программистов в этом треде.
Spaceoddity
31.10.2022 01:29Кроме того, сейчас начали набирать популярность сервисы NoCode и LowCode, которые позволяют создавать несложные мобильные приложения в визуальном редакторе.
Всё-таки к вёрстке вы имеете очень опосредованное отношение, да?))
Потому что уже лет 20 существует такая софтина как Adobe Dreamweaver. Лет 15 назад у меня дошли руки её попробовать... Вкратце суть - либо лэйаут на основе корневого элемента table, либо абсолютное позиционирование. Ну как бы для любого сервиса (ну кроме непрофильных "хомяков" - адвокату домашнюю страничку своей конторы позволительно слепить в Тильде) это даже в те времена было лютой халтурой. Впрочем, это уже оффтоп.
По сабжу. Тезисно:
Мне 41. Профессий и увлечений я попробовал достаточно, но в итоге все равно вернулся в IT. "Вернулся", потому что "начал" лет в 12 - с подаренного отцом ZX-Spectrum. Разумеется, после освоения азов в таком возрасте (сейчас это не впечатляет, но это 93-й год был), "войти" в IT-шную специальность - не представляло какой-то особой трудности.
Потом много чего было. И уход на фриланс, и попытки попробовать на "постоянке в офисе", и несколько циклов выгораний, кризис среднего возраста, "поиски себя" и т.д. Сейчас, в принципе, я навел в голове порядок (хотя с мотивацией есть проблемы). И вот что хочу сказать - да, в IT действительно надо постоянно учиться. И? Почему это плохо? Преодоление физических нагрузок (прекратите без конца проводить аналогии со спортом! все и так в курсе что айтишники следят за здоровым образом жизни) совершенно не то же самое, что тяга к овладению новыми знаниями. Просто кому-то это надо, а кому-то категорически нет. Я смотрю на своих сверстников, которые сейчас "обросли жирком в кабинетах" и извините, но меня такая перспектива никогда не прельщала. Я предпочитаю, чтобы мой мозг постоянно работал. В конце концов, старческая деменция - не такое уж и редкое явление. Я в принципе не могу заниматься деятельностью на которой "тупеешь", какой-бы комфортной во всех остальных аспектах эта деятельность ни была (с алкоголем завязал по этой же причине).
А теперь довольно пафосный (ну что поделать - именно так я это и понимаю) вывод: в IT вам будет комфортно, если вы... не можете жить без IT. В противном случае вас эта кухня довольно быстро прожует и выплюнет. Ну вот актёры же тоже неплохо зарабатывают? И условия труда у них тоже вполне комфортные. И тоже выгорания случаются. И прям на "рабочем месте". И даже такая же патетика - "вы станете настоящим актёром, только тогда когда поймете что не можете жить без сцены". Только вот почему-то интернет не забит рекламой актёрских курсов. Потому что любому адекватному человеку понятно - случайные люди в профессии редко становятся квалифицированными специалистами. Но вот именно с IT это и не работает. Вот такое ощущение, будто большинство считает что для любой другой профессии нужны какие-то скиллы, талант, предрасположенность... а в IT сможет любой дурак... Откуда это пошло - непонятно... То ли обыватели решили, что раз они могут довольно просто установить на смартфон приложение - то им прямая дорога в IT))
Так что ещё раз: если чувствуете что IT - это "не ваше", бегите отсюда)) Будет только хуже.
vassabi
31.10.2022 13:57возможно - потому что актеров сейчас нужно не так много, как программистов ?
ну и еще с найма программистов - капает больший % рекрутерам :)
acordell
31.10.2022 11:48+2Интересно, а почему, собственно, граница именно в 40 лет выбрана? Я вот тут давеча взял на работу дотнетного сеньора 52 года. Все по классике: старая школа МФТИ, 20 лет плюса, 20 лет дотнета...Ну... с пересечением в смысле. Так вот, доложу я вам, это не просто старый конь, что не портит борозду. Это, блин, землеснаряд! Он в легаси коде ориентируется как у себя дома и хреначит, хреначит, хреначит, только задачи успевай подносить. Причем, качество кода выдает такое, что хоть распечатки на стенку в золотой рамке вешай и в них носом джунов тыкай.
SteelRat
31.10.2022 13:05+1Мне кажется, что одна из очень больших проблем современного IT (помимо случайных людей), это HR. Я вот, как человек, который много лет занимался администрированием баз данных и который хочет вернуться к разработке, просто не могу пройти барьер в виде HR из-за того, что у меня в резюме указано. При всем при этом я со школьных лет и по сегодняшний день что-то пишу (автоматизация, для себя, в качестве обучения) и уверен, что на джуниорские и миддловые позиции вполне мог бы пройти собеседование, но хрен. Ну и 40 скоро уже.. Хотя я не ощущаю себя старше 25. Понимаю, что HR как фильтр нужны и люди вроде меня это те, кем можно принебречь. Но мне кажется, я ничем не хуже в профессиональном плане многих других и с этой системой что-то не так.
vtal007
31.10.2022 17:39Думаете сидит себе HR и думает, как бы ему саму себе усложнить задачу. Так что ли?
Этот барьер не HR ставят, а клиенты (внутренние и внешние). Если они хотят видеть до 30-и, то HR то что должен сделать? подделать Ваш паспорт что ли?Tresimeno
31.10.2022 20:04Этот барьер не HR ставят, а клиенты (внутренние и внешние).
Иногда такой барьер вполне себе ставит сама ХРюшка. Особенно если она ищет таким образом себе мужа, формируя массовку нанимаемых (реальные истории, с 2000х слышал, и не раз)
vtal007
31.10.2022 20:06да-да, именно так. именно все HR-ы незамужние девушки и вместо работы ищут себе богатенького молодого программиста
А молоденькие неженатые программисты ходят на собеседования не чтобы работу найти, а чтобы присмотреть молоденькую симпатичную HR-у (реальные истории, слышал еще до нашей эры)
Ах да, Вы же написали "иногда". А иногда бывает все, кроме встречи с динозавром (с которым, как известная, встреча 50х50)Обсуждается ситуация в целом. что, SteelRat попадаются исключительно HR-ы, которые ищут мужа и поэтому не рассматривает его резюме? так что ли? к чем это ваше "иногда"
Я вам таких "иногда" историй могу рассказать, что хватит на целую книгу. А если еще подливать... Причем не тех, что слышал, а те, что видел своими глазами
Вот на ваших работах было, чтобы мидл-менеджеры дрались прямо в офисе? значит ли это, что все мидл-менеджеры деруться? значит ли что во всех обсуждениях мне надо писать "иногда мидл-менеджеры деруться"
Bedal
31.10.2022 14:12Как программист, уже 25 лет назад переваливший через указанную сакральную цифру, могу сказать, что единственное важное - потеря мотивации.
Осознание, что на самом деле все усилия - только ради того, чтобы облегчить природе размножение идиотов, сильно убавляет энтузиазма. Тем не менее, после длительного перерыва в собственно программировании с огромным удовольствием вернулся к нему (на работе могу себе позволить заниматься только тем, что мне интересно) - соскучился. Но после февраля отрезало, наверно, окончательно. Исполняю, что должен, не более того.
7313
31.10.2022 16:03А у меня многие знакомые (и я тоже) на старости лет ушли из программирования в сантехники небоскреба ИТ - в сисадмины :) Некоторые даже очень удачно - шарят в никсах, развертывают рабочие какие-то джайлы за 5 сек одним скриптом и т.д. А остальные тупо мышевозят в каких-нибудь мелких конторах и получается как-то поспокойнее.
PS Еще бы не путали нас с монтажниками (ноги и спина уже не новые) и не эти долбаные пучки телефонии, нарукожопленные кем-то в начале нулевых, которые просто страшно трогать, то было бы вообще замечательно :)
Dikoy
31.10.2022 20:43+1То есть сама отрасль лишает свой хвост работы, отбрасывая его.
Это естественный процесс отъёма поляны, который происходит в любой отрасли. В "гроздьях гнева" фермеров вытеснили трактора, а в IT более умные айтишники делают инструмент для отжима поляны у более глупых айтишников, которые тупо работают руками.
Профессионалы остаются востребованными и после 50-60 лет.
Тока надо, чтобы это поняли на рынке. Из недавнего разговора с HR:
"а вы же ещё и дизайнером работали?".
"Нееет, почему Вы так решили?".
"Ну у вас тут написано in chief designer role".
anatolius
ну таки "Куда исчезают программисты после 40 лет?"
pavel_raskin
Внимательнее нужно быть, внимательнее... :)
Hidden text
shasoftX
Подтверждаю. 5 лет уже среди зеленых человечков живу.
gabirx
так мобилизации пару месяцов всего?
Drayden
А вот зеленые человечки появились в 2014м...
lagudal
Инопланетяне, похитившие пьяного русского программиста, не выдержали и таки дали ему порулить.
Wan-Derer
М... А они достаточно вежливы? :/
rezdm
Мы тут.
checkpoint
Подтверждаю, мы никуда не деваемся, просто у нас свой закрытый клуб по интересам. Мы не пользуем телеграммы, фейсбуки и вконтакты и не содрагаем воздух. Мы любим обсуждать "как это было в 80-х и 90-х" и ненавидим всё новое, которое, по сути, давно забытое старое, но вывернутое наизнанку. Мы с неимоверной легкостью умеем отсеивать зерна от плевел и попусту не тратим своё драгоценное время на технологический шлак, который производит современная цивилизация. Мы программируем на голом "Си" и часто вспоминаем ассемблер. Мы стараемся не использовать сторонние библиотеки, у нас есть свои компактные и хорошо оптимизированные парсеры JSON, XML и вообще всего в виде одного .h файла. Мы вообще никуда не торопимся, а медленно и методично делаем своё дело. Мы, как в том анекдоте, медленно спускаемся с горки и берем все стадо.
semennikov
А я с Вами и полностью согласен, и столь же полностью не согласен. Ну появляются же новые я бы даже сказал "сущности" которых раньше не было, и приходиться и их тоже объезжать. Ну например современные FPGA, или ОС РВ. Я тоже пишу в основном на С и ассемблере, но иногда приходится залезать и в другие языки. Ну не напишу я на С распознавание образов. Точнее, написать то наверное напишу, но проще взять полуготовое на другом языке и прикрутить к своему коду
ladle
И с каких это пор ОС РВ стало "новой сущностью"?
semennikov
Сами по себе ОС РВ конечно не новые, но за последнее время сильно изменились и нужно постоянно за ними следить. И, возможно, это не самый удачный пример.
arheops
FPGA это сущность из 1984го. Ей чуть меньше, чем 40-летним программистам.
old_bear
Современные FPGA от тех, которые были 20+ лет назад (когда я начинал), принципиально ничем не отличаются, кроме жирности и доступных частот. А внутрянка та же и осталась - LUT-ы, FF-ы, DSP-блоки (умножение+сложение), всякие там SERDES- ы для интерфейсов... Даже встроенные процессоры уже были в то время, пусть и не такие модные как ARM.
Методология работы тоже не то чтобы сильно поменялась, RTL-код как рулил так и рулит, и отличия в основном в использовании или не использовании всяческих кодо-генераторов, начиная от самописных скриптов на Perl и заканчивая Chisel-ом. Ну может HLS стал за это время чуть менее тупым и теперь годится для быстрого прототипирования или не слишком требовательного к производительности продакшена (простите за англицизм).
Из относительно нового разве что
XilinxАМД с его Versal-ом, но это уже не совсем FPGA.0xd34df00d
Мы становимся героями очередных CVE о переполнении буфера, use-after-free и им подобных.
checkpoint
Чем меньше кода, тем меньше места для ошибки. Возмите любую библиотеку для парсинга XML и посмотрите сколько она тянет за собой зависимостей. Вы уверены, что во всем этом г@вне нет ошибок ?
0xd34df00d
Это было бы хорошим аргументом, если бы количество ошибок зависело только от размера кода. К сожалению, это не так: оно зависит и от выразительности языка, и от количества пользователей библиотеки, и количества читателей библиотеки, и так далее.
Да и на хаскеле получится короче, чем на сях.vkni
Зато Хаскель тока адын. Мы (я), кста, таки затащили 9.2.4, ведь Эрик нас оставил с 8.8.3. И вот что я имею сказать по опыту: совершенно, блин, непонятно, как мигрировать на 9.4.2
anarchomeritocrat
Ага, от души прям как точненько, а за кадром и самое главное, что по сути нам то до лампочки рассуждения эти всякие, что на тему куда мы деваемся, чем живём, как зарабатываем, потому что мы вне любой хайпогенной аналитики на тематику а-ля "сколько рубят" и особенно "на кого вкалывают", так как познали давно уже дзен независимого существования в мире работы для удовольствия, а бюджет свой ходлим тихонечко, иногда выводя сатошинки на жизнь свою безмятежную, с интересом врываемся во всё новое, не влияя ни как на вашу статистику, от чего ухмыляемся добренько, понимая как она далека от реальности, иллюзиями энтерпрайза и корпорейта пропитанная, так как то что от нас в на гитхаб пушится, сие лишь пыль от того что в гитлаб коммитится, на своей виртуалочке хостящийся, а ещё ВПН-ы у нас самодельные, в коих серты лишь нам подконтрольные, и в даркнетах мы есть и фидо ещё живо и везде при везде есть лазеички, потому что для нас килобайты простор, в мире где гигабайты не ёмкость и сто мегабит не канал, так вот и живём потихому - в виме код, сикэш на сто нод, ну а главное, то что нам есть стремиться к чему с превеликим на то удовольствием )
Am1GO
Пафос аж из монитора потёк.
Офрогарфию хоть бы потрудились проверить, достопочтенный вы наш.
anarchomeritocrat
это не пафос, это ирония, порождённая очередными рассуждениями на тему куда я и такие как я делись, о профессиональных, там, выгораниях, конце карьеры, уходе в закат и прочих возрастных, типа профессиональных, заболеваниях, свойственных труженикам индустрии заработка бабла кому то за зп, с замахом натянуть сову на глобус при помощи обобщения всех под один шаблон и с прицелом на то что это норма и закономерность )
ilmarinnen
Вафин, перелогиньтесь)
anarchomeritocrat
На хабре мультиаккаунтинг не этичен ))
KvanTTT
Это же сарказм?
vkni
Ну есть масса действительно новых вещей, всё-таки. Особенно с учётом того, что С сколько десятков лет. Да и ассемблеры бывают сильно разные.
checkpoint
Спиваются ?
Wan-Derer
Вариант: уходят на пенсию (как военные), устраиваются в ЧОП (как военные), охраняют склады (как ЧОПовцы). Просто и ЧОП, и склады - специальные, айтишные :)
vin2809
А еще у них может быть домик в деревне или дача...
rukhi7
Я бы лучше спросил: я с чего автор статьи взял что они куда то исчезают?
По моему опыту кто работал до 40 так же и работают после 40.
Те кто уехали в США, в Европу, уехали туда где то после 30 максимум.
Есть естественная убыль с возрастом, могу предположить, что тех кому 40 - 60 наверно меньше чем тех кому 20 - 40, чисто статистически.
Может быть этим все и определяется?
Странно рассуждать о причинах некоторого факта, у которого нет хоть каких то объективных подтверждений.
Kanut
Это даже не естественная убыль. По грубым прикидкам количество айтишников раньше удваивалось примерно каждые 5 лет. То есть опять же если совсем грубо, то 25-летних айтишников у вас будет в два раза больше чем 30-летних и в восемь раз больше чем 40-летних.
То есть чем более "старых" айтишников вы ищете тем меньше их будет в процентном отношении.