Comments 281
ну таки "Куда исчезают программисты после 40 лет?"
Внимательнее нужно быть, внимательнее... :)
Hidden text
Мы тут.
Подтверждаю, мы никуда не деваемся, просто у нас свой закрытый клуб по интересам. Мы не пользуем телеграммы, фейсбуки и вконтакты и не содрагаем воздух. Мы любим обсуждать "как это было в 80-х и 90-х" и ненавидим всё новое, которое, по сути, давно забытое старое, но вывернутое наизнанку. Мы с неимоверной легкостью умеем отсеивать зерна от плевел и попусту не тратим своё драгоценное время на технологический шлак, который производит современная цивилизация. Мы программируем на голом "Си" и часто вспоминаем ассемблер. Мы стараемся не использовать сторонние библиотеки, у нас есть свои компактные и хорошо оптимизированные парсеры JSON, XML и вообще всего в виде одного .h файла. Мы вообще никуда не торопимся, а медленно и методично делаем своё дело. Мы, как в том анекдоте, медленно спускаемся с горки и берем все стадо.
А я с Вами и полностью согласен, и столь же полностью не согласен. Ну появляются же новые я бы даже сказал "сущности" которых раньше не было, и приходиться и их тоже объезжать. Ну например современные FPGA, или ОС РВ. Я тоже пишу в основном на С и ассемблере, но иногда приходится залезать и в другие языки. Ну не напишу я на С распознавание образов. Точнее, написать то наверное напишу, но проще взять полуготовое на другом языке и прикрутить к своему коду
И с каких это пор ОС РВ стало "новой сущностью"?
Современные FPGA от тех, которые были 20+ лет назад (когда я начинал), принципиально ничем не отличаются, кроме жирности и доступных частот. А внутрянка та же и осталась - LUT-ы, FF-ы, DSP-блоки (умножение+сложение), всякие там SERDES- ы для интерфейсов... Даже встроенные процессоры уже были в то время, пусть и не такие модные как ARM.
Методология работы тоже не то чтобы сильно поменялась, RTL-код как рулил так и рулит, и отличия в основном в использовании или не использовании всяческих кодо-генераторов, начиная от самописных скриптов на Perl и заканчивая Chisel-ом. Ну может HLS стал за это время чуть менее тупым и теперь годится для быстрого прототипирования или не слишком требовательного к производительности продакшена (простите за англицизм).
Из относительно нового разве что Xilinx АМД с его Versal-ом, но это уже не совсем FPGA.
Молодняк... Я до прошлого года даже на JCL писал. ;-)
Чем меньше кода, тем меньше места для ошибки. Возмите любую библиотеку для парсинга XML и посмотрите сколько она тянет за собой зависимостей. Вы уверены, что во всем этом г@вне нет ошибок ?
Зато Хаскель тока адын. Мы (я), кста, таки затащили 9.2.4, ведь Эрик нас оставил с 8.8.3. И вот что я имею сказать по опыту: совершенно, блин, непонятно, как мигрировать на 9.4.2
Вот что бывает, когда человека со степенью сажаешь логи разгребать.
Я всё это время совершенно не понимал, что же он там делает.
А что с 9.4.2?
Новая сборочная система. Я, как один из сборщиков ALT, всей душой ненавижу, когда меняются сборочные системы. А ещё ненавижу убогие попытки автоопределения того, что в системе где находится (особенно написанные на С++, как в Шланге — https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Gnu.cpp#L2207 и ниже :-) ).
P.S.
Солярка, кстати, живее всех живых. :-)
А что, использование стандартных библиотек как-то защищает от этого?
Что чаще всего ломают? То, что сильно распространено.
Вы очень-очень недооцениваете эффективность метода "security through obscurity". Уникальные кастомные решения, если они не совсем уж дешманские, куда устойчивее к взлому, чем популярные библиотеки. Ну просто потому, что чуваков, способных декомпилировать ваш код, найти в нем уязвимость, и готовых потратить достаточно много времени профессионала на эту кропотливую работу, в интернетах этак на пять порядков меньше (цифра условная, но вряд ли далека от истины), чем чуваков, способных прочитать про свежие патчи стандартных библиотек и подловить вас в тот момент, когда вы ещё не успели накатить последний патч.
Знаете, как один мой сервер проходил банковский аудит безопасности когда-то? Аудиторы просто взяли и запустили здоровенный скрипт, в котором были тщательно собраны все эксплойты, до которых они дотянулись за несколько лет, и натравили его на эту мою софтинку, чтобы он просто применял один за другим и логировал результат. Эксплойты дыр из разных серверных софтин и разных библиотек и разных их версий, ну и предполагалось, что если одно из них применяется, то соответствующий эксплойт сработает и в логе покажет наличие уязвимости. Полагаю, у многих кулхацкеров есть что-то такое же.
Это не совсем фаззинг, здесь речь шла о применении известных библиотечных эксплойтов. Фаззинг сам по себе всего лишь один из возможных векторов атаки, и далеко не самый результативный.
Если они уже известные, то почему вы ещё не обновили используемые библиотеки?
Допустим, просто не успел. Я начинаю рабочий день с кофе, а не с обновлений библиотек. А хакер, может быть, больше предпочитает вечером пиво, чем утром кофе. Или я просто ленивый. Или наоборот, обнаружил проблемы несовместимости, и это обновление мне не подошло. Да стопицот есть причин, почему у меня может быть не актуальная версия какой-то либы.
Я, похоже, не смог донести свой вопрос. Кто мешает аудиторам вместо брутфорса эксплойтов применить фаззинг
Никто не мешает, кроме того момента. что вероятность успеха фаззинга невелика, и требует как минимум, серьёзной предварительной подготовки, знания вызовов API и так далее, а вероятность успеха брутфорса эксплойтов и велика (особенно в первые часы после выхода свежего эксплойта к популярной либе), и делается, по сути, уже готовыми средствами.
Ага, от души прям как точненько, а за кадром и самое главное, что по сути нам то до лампочки рассуждения эти всякие, что на тему куда мы деваемся, чем живём, как зарабатываем, потому что мы вне любой хайпогенной аналитики на тематику а-ля "сколько рубят" и особенно "на кого вкалывают", так как познали давно уже дзен независимого существования в мире работы для удовольствия, а бюджет свой ходлим тихонечко, иногда выводя сатошинки на жизнь свою безмятежную, с интересом врываемся во всё новое, не влияя ни как на вашу статистику, от чего ухмыляемся добренько, понимая как она далека от реальности, иллюзиями энтерпрайза и корпорейта пропитанная, так как то что от нас в на гитхаб пушится, сие лишь пыль от того что в гитлаб коммитится, на своей виртуалочке хостящийся, а ещё ВПН-ы у нас самодельные, в коих серты лишь нам подконтрольные, и в даркнетах мы есть и фидо ещё живо и везде при везде есть лазеички, потому что для нас килобайты простор, в мире где гигабайты не ёмкость и сто мегабит не канал, так вот и живём потихому - в виме код, сикэш на сто нод, ну а главное, то что нам есть стремиться к чему с превеликим на то удовольствием )
Пафос аж из монитора потёк.
Офрогарфию хоть бы потрудились проверить, достопочтенный вы наш.
это не пафос, это ирония, порождённая очередными рассуждениями на тему куда я и такие как я делись, о профессиональных, там, выгораниях, конце карьеры, уходе в закат и прочих возрастных, типа профессиональных, заболеваниях, свойственных труженикам индустрии заработка бабла кому то за зп, с замахом натянуть сову на глобус при помощи обобщения всех под один шаблон и с прицелом на то что это норма и закономерность )
Вафин, перелогиньтесь)
На хабре мультиаккаунтинг не этичен ))
Былинненько :) Фидо рулез форева!
Я в этих ваших Сях ничего не понимаю, максимум, код для Ардуино поправить.
Но у меня VPN самописный много лет, вся работа в облаках, на своих серверах. В Гугле и Ажуре любую фигню можно подключить практически бесшовно. Нейросети, перевод, все такое. Могу с любого утюга зайти на сервер, править код и деплоить. Только браузер нужен. Если я свой боевой лаптоп утрачу, это будет печаль, но не катастрофа.
ЧЯДНТ?
Это же сарказм?
и ненавидим всё новое, которое, по сути, давно забытое старое, но вывернутое наизнанку.
Ну есть масса действительно новых вещей, всё-таки. Особенно с учётом того, что С сколько десятков лет. Да и ассемблеры бывают сильно разные.
так вам не "после 40-ка", а "после 60-ти", видимо?
Блин, и снова ты :)
Спиваются ?
Куда исчезают программисты после 40 лет?
Вариант: уходят на пенсию (как военные), устраиваются в ЧОП (как военные), охраняют склады (как ЧОПовцы). Просто и ЧОП, и склады - специальные, айтишные :)
Я бы лучше спросил: я с чего автор статьи взял что они куда то исчезают?
По моему опыту кто работал до 40 так же и работают после 40.
Те кто уехали в США, в Европу, уехали туда где то после 30 максимум.
Есть естественная убыль с возрастом, могу предположить, что тех кому 40 - 60 наверно меньше чем тех кому 20 - 40, чисто статистически.
Может быть этим все и определяется?
Странно рассуждать о причинах некоторого факта, у которого нет хоть каких то объективных подтверждений.
Есть естественная убыль с возрастом, могу предположить, что тех кому 40 — 60 наверно меньше чем тех кому 20 — 40, чисто статистически.
Это даже не естественная убыль. По грубым прикидкам количество айтишников раньше удваивалось примерно каждые 5 лет. То есть опять же если совсем грубо, то 25-летних айтишников у вас будет в два раза больше чем 30-летних и в восемь раз больше чем 40-летних.
То есть чем более "старых" айтишников вы ищете тем меньше их будет в процентном отношении.
Robert Martin который Uncle Bob, емнип, про это целую лекцию читал. Очень быстро росло количество рабочих мест, предыдущие айтишники все остались, но растворились в потоке новых людей.
Ну и переход на менеджерские позиции, пенсия, естественная убыль. Некоторые устроились на комфортные позиции, как хвастается товарищ выше. Там их никто не трогает и не видит.
Кармак рассказывает - большую часть своей карьеры я сидел один в своем офисе и пилил код, и мне было офигенно. Ни разу не выгорал.
Неверно было бы полагать, что дело в «молодости» области информационных технологий. Это не правда. Знаете, первое поколение программистов уже давно умерло от старости. Многие профессиональные программисты уже вышли на пенсию.
Так изначальный тезис, вроде бы, был о существенно меньшей распространенности IT-технологий 20-30 лет назад, а не о полном их отсутствии. И примеры Брукса или академика Ершова его никак не опровергают.
А под конец пришли сервисы типа Тильды. Это конструкторы сайтов, которым могут пользоваться непрограммист. <...>
Куда делись те люди, которые ещё недавно разрабатывали сайты за 5 тысяч рублей на потоке? Правильно - были вынуждены искать новую работу.
Перешли на Тильду. Я серьезно.
P. S. Так и не смог найти в статье ответа на вопрос, который содержится в ее заголовке. Senior COBOL developers из дома престарелых можно считать разве что только контрпримером :)
Да там и дальше можно продолжать разбирать по всем пунктам.
Нужно постоянно учиться: так программисты в этом совсем не уникальны. Врачам, ученым, юристам и многим другими профессиям тоже надо постоянно учиться, однако это не является поводом уйти из других профессий после 40.
Крупные корпорации с устаревшими технологиями: так как раз возможность взять паузу в такой сложной для автора гонке обучения не уходя из профессии, наоборот там рады тем кто за 40.
Нужно любить работу: ну так здесь разница только в том, что видимо айтишнику чуть проще сменить род деятельности, чем токарю. Может это кризис среднего возраста виноват, а не айти?
А как люди, проработавшие почти 20 лет могут быть случайными в профессии я не поняла. Случайными сорокалетними могут оказаться те, кто туда решил заглянуть в 35+. Ну так они в этом мало отличаются от тех, кто начал в 20, это не от возраста зависит.
Айтишнику сменить род деятельности психологически сложнее, чем во многих других профессиях: скорей всего, это приведёт к сильному проседанию по зарплате, немногие готовы, особенно после 30-40.
А другие делают накопления для пассивного дохода и "ранней пенсии". Все же в нашей сфере мало кто живет от зарплаты до зарплаты, и накопить "подушку" на год нормальной жизни, пока идет становление в новой сфере более чем реально.
Перестаньте читать тиньковжурнал). А если серьезно, то у людей под 40 чаще есть семьи с уже подросшими детьми, что тянет совсем несоразмерные траты по сравнению с молодыми одиночками или даже семьями с младенцами. Нет, речь не о стоимости подгузника-корма, речь о привычке жить на доходы itшника уже не одного человека, а 3-4... да с учетом того, что люди под 40 росли в начале 90х, когда не было ничего, они теперь с комплексом гиперлюбви к детям. У меня в жизни как-то так получилось, что доходы росли скачкообразно, в два раза. И я понял одно - денег всегда будет недостаточно - нужна будет квартира сильно побольше и в центре, ребенок увлечется лошадками и мотоспортом, жена захочет быть "элегантной и более привлекательной для мужа", что с возрастом под 40 "чуть" дороже, сам захочешь не только работать и играть, а еще заняться чем-то интересным и скорее всего хобби тоже окажется не копеечным... этот процесс бесконечен. Поэтому сегодня накопления 40 летних, в большинстве своем, это не деньги на счете или "акции", это хорошая квартира, дачка с бассейном и гаражом на пару машин, красивая жена и счастливые дети, иногда бизнес (в it) - признайте, сложно от этого отказаться ради того, что бы год входить в другую отрасль.
Так изначальный тезис, вроде бы, был о существенно меньшей распространенности IT-технологий 20-30 лет назад, а не о полном их отсутствии.
В этом и есть ответ. Серьёзно. 10 лет назад о 30-летних программистах говорили в таком же контексте, как сейчас о 40-летних. Представьте, как тяжело было начать заниматься программированием в 90-х, когда компьютеры были роскошью, а интернета, можно сказать, вообще не было.
С удешевлением компьютеров и распространением интернета (довольно доступным он стал во второй половине нулевых) количество программистов увеличилось на порядки. И представителям этой первой массовой волны сейчас как раз где-то от 30 до 40 лет. И да, примерно половина из них это физики, математики и инженеры, по образованию с IT не связанные. В этом автор статьи прав.
В 90-е годы начать заниматься программированием было куда легче чем сейчас. Не было развесистого древа технологий, где не знаешь, за что хвататься. Не было кучи библиотек для каждой платформы, и в целом онлайн для развития был не нужен. В 90-е годы ты выбирал язык программирования (что чаще всего означало "сложный" выбор между С++ и Паскалем/Delphi), потом покупал одну толстую книжку по выбранному инструменту, и по окончании прочтения в принципе уже мог что-то делать и даже продать. Естественно, не серьёзным компаниям, но и покупатели тогда были ничуть не избалованы навороченным софтом. Они зачастую были рады и консольной утилитке, которая при запуске делала какую-то нужную рутинную работу для них.
По-моему вы с нулевыми путаете. Я по такому алгоритму в 2004-м начинал (с Delphi и C++, без доступа к интернету).
А в 90-х самым сложным был шаг - купить компьютер. Самый простенький PC стоил примерно 15 средних зарплат, т.е. около 1 млн рублей в пересчёте на текущие цены.
В нулевых уже было куда больше вариантов - тут и веб-разработка, PHP, JavaScript, собственно Java уже была популярной, набирал обороты дотнет и т.д. Вы в 2004-м году начинали с Delphi, а я уже заканчивал, т.к. клиенты хотели дотнета, а восьмая Delphi под дотнет была совершенно невразумительной.
В 90-е я учился программировать на "Поиске" за сто баксов. Туда не поставишь Delphi, но все более-менее актуальные средства разработки под DOS, которая была актуальна чуть ли не до конца 90-х, там работали. Даже худо-бедно ворочались самые последние версии Борланд Паскаля и С++. И эта машинка была доступна, по сути, практически любому студенту-айтишнику. Ну или как вариант, почти любой советский х86 также годился, но у Поиска был бонус в том, что это конструктор, который можно было покупать по частям, как бюджет позволял.
До веб-разработки дело только в 2006 году дошло, когда стало по карману покупать 100 Mb трафика в месяц)
а восьмая Delphi под дотнет была совершенно невразумительной
Это да. Ещё и C# Builder был))
В 90-е я учился программировать на "Поиске" за сто баксов.
Я даже не слышал про такое. Откуда он у вас появился? У нас в школе были Агаты, но они как-то не вызывали желания что-то подобное заиметь.
Мне кажется у каждого свой инфопузырь, определяемый локальными условиями. В 2001 моя первая работа была связана с развитием Delphi+JS+IIS ASP, где в десктопные приложения встраивалось, как бы сейчас сказали web view (IE5 как компонент ActiveX). В 2003 бекенд переписал на LAMP и предпринимал попытки переделать формы Delphi на TCL/TK. В обоих случаях я не угадал, куда через 20 лет повернется индустрия. :)
Мне кажется у каждого свой инфопузырь, определяемый локальными условиями.
Да, пожалуй, так и есть. Не было глобализации и массовости, поэтому у каждого был свой уникальный путь.
В обоих случаях я не угадал, куда через 20 лет повернется индустрия. :)
Ну, ставки на 20 лет - это дело неблагодарное. Впрочем, я пару лет работал на LAMP, а в 2008 году поставил на Ruby и эта ставка вполне успешно сыграла. В 2016-м поставил на Elixir. С ним не всё так бомбезно, как с Ruby развивается, но технология зрелая и качественная, так что в целом тоже не прогадал.
Я даже не слышал про такое. Откуда он у вас появился? У нас в школе были Агаты, но они как-то не вызывали желания что-то подобное заиметь.
Поиск - это, как по мне, был самый распространённый советский x86 компьютер (тогда это называли "IBM-совместимый"). Он был жутко медленный, но при этом дешёвый, в базовой комплектации стоил как хороший Спектрум. Я просто купил его на радиорынке за 60 баксов у какого-то мужика (там было несколько "точек", где торговали именно Поисками и модулями расширения к ним), и через пару месяцев отдельно дисковод к нему.
До веб-разработки дело только в 2006 году дошло
Ну а как же хардкор - диалап, хомяк на народ.ру или геоситиз? :)
В гор. Уфа "Поиски" продавались в ТЦ "Башкирия" в том же отделе, где и телевизоры. Самые крутые модели были с 286 процессором и EGA-видеокартой, но мне покупали, вроде в 1994 году, минимальный "Поиск 1.06" из позднесоветских комплектующих, он почти совместим был с PC XT и CGA-видеоадаптером, но без аппаратного знакогенератора, так что текстовый режим был весьма уныл))
Поскольку собирали их в Киеве, то клавиатура имела расширенную украинскими символами Ґ, Ї, Є кириллицу.
Дисковод тоже докупили позже отдельно, и тогда у меня появился доступ к Turbo Pascal 5.5 (можно сказать, ранний прародитель Delphi) и Turbo Assembler.
Позже уже, когда на втором курсе универа учился, полноценный ПК взяли на CPU AMD 5x86. Обошелся он, вроде в 1996г, примерно в $1000, отцу за доллары и продали в магазине (но формально принимали только рубли)).
Если я правильно помню, Поиск был аналогом даже не PC XT, а самого первого IBM PC, его процессор был аналогом 8088
Вы правы, в "Поиск 1", оказывается, стоял КМ1810ВМ88 с восьмибитной шиной данных.
Но с т.з. программной совместимости разницы особо не было.
Ну так и в PC XT был такой же 8088, как и в первом PC. Они вообще отличались сугубо конфигурацией: у PC XT было 8 слотов расширения, у PC всего пять. У PC XT был жёсткий диск, у PC не было. Соответственно, у PC XT блок питания был намного мощнее, чтобы винт тянуть. Ну и памяти у PC XT было 128К в базе, у РС всего 64К. Проц у обоих работал в максимальном режиме.
Поиск в этом плане с ними сложно сравнивать. В базе у него 128К или 512К ОЗУ, жесткий диск опция, блоков питания четыре на выбор от 15-ваттного до 100-ваттного, видео дрянь, процессор - в минимальном режиме, как у PCjr (с ней там вообще много общего). В общем, это совсем не аналог, скорее, нечто по мотивам.
Не совсем так. Я покупал первый PC 17 августа 1998, за 500 баксов, из них половина рублями по курсу 6 рублей, просто приехал на Царицынский рынок прям к открытию и успел затариться. Выходя с коробками, видел мужика который несся по рядам и орал, чтоб никто ничего не продавал. То был P-200MMX, HDD 1,2 Gb, 16 RAM, S3Trio 64v+. Вполне рабочая машина. Оклад у меня был тогда 600 рублей - 100 баксов. В 2000 оклад у меня был 3000 - 80 баксов :)
Купить готовый - да. А собрать по частям - без проблем. Если не гнаться за последними пентиумами - максимум полгода (проверено личным опытом). Самая дорогая часть - монитор, могла быть заменена на какое-то время простой схемкой-переходником и телевизором (опять же опыт из 90-х).
а зачем покупать PC? я учился сначала на собранном кооператорами "Спектруме", потом в ПТУ на классных "Ямахах", 286-х, а в 94-м году уже и 486 закупили. В школе до этого тоже стоял класс PS/2, поставленных по какой-то общероссийской программе.
Не путает.
Как сейчас помню, в 97-ом прочёл "Delphi 2 для чайников" + видеокурсы на Казакова купил (Юноны тогда не было) записанные и Lotus Notes 4 и переписывал приложение (если так можно выразиться) с Borland Paradox на Delphi 2 + InterBase.
А осенью 99-го устроился писать систему учета приема и доставили корреспонденции для одной курьерской службы, которая жива до сих пор, на Delphi + InterBase. Спасибо товарищу Архангельскому за его книги.
Потом для одного поставщика сантехники из Франции писали систему (там уже команда небольшая была) так же на Delphi + InterBase. Это уже нулевых было.
Хорошее время было.
Да, я помню, как в 97-м скидывались комнатой в общаге на один "общий" ПК, на котором 1 потихоньку развивался как программист, а остальные записывались в очередь поиграть в Age of Empires $))
А программку простенькую человек написал, производившую математический подсчет курсовой работы по каким-то инженерным вычислениям, не помню уже, и удачно продавал распечатку индивидуальных расчетов за какие-то вполне доступные деньги.
Молодец! Правда в итоге айтишником так и не стал, другой профиль ВУЗа у нас был, пошел по предназначению.
Тогда и пользователей - потенциальных покупателей - было сильно меньше. В моей институтской группе в 2000-м компьютеры дома были примерно у половины. Это в техническом вузе.
Так и не смог найти в статье ответа на вопрос, который содержится в ее заголовке
Смотрите глубже: я не смог найти даже обоснования корректности вопроса. На какую статистику опирается автор утверждая что после 40 какие то специалисты пропадают?
Да, все предприятия возьмут и выкинут дружно всё что писалось до этого 20-30 лет на Java|C# чтобы переписать на очередной модный фреймворк(нет)
Работаю уже лет 20(с первого курса) и подхожу к заветной точке 40+, так вот первым моим языком был С++, первым большим фреймворком был Qt, не поверите, но все что изучал еще в школе до сих пор вполне актуально. А самое главное без этого не строится ни один большой проект, автор работает в очень специфичной сфере, судя по примерам, веб-сайты, интернет магазины, мобильные приложения на Flutter, это очень маленькие проекты, это даже не программы в полном смысле, аналоги сайтов визиток популярных в начале 2000. Напишите пожалуйста хотя бы мессенджер без с++ или натива. Только нет вот это я тут взял фреймворк где за меня разрабочики фреймворка прикрутили webrtc сделали обертки в js и меня вот звонок уже идет. Нет, сделайте хотя бы звуковой кодек без си/с++. Про всякую пену типа флеш, электрона, теперь флуттер, слышу уже много лет, сколько работаю столько и слышу. Ну и как программировал UI на Qt, так и программирую. Конечно все эти модные штуки возьмут себе какое-то место под солнцем, хотя флеш вроде сдулся совсем, но с++ никуда не денется очень, очень много времени. А самое приятное что можно вообще не тратить время на новое разрабатывая на с++, ну к примеру появился std::thread, но что системные потоки перестали работать? появилось время можно посмотреть новый стандарт, не появилось пиши как раньше, работать не перестанет. И по перфу готов на с++/qt соревноваться с любой модной штукой. И самое что интересное, уверен в том что на с++ и qt будет реализована любая сколь угодно сложная задача в полном объеме и не упрусь в технологию, в крайнем случае пойду дергать нативное апи системы, будь то андроид, winapi или ios.
"теперь у нас в компании нет разработчиков мобильных приложений на нативных языках" это означает что вы можете решать класс задач только тот который дает флуттер и не больше, обсер произойдет сразу как понадобиться работать с камерой и выжимать перф для нейросетей.
Коллега, я вот пишу на С++ уже более 30 лет и с ним случилась нехорошая метаморфоза: из достаточно простого и понятного С-с-классами получился чудовищно сложный, перетяжеленный язык, попытки исправить который делают только хуже (по причине возрастания сложности языка). Понятно что причина в legacy, код 30-летней давности должен собираться и работать.
Не знаю что с этим делать, замены C++/Qt действительно не вижу на сегодня, может быть плохо смотрел. Но она точно вот уже нужна.
Мы используем из нового просто и понятное: optional, atomic, thread, filesystem, лямды, с новым стандартом появились хорошие библиотеки, например magic_enum. Вроде Rust развивается активно. С++ хорош тем что вокруг него есть миллиард библиотек и он работает почти везде.
Из C++ (текущего) вполне можно вырезать "простое и понятное", ну в некоторых пределах. Правда в разных случаях (командах, компаниях) эта вырезка будет сильно разной, то есть когда к вам приходит новый сотрудник - он будет долгое время переключаться на ваше, отчего будут всякие (решаемые) проблемы.
Проблема C++ в том, что сам язык слишком сложный, во всей его полноте его мало кто знает: для этого нужно прочитать и понять текущий (используемый) стандарт и все предыдущие и понимать чем вызвано конкретное изменение. Это делают не только лишь все, как следствие - знание языка у (большинства/всех) членов команды - фрагментарное и фрагменты эти не совпадают.
Причем, эта проблема ("слишком сложный язык") уже и 20 лет назад была, а с тех пор многократно усугубилась.
Своей команде позволяю писать как хотят, мне все равно, могу читать почти любой код в любом стиле, друг друга пока понимаем, код ревью вести не сложно. Но люди особо и не пишут ничего сложного, никто не рвется писать трехэтажные шаблоны. Сам стараюсь писать максимально просто, остальным то же рекомендую. Когда долго программируешь все равно приходится лезть в чужие библиотеки и так или иначе в них разбираться, со временем становится все равно на код стайл и гайдлайны. Скажу крамольную вещь, у нас сейчас команда 10+ программистов и даже кодстиля нет ), когда приходят новички по началу спрашивают про код стиль, говорю пишите примерно как в коде написано, ну и как-то нормально. На мой взгляд самый лучший способ разработки это не мешать бюрократией и проектировать постфактум, перед реализаций быстро прикинул что как, обсудил минут за 10, потом когда уже функциональность написана и ее много, вот тогда делать проектирование и рефакторить. То есть условно процесс разработки можно построить на два этапа, первый это говнякать прототип, который может и в релиз уйти, а потом уже систематизировать написанный код, уже зная как он работает и какую задачу решает, систематизировать. Причем эти два процесса должны идти все время, так лично по моему опыту получается лучше и быстрее разрабатывать даже достаточно крупные штуки. Беда начинается когда менеджеры вмешиваются и не дают проводить систематизацию: "ну оно же не привезет новых функций зачем работу делать". Более того слишком большое проектирование вначале как правило заканчивается овериндженерингом, а самое неприятное что в процессе реализации как правило приходит понимание что не учли, но так ТЛД уже написано начинают костылить и получается по качеству примерно то же самое что просто наговнякать, все равно набор подпорок и костылей. Так давайте говнякать сразу а потом уже сделаем начисто.
Это все звучит очень спорно и вразрез с общепринятыми подходами, возможно оно работает только у меня и еще у пары коллег, а у других такой подход работать не будет.
Я не про говнякать и не про "проектировать постфактум". Наговнякать несложно.
Я именно про язык C++: он слишком сложный и его никто не знает на самом то деле. В этом проблема.
А наговнякать я могу и на фортране-4.
Ну на Фортране это еще не показатель. А вот на Forth да с обратной польской нотацией :-). Впрочем я конечно стебусь.
Любой язык это прежде всего инструмент, и точно также как и с реальным инструментом плохо забивать гвоздь отверткой (но можно!) или завинчивать шуруп топором(а вот это не пробовал, но думаю что получиться)
> Я именно про язык C++: он слишком сложный и его никто не знает на самом то деле. В этом проблема.
начиная с C++11 вероятно можно было бы назвать "D", Stroustrup касается этого слегка, личной точки зрения не имею (дело не в названии), но такое мнение существует,
см.
я поддержу, сначала тоже пишу прототип, понимая, что все равно его переделывать. Для начала должно заработать, и нужно определиться, какие фичи нужны, а какие отпадут. Нет смысла проектировать, например, ГУИ на бумаге, проще сразу в коде.
Или прототип на python, а к 2-3 переписыванию - на C+Qt (но это будет лень)
кодстайл у вас просто описан в виде примеров. Повезло, что все пишут примерно одинаково.
Единственное - я не программист... По крайней мере, ищу скорее работу инженера-разработчика, инженера-исследователя, и чтобы не просто программирование, а с физикой, математикой, hardware, ... .
Тоже 40+, начинал в том числе с ассемблера 8080.
Если Вы пишите многопоточный код, то пользуйтесь POSIX thread-ами и mutex-ами (напишите к ним простую обертку) вместо atomic, thread и прочих модных нововведений языкаю, и Вы никогда не выстрелите себе в ногу. А еще лучше не использовать нитей вообще. Запускайте процессы обработчики задач и организуйте диспетчерезацию заданий между ними. Этот старый дедовский метод прекрасно работает по сей день. Более того, он делает программу простой и понятной.
Можете сказать, не глядя в стандарт, нужно ли инициализировать переменную
xв коде ниже, или это UB?
Если Вы работаете на симметричной многопроцессорной системе со строгой (strong) моделью памяти, то Вам ничего делать не нужно. Если же у Вас модель памяти слабая (weak), то потребуется барьер типа StoreLoad. Как это делается в "модных плюсах" я не знаю и знать не хочу. Могу сказать как это сделать на асcемблере для ARM.
Простой и понятной программу делает STM, а не ковыряние мьютексов или методов синхронизации между процессами.
Какие мьютексы и синхронизация в однопоточной программе ? Всё, что Вам потребуется это системный вызов select(), а так же read() и wrote() для раздачи заданий. Оставьте системе её работу, займитесь делом.
Я хочу перемножить две матрицы.
Перемножайте на GPU, eсли у вас что-то серьезное. В остальных случаях решения отличаются плюс-минус чисто эстетически.
Перемножайте на GPU, eсли у вас что-то серьезное. В остальных случаях решения отличаются плюс-минус чисто эстетически.
Вот когда вам очередная версия gcc/clang вырежет этот код в режиме -O3, т.к. он содержит UB, вы осознаете, что оно не совсем эстетически различается. :-(
Несколько месяцев назад я портировал программу с Borland C++ (очень толерантный к ошибкам компилятор) на относительно современный Шланг, так там вот таких UB было штук пять. Хорошо ещё, что было сразу понятно, что программа работает неправильно.
Тут нет никакой синхронизации вообще, вопрос не про неё, а про инициализацию. Честный однопоток.
Корректный ли это код с точки зрения 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 году и используется по сей день в высоконагруженных вычислительных системах.
Я всё ещё не могу понять, где и по какому принципу вы вставляете синхронизацию. Где вы здесь нашли в ней необходимость?
Судя во всему, Вы программируете для систем со строгой моделью памяти (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-ы. :-)
"исходят из того, что любая программа потенциально может иметь много нитей и быть запущена на многопроцессорной системе" — это не так. В C++11 вам предоставляется возможность писать многопоточный код, опираясь на стандартную библиотеку и на модель памяти. Совершенно необязательно этой возможностью пользоваться. Программы C++98 корректны и с точки зрения C++11.
Писать корректный многопоточный код существенно сложнее и дороже. Ни одна компания не стала бы переходить на новые версии стандарта, если бы при этом надо было перерабатывать весь код с учетом "потенциальной" многопоточности.
Слушайте, ну MPI придумали от тоски, в смысле от того, что задача перестала влезать на одну ноду.
После чего сразу стали его ломать разными способами, только бы ускорить (RDMA очевидно же абсолютно не в парадигме MPI)
Пускать параллельные "тесно связанные" задачи внутри одной многопроцессорной системы на процессах и использовать средства ОС для синхронизации имеет смысл только если этой синхронизации у вас совсем немного и в реальности она на производительность практически не влияет и объемы передаваемых между процессами данных невелики.
Ну, или если производительность не интересует.
Можете сказать, не глядя в стандарт, нужно ли инициализировать переменную
xв коде ниже, или это UB?
Если это локальная переменная - не нужно.
Если это глобальная переменная в многопоточной программе, то нужна синхронизация доступа к ней.
>>С++ хорош тем что вокруг него есть миллиард библиотек и он работает почти везде.
Однако, по моим наблюдениям, самые распространённые библы переписывают на C, т.е. вся хорошесть внезапно в поддержке С, самого по себе, довольно примитивного языка.
Аналогично. Не знаю кто распускает все эти нелепые слухи про бежать быстро и долго. Успокойтесь никуда бежать не надо. Весь современный мэйнстрим в программировании родом из 80-ых, 90-ых. И в целом мало, что то меняется. Программист это не языки программирования и модные фреймворки, а структуры данных, алгоритмы и паттэрны проектирования. Если вы прекрасно знаете как оно под капотом работает, а работает оно поверте уже много лет примерно также, то разобраться в новомодной фигне не составит проблемы.
Наверное, я в своей жизни провел уже несколько тысяч технических собеседований программистам. Я видел много людей, которые не смогли «добежать», из-за чего очень сильно отстали от отрасли. Здесь я с вами согласиться не могу.
А вот с тем, что многое из современных тенденций родом из 80-90 годов, я полностью согласен. Что-то является воплощением идей того времени, что-то просто повтором старого и хорошо забытого, но на новом уровне.
Но вот есть одна беда. Людей, которые реально понимают, как оно работает под капотом и почему оно работает именно так, очень немного. Да, эти люди будут востребованы «всегда». Только их процент от общего числа «программистов» сейчас очень небольшой. Собственно об этом я и написал.
Людей, которые реально понимают, как оно работает под капотом и почему оно работает именно так, очень немного.
Слава богу, сформулировали. Так может быть, в этом всё и дело? Именно в этом, а не в судорожном "изучении" всё новых языков и всё новых технологий, которые не вами придуманы? Постоянно бежать - это хорошо, но понимать, куда бежать в перспективе - ещё лучше. Вы приводили пример с наукой. Отличное сравнение. Вы не сможете работать в науке, если не понимаете, как оно там "под капотом" работает. В IT, так уж получилось (с лично моей берёзы глядя), набилось слишком много людей, которые довольно расплывчато разбираются в тех самых структурах данных, алгоритмах и паттернах проектирования. Я ужЕ не говорю об элементарных представлениях о том, как именно под этим самым капотом работает несчастный компьютер, в машинные коды которого транслируется всё то, что мужественные разработчики наваяли (скопипастив из интернета). Да простят меня те, кто понимает. Не это ли непонимание и служит причиной выгорания? Каково психологическое состояние человека, который вынужден день за днём выполнять работу, истинный смысл и внутренняя структура которой ему не понятны? Рано или поздно подсознание взбунтуется от такого насилия над природой.
Если человек совсем ничего не понимает, то его век в IT будет недолгим. Беда наступает, когда человек зависает между поверхностными знаниями и глубоким пониманием. То есть он вроде и может, но через постоянное усилие над собой. Вот это усилие и выжигает людей, медленно, лет за 15-20.
В науке все где-то так же, но там немного денег, такого притока желающих нет. Поэтому остаются в основном те, кто может и любит свою работу. Плюс процесс защиты кандидатской и докторской очень долгие. Вот где-то к 40 годам человек будет считаться состоявшимся специалистом. Лишних людей почти не остается.
Суть учёного в способности самостоятельно ставить и решать задачи. Диссертация и процедура её защиты, как квалификационной работы, основана на доказательстве именно этой способности. Причём для докторской - уже даже без научрука.
Если человек для кого-то что-то считает без понимания, он бухгалтер, но никак не учёный.
Вам ещё сейчас скажут что ассемблер не нужен и устарел...
На своей шкуре могу подтвердить, что если понимаешь что под капотом, то на каком языке написано глубоко фиолетово. Правда я занимаюсь только совсем низкоуровневым ПО, там где оно интенсивно взаимодействует с внешним миром
Я видел много людей, которые не смогли «добежать»
Т.е. освоить флаттер и иже с ним?
У вас какое то узкое понятие отрасли. Многие сидят, годами делают один и тот же ентерпрайз на яве и хорошо зарабатывают. Они тоже "не добежали" и "жизнь не удалась"?
Про возраст можно было не писать, понятно по тексту =)
К слову говоря, мы не считаем месенджеры какой-то сложной задачей. Если бы мне предложили реализовывать его на базе С++, я бы такое запретил. Скорость разработки медленная, поддерживается плохо, преимуществ перед web-сокетами нет никаких. Ей богу, у нас месенджер в одного реализует фронтендер, просто взяв Flutter для клиентского приложения и Node.js для сервера.
Кроме того, стоит заметить, что у Flutter нет никаких проблем в работе с камерой, а что такое выжимать производительность для нейросетей я себе очень плохо представляю. Может быть, просто нейросеть нормальную взять? И обучаете вы её, наверное, не на телефоне?
Нет, у меня были коллеги, которые извращались с С++ на мобильных устройствах, но это были задачи из разряда запуска навигационной программы на китайском убогом планшете, из-за этого приходилось вписываться в те ресурсы, что есть.
Кстати, первой из задач, что мы реализовали с использованием Flutter, это географически распределенная система на нестабильных каналах связи для пассажиров речных круизов. Мобильное приложение позволяло людям просматривать экскурсии, использовать аудиогид, смотреть контент из бортовой мадиа-библиотеки, делать заказы услуг, доступных на борту. Конечно, приложению приходилось работать с бортовым сервером, который при наличии связи соединялся с центральным сервером. В нашей стране мобильный интернет много где недоступен. Для нас это несложный проект.
Когда дело дойдет до реальных проектов, скорее всего, вы серьезно проиграете по производительности. По производительности (скорости) разработки, по скорости внесения изменений и раскатки обновлений. И скорости работы приложения, не потому что С++ медленный язык либо ему не хватает каких-то средств, просто есть еще архитектурный уровень, который тоже очень не простой.
P.S.
Я бы никогда не стал отождествлять потоки и процессы, это как путать работу над общим и раздельным полем памяти.
" Если бы мне предложили реализовывать его на базе С++, я бы такое запретил. "
Это очень хорошо. Фактически чем больше будет людей разделяющих ваши взгляды тем выше будет моя зп.
Только вот Telegram почему-то на C++ и прекрасно работает, в отличие от вечно лагающих Viber и Watsapp. Я тоже принимал участие в разработке чата, первая версия которого была написана на Cordova. Этот ужас мне снится по ночам) Люди год потратили впустую на эту "кроссплатформенную" технологию. Переписали нативно и все заработало по-человечески.
Только вот Telegram почему-то на C++ и прекрасно работает, в отличие от вечно лагающих Viber и Watsapp.
Ну вообще web-версия телеграмма, десктопная на windows и MacOS и мобильная у меня работают с одинаковой скоростью. Единственная разница между ними - у мобильной переодически отваливается загрузка изображений.
Так вот почему все мессенджеры гасятся в энергосберегающем режиме! Один вотсап продолжает присылать уведомления о входящих.
Думаю все эти модные штуки для отрасли в целом благо: разработка очень дорогая, всерьез ее себе могут позволить только крупные игроки.
Простые, доступные инструменты высокого уровня позволяют стартануть огромному количеству мелких игроков. Конечно время жизни бизнеса на таких технологиях будет коротким, но большего и не требуется - многие из таких игроков не переживут и года, к тому же каждый год приходят новые, это как бурлящий котел. Но их суммарная капитализация в разы, если не на порядок, превышает капитализацию крупных игроков. Это огромные вливания средств в отрасль в целом, и это для отрасли благо.
Для общества тоже большая польза: удешевление разработки привело к взрывному росту проникновения высоких технологий в общество.
Это банально удобно: доступные смартфоны, множество бесплатных или дешевых (читай доступных) приложений и сервисов, которые каждый из нас использует каждый день, которые в чем-то облегчают жизнь, конкуренция в конце концов. Множество мелких доступных бытовых девайсов - современные дома просто напичканы электроникой, прошивками, софтом, сервисами. Появилось множество сайтов, практически каждая мелкая кафешка имеет как минимум свой сайт с меню, а то и целый интернет-магазин с корзиной и доставкой, и пусть все это очень криво сделано, постоянно что-то глючит, какие-то проблемы, но суть в том что оно существует как явление, доступно даже очень мелкому бизнесу, и бизнес, пусть с проблемами, вполне себе живет.
А также это полезно: в том же смартфоне тебе и развлечения, и обучение, и организация своей жизни, и управление финансами, а иногда и работа. Не говоря уже про то, что связь по миру в принципе стала доступной штукой, можно очень дешево общаться с противоположным концом планеты, да еще и по видеосвязи - еще недавно это казалось фантастикой. Люди сегодня, пользуясь такими технологиями, обсуждают всякие бытовые, абсолютно бесполезные, темы, и это замечательно: все это настолько доступно, что даже на всякий мусор не жалко тратить ресурсы/трафик/время.
И все это обеспечено именно дешевой разработкой - она сделала информационные технологии доступными.
Даже закостенелые госаппараты оценили преимущества информационных технологий, в мире появляются цифровые госсервисы, системы связи/наблюдения/координации. Государства от обмена бумагой переходят к обмену данными по сети, цифровые архивы растут, все бумажное постепенно оцифровывается, упрощается взаимодействие. А те, кто не переходят на цифру, страдают, закапываясь в стопках бумаги, которые на каждый чих нужно перебирать вручную.
Ну и как следствие, большой приток мелкого бизнеса способствует росту крупного бизнеса: часть мелкого бизнеса со временем неизбежно отрастет до крупного. И вот тут и начинается самое интересное: дешевый процесс разработки для крупного бизнеса не подходит, дешевые высокоуровневые инструменты очень ограничены, и ограничивают развитие бизнеса, а выходить за пределы ограничений очень дорого, дешевых квалифицированных специалистов нет, а неквалифицированные не способны качественно решать сложные задачи, так что все это нарастает как ком, порождая все больше проблем, и бизнес вынужден переходить на нормальные инструменты, и привлекать соответствующих специалистов. Когда от софта зависит крупный бизнес, экономия обходится дорого.
Как итог приток мелкого бизнеса со временем увеличивает спрос на квалифицированных дорогих опытных специалистов - работы становится больше, и это хорошо. У каждого бизнеса свои потребности, свои требования, и множество сложнейших задач, которые кому-то надо решать.
Простые, доступные инструменты высокого уровня позволяют стартануть огромному количеству мелких игроков
У меня на телефоне приложение от самого мелкого бизнеса это Navitel. Остальное написано гигантами типа Google, Microsoft и т.п. Доступность инструментов создаёт условия для пополнения рынка до какой-то степени обученными и замотивированными кадрами. Но выводить самим что-то на рынок становится только сложнее.
Порог входа с каждым годом лишь увеличивается. Если 10 лет тому назад основной проблемой для стартапа a'la аналог Фейсбука, было найти дешёвый хостинг и выстроить продвижение, то сейчас к этому добавилось бесчисленное множество требований со стороны различных локальных регуляторов - иначе рынки закрыты. Элементарная задача хранения фоток, если на них могут быть какие-то люди, теперь уже целый архитектурно-юридический танец с бубнами на много денег.
Конкретно на смартфонах множество приложений буквально от одиночек, зачастую существующих только на рекламу, или вообще just for fun. От крупных игроков там не так много приложений. Но там есть целые фермы приложений - фирмы, которые клепают все подряд, в надежде что что-то выстрелит. Лучшая поддержка и обратная связь именно у одиночек/небольших команд: у них самая высокая мотивация на результат, многие предложения пользователей уходят в код, аудитория довольна. Сам пользуюсь несколькими такими мелкими приложениями, которые отлично выполняют свою задачу и не содержат скама и рекламы, и это именно продукт конкуренции, он отшлифован, он ценен лично мне, т.к. решает мои задачи, но с финансовой точки зрения такие приложения имеют мало смысла, сложно представить что такое выпустит какой-то крупный игрок.
В этом плане у мелкого бизнеса есть преимущество: он более эффективен. Не смотря на почти полное отсутствие финансирования, люди выдают очень неплохой результат. В то время как крупный бизнес, не смотря на огромное финансирование, разбивается о скалы бюрократии, из-за чего довольно простые задачи излишне переусложняются, и стоят многократно дороже. Это буквально так: в то время когда в мелкой команде какую-нибудь опечатку поправить минутное дело, в крупном бизнесе это целый квест с десятком промежуточных узлов, ответственных, специалистов разных уровней, где никто особо не заинтересован в результате, но их всех нужно оплатить. Т.е. мелкий бизнес более ориентирован на результат, быстрее цикл разработки, проще процессы, оперативнее связь внутри. Именно этот дисбаланс в пользу мелких дает им возможность конкуренции. Уже были случаи, когда такие одиночки клали на лопатки продукты с огромной капитализацией, и крупные фирмы противопоставить этому ничего не смогли - не смотря на всю рекламу, в конце концов люди выбирают что удобнее.
На рынок выйти безусловно сложно, как минимум из-за рекламных бюджетов: крупные фирмы просто грузовиками завозят средства на рекламу, скупают многих конкурентов, могут себе позволить. У мелких компаний в этом плане шансов почти нет. Тем не менее ситуация не безнадежная, отдельные приложения успешно пробиваются, отхватывая свою долю рынка, не смотря на все давление, т.е. конкуренция вполне себе работает, но отбор сегодня конечно куда более строгий, чем был когда все это только зарождалось.
Про порог входа - да, в каких-то сферах он растет, но в целом остается довольно невысоким. Собрать какое-то примитивное приложение можно без знаний и опыта - инструменты достаточно автоматизированы, чтобы это простить. Что-то с нормальный функционалом безусловно потребует знаний. В моем окружении мини-приложения даже админы клепают, для производственных нужд, для управления/мониторинга чего-нибудь мелкого, почти в личных целях, в свободное время. Тоже для себя пару простых делал - не так сложно, в смысле даже не пришлось погружаться в тонкости ОС, хватает и базовых знаний, а интерфейс вообще из готовых блоков собирается в визуальном редакторе. В этом плане гугл проделал большую работу, создав такие сложные инструменты, чтобы привлечь разработчиков для заполнения экосистемы.
Про бизнес - тут ничего не поделать, это рынок, кто первый того и тапки. Фейсбуки и гуглы стартовали на почти пустом рынке, сейчас там стартануть конечно намного сложнее, ниши уже заполнены и поделены. Но все еще возможно - если продукт предлагает что-то уникальное и более доступен/удобен, чем конкуренты, или нашел относительно свободную нишу, или конкуренты уже отмирать начали, у него хорошие перспективы. Расклад на рынке в конечном итоге определяют именно потребители. Опять же бюджеты сейчас часто закрываются инвестициями, многие этим пользуются, пусть это и палка о двух концах, т.е. и с ресурсами проблемы можно решить, если продукт действительно ценный и нужный.
> Работаю уже лет 20(с первого курса) и подхожу к заветной точке 40+, так вот первым моим языком был С++, первым большим фреймворком был Qt, не поверите, но все что изучал еще в школе до сих пор вполне актуально.
Добрый день, а не подскажете, что пишете? Действительно интересно, просто в последнее время ни с чем нативным не сталкивался. Даже рад, что JS ещё не целиком захватил мир.
аутомотив вон бегает на С++ с Qt . (видел еще такую же связку в аудиосистемах, у которых больше 20 динамиков, и в распределительных системах электросетей дженерал электрикс)
игрушки для множества платформ на С++ пишутся (однажды довелось даже самому участвовать в проекте, когда код на С засовывали в эмскриптен и потом запускали в браузере !)
Спасибо
> игрушки для множества платформ на С++ пишутся (однажды довелось даже
самому участвовать в проекте, когда код на С засовывали в эмскриптен и
потом запускали в браузере !)
Слушал, что менюшки теперь тоже принято рисовать в электроне, а саму игровую графику в каком вулкане. Пожалуй, хорошо, что не все таким заняты.
Что пишу, в основном геймдев: движки, внутренние редакторы и различные утилиты. Геймплей, понятно, что это будет или скриптовый язык или квестовый граф, в общем то что можно быстро и легко переделывать, а вот различная работа с ресурсами, рендер, сеть и прочее это будет или натив или с++. Вот что-то такое и пишу, делаю все что бы гемплей командам жилось хорошо и беззаботно. В геймдеве работы много и она разная, можно менять специализацию при желании. Лично по-моему опыту уровень задач и их качество зависит от рук, а не от технологии, Языки, фреймворки все плюс минус одинаковое. Мне нравится связка 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 только на нем, продолжаю программировать на с++, сейчас вот флуттер, все с++ хана все только на нем, ну... как бы мое отношение понятно ) Нет какую-то нишу себе флуттер займет, как заняли и все убийцы с++ до этого, но с++ никуда не денется еще очень очень очень долго.
С компиляцией последнее время почти нет проблем, прекомпиленые хидеры это понятно, сейчас добавилась инкрементальная линковка. Плюс компилируется то что менялось, плюс появились очень многопоточные процессоры. Ну и мне даже иногда нравится задержка перед запуском программы, те 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.
Программисты после 40 всё так же продолжают работать. Просто надо учитывать, что двадцать лет назад их было намного меньше, а сами технологии были другими. Поэтому и работают они преимущественно не в молодых стартапах с дружным коллективом, а в куда более классических компаниях.
+1. Вполне себе работаю мне уже скоро 50. И честно говоря не вижу чего-такого радикально нового появилось в SQL за эти 30 лет. Мне гораздо сложнее в предметную область въезжать.
Хранение сначала XML, потом JSON(б). Специальные типы данных и индексы для ГИС данных.
Самое главное, появился пласт No SQL решений и гибридных решений. А ещё появились DWH и задачи ETL с десятками разнообразных инструментов.
От этого качество данных не изменилось в лучшую сторону. И вместо 50 строк SQL приходится писать 100500 :(
Оченно модные новые решения никак не помогают в переписывании всего древнего, что накопилось за 20 лет.
Можно пользоваться всем этим умело, а можно - как всегда.
" XML, потом JSON " - угу, и потом 2 недели разбираться почему работает не стабильно. Как оказалось виноват свежий драйвер шины данных - он обрезал запрос до 512б.
Неужели DWH не является обыкновенной базой данных ? Неужели 3 простых правила что-то кардинально поменяли ?
" ...и задачи ETL с десятками разнообразных инструментов. " - достаточно плотно знаком с ODI, DataStage и NiFi - да, шЫкарные инструменты в "ровных" руках. Но если их дать пламенному нубу - бяда.
Вывод: неважно какой автомобиль, важно какой ВОДИТЕЛЬ
Мне пока ещё не сорок, хотя уже не так и далеко. Но вот мама у меня всё ещё работает и на седьмом десятке, хотя начинала ещё с перфокарт.
ого! а на чем пишет код ?
У них там тоже с базами работа, в основном. Раньше FoxPro был, последние годы ещё Firebird добавился.
Работаю в фирме, производящей серверы. Один клиент купил новейшую систему на Xeon Scalable 3rd и потом предъявил, что новый сервер сильно тормознутее старого, на 2 поколения назад. Выяснилось, что база у них как раз Firebird, которая, похоже, однопоточная, и вдобавок пишет файлы очень мелкими блоками. Разбирались долго - похоже, что-то с транзакциями на шине PCI-E, производительность так и не вытянули, при том что на современных SQL-базах последнее поколение дает существенную прибавку скорости
а на чем пишет код ?
На перфокартах!
Отличная статья, согласуется с моим опытом как руководителя программистов. Особенно, что хорошие программисты из радиотехников получаются. И про возраст правильно написано, если человек хороший специалист в молодости, то и после 60-ти отлично работает и новое осваивает.
Помнится лет десять назад в аналогичных статьях вместо 40 было 30...
Владимир Орлов — это тот человек, который учился у первых программистов, а сейчас он пишет статьи о своём более чем пятидесятилетием опыте в отрасли
Спасибо, что вспомнили о моей скромной персоне.
Не только пишет статьи, а продолжает программировать и много программировать:
удостоверяющий центр, утилита для работы с электронной подписью, наконец SVG-редактор и т.д.
Да, и кроме упоминаемых автором трех частей, вышла и четвёртая часть:
Пятьдесят лет на стезе программирования. Часть IV. 4 ЦНИИ МО. Звёздные войны. 1983-1987 г.г
35 лет назад я получил первую зарплату за программирование. И продолжаю, не собираюсь прекращать....
о, я как раз в 45 пытаюсь зайти в ойти (аналитику). Видимо надо стремится к пожилому дружному коллективу :)
Вы знаете, за 20 лет, люди все также считают медиану и среднюю, факторный и кластерный анализ. в ML конечно добавились методы, но это применяется достаточно редко
Теперь SPSS это фу, а вот питон с пандасом это круто (хотя на 90% делают ровно одно и то же)
Странно слышать от человека, который пишет про SPSS (ничуть не фу) и (кажется) понимает, что такое ML с точки зрения математики, о том, что он только-только собирается зайти в ойти.
Скорее всего, у вас уже есть фундаментальные знания и системное мышление. Остается только немного актуализировать знания по технологиям дата-сатанизма и найти нормальную команду (не стартап). В стартапе может не получиться с горящими глазами делать какие-нибудь глупости, а в серьезной компании будут интересные задачи.
не, к сожалению немного не так. Я пытаюсь зайти в аналитику данных. Почти прошел Excel, скоро надо будет проходить базу по Питон и SQL (может потом на платные курсы аналитика). А про ML общее представление. Штука интересная, но требует (если не обезьяничать, подключая "эскалёрн"), хорошее знание математики
Их даже учат правильно составлять резюме и проходить собеседования.
У вас в слове "только" несколько опечаток.
На мой взгляд у автора профессиональный перекос, судит о пограмистах исключительно из своего окружения.
В реальности полно людей в возрасте продолжающих писать на прологе, фортране, дельфи, пиэльсекюле и прочем таком же старье.
Работа есть, деньги платят, всякое стильное/модное/молодежное оставленно хипстерам от программирования. Бежать нужно чтобы оставаться на острие процесса, так наверное справедливо, просто для сохранения статус кво это, зачастую, необязательно. Ну и хватает областей где к прогрессу отношение негативное а легаси обширное.
В реальности у меня очень широкий круг общения, который захватывает большой спектр технологий.
Можно сказать, что на Fortran сейчас пишут всё меньше и меньше, даже в научной среде, которая занимается численным моделированием. Даже оттуда его вытесняет С++.
Для меня очень сомнительно, что на Prolog сейчас идет много разработок. Дело в том, что это отдельная парадигма программирования, которая имеет очень узкую нишу применения. Возможно, его еще где-то используют, но это должны быть специфичные задачи.
Если коснуться PL SQL, то могу сказать что его сейчас его все так же активно используют. Иногда слишком активно, за что приходится очень больно бить по рукам. Размещать слишком много бизнес-логики в базе данных - плохая идея и известными последствиями. Тем не менее, язык все еще востребован, причем, как для диалекта Oracle, так и для диалекта PostgreSQL.
А вот с Delfi все несколько сложнее. Нам приходилось консультировать компанию, которая реализовала внутри себя аналог 1С на Delfi, после чего людям захотелось упаковать это, как продукт. При таких инициативах всегда проводится анализ доступности разработчиков на требуемых языках. Нет программисты на Delfi есть, но стоят они меньше джуна на Python. Реалии рынка где-то такие.
Нет программисты на Delfi есть, но стоят они меньше джуна на Python. Реалии рынка где-то такие.
Есть программисты на Delphi. Кто помнит как называется язык стоят уже нормальных денег.
Вот я сейчас посмотрел вилку зарплат (по вакансиям и резюме) по Новосибирску на HH.ru, для разработчика Delphi это 40-50 тысяч рублей. Вакансий мало, резюме - много.
Я смотрел на Glassdoor, там предлагают $50K - $130K, что вполне сопоставимо со обычными цифрами по рынку. Понятно, что это не мейнстрим, вакансий мало и учить с нуля смысла нет. Но если уже есть навыки, то работу ещё можно найти.
Хм, мне в январе в Томске 100тыс. предлагали. С перспективой роста зп.
Ну зависит от ситуации и опыта. Мне, к примеру, предлагали год назад порядка 400 тыс руб в Москве. Но там и разработка была достаточно высоконагруженной системы и опыт нужен был не только в Delphi.
Я не далее как в текущем году в очередной раз заработал денег халтурой на фортране. Причём за фортран или, скажем, лисп платят намного дороже, чем за мейнстримные языки, ввиду дефицита исполнителей. За программу на Прологе тоже в текущем году предлагали заплатить, но я не взялся, не люблю эту парадигму.
Самая удельно дорогая моя программа состояла из 58 строк на языке REXX (включая пустые строки и комментарии) и обошлась заказчику вместе с документацией в 700 000 рублей. Это, конечно, больше исторический анекдот, но в целом иллюстрирует тенденцию, что не всегда обязательно впахивать, как раб на галерах, при правильном позиционировании на рынке.
При этом, если мне изредка надо что-то запрограммировать чисто для себя, я последнее время обычно пишу на питоне. Не то, чтобы я люблю именно сам язык питон, но под него много современных фреймворков на разные случаи жизни, и на нём гораздо быстрее тяп-ляп что-нибудь наваять, чем на C++. Но как питон-разработчик себя не позиционирую, рынок задемпингован бедными студентами.
А так вообще руководить выгоднее и интереснее. На данном этапе жизни какое-нибудь толстое ТЗ для соисполнителя я в большинстве случаев напишу с бо́льшим удовольствием, чем программу.
Кстати, фортран сильно эволюционирует, поэтому нельзя сказать, что это такой уж путь для лентяев. Фортран IV (он же 66), который я учил в детстве, и Фортран 2008, который сейчас является стандартом де-факто (а есть уже и 2018) – это как K&R C и C++ 14, по существу разные языки с разной методологией кодирования.
Так разработка ПАК -- всегда комплексная задача, всё нужно. Особенно если приходится колхозить на стыке ранее не использовавшихся совместно технологий.
Наверное, вы все же разработчик. :о)
Из написанного вами у меня только один вопрос возник, почему Lua? Это ж еще тот «мопед», иначе и не скажешь. Самое ужасное то, что я сам его знаю и мы реализовали не нем высоконагруженный сервис. Сервисом мы гордимся (архитектура красивая, скорость работы высокая, надежность уникальная), а вот то, что он сделан на Lua никому не говорим.
А так, время идет, а проблемы остаются похожими друг на друга. Но для этого нужно достигнуть некоторого профессионализма в области, на это способны далеко не все.
Lua удобен чтобы делать маленькие примочки, например новую команду для робота. Просто как валенок, и удобно отлаживать
а чем Вам Lua не угодил?
Отличный мультипарадигменный язык, чертовски простой в освоении, легковесный(официальный) интерпретатор идеально подходит для встраивания и работает на всем, начиная от микроконтроллеров. Для интерпретируемого языка это чудо еще и работает весьма быстро.
Насколько я понимаю, на чистом Lua, от и до, большие системы проектируют довольно нечасто, зато как средство расширения нативных программ, написанных на том же C и C++ - применяется очень широко.
Ну, в какой-то момент мы начали писать на нем слишком сложную логику. А Lua неудобно отлаживать и как язык он, конечно, простой, но несколько обрезанный. Потом перенесли сложную логику на python.
А вот об активном применении Lua в робототехнике и для микроконтроллеров я даже как-то не знал. Там его «легковесность» вместе с интерпретируемостью действительно огромный плюс.
сделай публикацию на Хабре? И по делу интересно будет, и в карму можно будет добавлять >4.
(не личным сообщением, поскольку многие, кому хочу добавить в карму, ограничены числом 4 - всем вам актуально)
Все так. Основная мотивация это интерес и самореализация в разработке. Сейчас уже, по прошествии многих лет занимаюсь этим как хобби. 24/7 уже не интересно. интересно что то делать руками. осваивать другие специалтности (и там применять подходы используемые в разработке) . но и изучать и осваивать что то новое, реализовывать то, на что в потоке не было времени тоже никуда не ушло.
вот учить молодёжь - не интересно. сколько ни пробовал.. смотришь в пустые глаза и понимаешь, что всё зря. нет той искры, желания учиться этой "магии". и не хочется тратить свое время на эту бесполезную возню.
Возможно, это просто стариковский консерватизм прогрессирует, а может быть, и нет. Сложно судить.
Редко, что действительно увлекает — и тогда принуждать себя не надо, всё как в молодости.
Я недавно остался без работы (честнее будет сказать «отказался»), зато вновь ощутил то, чего давно не испытывал — удовольствие от процесса познания.
Верное замечание. А также практически все паттерны проектирования уже хорошо известны, нет ничего нового в самой реализации кода. Подумать в принципе над алгоритмом решения задачи интересно, а расписывать этот алгоритм отдельными операторами – уже настолько забодало своей однообразностью, что проще поручить молодому сотруднику. Это как зумиться на отдельные пиксели, представляя себе в целом картинку.
Если программировать по ТЗ однотипные задачи, то наверное все это в конце концов осточертеет. Если начать решать небанальные задачи бизнеса и выбирать соответсвующие технологии для их решения, то станет веселее. В 33 дорос до руководителя разработки коробочного продукта, в 35 ушел разработчиком на задачи обработки документов, где мы заменили кожанных мешков с приемлемым качеством и обработали за них миллионы документов, в 40 вкатился в ML и нейросети, несколько интересных проектов в области ИИ, в 45 вернулся в руководство командой, не зашло, возврашаюсь в разработку. По теме можно почитать статью Андрея Карпаты "Software 2.0".
Куда исчезают программисты после 40 лет?
Футурама, сезон 2, эпизод 10
Всегда смешно читать как ИТшечка уникальна тем, что надо учиться и технологии быстро меняются. Взять довольно гуманитарную дисциплину продаж. Люди из итешечки, наверное, думают, что продажи как велись 20 лет назад с помощью платного объявления с рамочкой за 100 рублей в газете "Из рук в руки" так и ведутся. Сейчас и 10 лет назад даже лишние волосы в труднодоступных местах удаляют иначе. И всем причастным пришлось этому учиться. Даже просто ездить на развозном фургончике в среднем российском городе сейчас и 10 лет назад это две разных технологии.
объем данных. который необходимо освоить, не сравнить.
Да, появился планшет с программой, но освоить популярные 3-5 юзер сторей на новом инструменте это одно, а другое - освоить новую либу, фреймворк, а то и язык со всей его экосистемой.
Изучить как в новом говнофреймворке создаётся круд формочка (90% вебдева) сильно сложнее чем перейти на новое поколение элементной базы в железячничестве, или понять каким именно образом нужно строить канал рекламы новой демографической группе с новыми предпочтениями в потребляемом контенте?
"Понять каким образом нужно строить канал рекламы" - для меня это норма работы, не связанная с обучением. Всегда что-то надо понимать - обычная работа, где схема по указанному вопросу проще схемы загрузки небольшого приложения во много раз.
А обучение - это про другое. Всё это математика, принципиально новые подходы, просто большой объём алгоритмической информации. И всё это завязано в языках, фреймворках, схемах, статьях, безотносительно текущей работы. Когда это понадобится? Может даже и никогда, а может ещё вчера.
Не знаю, у меня например нет статистики, только свой личный пример, и это не слишком представительная выборка но... я не раз брался за проекты, построенные на платформах, которые вижу в первый раз в жизни. Всё-таки четверть века опыта в смежных сферах позволяют легко разобраться практически во всём. Я всегда понимал, что надо делать, вопрос был только в том, "как сделать вот такую вещь на такой-то платформе", и ответ на него, как правило, всегда находился на первой же странице гугла. И тот же опыт позволял увидеть, правильный ли это ответ, или нет.
Это немного не так работает. Любая нетиповая задача, заставляет что то покопать и что то изучить. А если вы сеньор, то типовых задач и формошлепств в целом не будет. Сама по себе работа и есть учеба, а учиться и напрягать мозг в целом сложно. Все эти спанье в офисе, печеньки бонусы и прочее появились в айти сфере, чтобы народ мог больше работать не выгорая. При этом лет после 25, мозг после нагрузок начинает гораздо медленней востанавливаться. Благо что для опытного мозга, то что раньше было затратной проблемой на недели, часто теперь легкая проблема на пару часов.
26 лет работаю с микроконтроллерами и DSP. Как был классический С, так и остался. Даже плюсы не пролезли. Естественно ассемблер.
Недавно пришлось писать на котлине. Так большая часть времени ушла на то, чтобы разобраться с классами хранения данных и понять, как из всего этого счастья вылезти. После этого эксперимента я в андроид не ногой. Тем более после того, как столкнулся с попыткой внедрить код старой версии андроид в приложение, написанное на новой.
Зря вы так про Котлин. Это как раз пример удачной новой технологии. Язык удобный и легкий для освоения и в то же время эффективный и грамотно спроектированный. Для Андроида он гораздо лучше, чем Java 6, которая там была долгие годы до этого. С другой стороны, под Андроид вполне можно писать на плюсах, да и на Си тоже. Только не UI, а библиотеки и системные сервисы.
У меня несколько претензий к котлину.
Во-первых, огромное количество классов хранения данных, переход между которыми отнюдь не тривиален (в отличие от кутей, в которых и классов меньше, и переход вполне стандартный).
Жутко напрягло новшество в формировании цикла for. В сях можно делать что угодно по одной схеме. Можно целое число использовать, можно плавующую точку. Точка старта и точка останова задаются везде в одном виде. А в котлине наворотили месиво из вариантов.
Куда исчезают программисты после 40 лет?
Так в тимлиды, куда ж ещё. Или в продакты.
Интересные мысли. Я в начале карьеры так и думала, что рынок в России у нас молодой, поэтому так много спецов молодых, 40+ в нашей конторе было от силы процентов 5-7%, остальной был молодняк 23-33 лет в основном
Flutter - хорошая технология, теперь у нас в компании нет разработчиков мобильных приложений на нативных языках (Java, Kotlin, Object-C, Swift), они проиграли конкуренцию по скорости и стоимости разработки.
Как-то мне наши рекрутеры сказали, что просмотрели где-то 600 (!!) откликов на вакансию, провели несколько первичных собеседований, но до второго этапа никто не дошёл. Причина - выпускники онлайн школ.
Просто надо и бэкенд перевести на что-то флатероподобное, Django там или может ещё что-то с более низким порогом может есть))
Упомянутая прогулка - "Удмуртский скороход"? Позвольте полюбопытствовать, в котором году ходили?
Интересное мероприятие, организуется туристическим клубом УДГУ...
@constantine_mitin, отдельное спасибо за иллюстрации. Такой шикарный уровень оформления и не в корпоративном блоге, даже удивительно. Вы сами рисуете или вам кто-то помогает?
Кто-то еще расползается по смежным областям, кто-то уходит в консалтинг или в свой бизнес.
Еще чем ближе к 40, тем менее интересно вписываться в еще одну технологию. Просто потому что я уже знаю, каково это - изучить что-то новое за 2 недели. Been there, done that. А вот свой бизнес развивать уже интереснее, 100 км дистанцию пробежать интересенее, даже помидоры интереснее научиться выращивать, чем 100500 фреймворк осваивать.
Вполне себе можно уходить туда, куда не может пойти молодёжь, а именно в консалтинг, архитектуринг и аналитинг. Да, составление ТЗ, сбор требований и маппинг процессов в компании, - это то, чему не научиться за пару лет, потому что нужен именно большой и долгий опыт. Конечно, BPMN, UML diagrams можно научиться и за пару месяцев, но без опыта этим не заработаешь.
исчезают программисты после 40 лет
Откуда вообще взялся этот шизофренический бред про «программисты исчезают»? Не конкретно в этой статье, а вообще. Это гимнастки после 20 лет исчезают, а программисты вечны.
согласен не исчезают, бывает что некоторые становятся известными, типа попадают в 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
конечно последний список сильно не полный, кое с кем приходилось встречаться, но есть также достаточно много других людей, которые залуживают там быть
Набор штампов и мифов.
Хм, у меня обратная ситуация - вошел в айти в 48: выучил на бесплатных онлайн курсах питон, фрилансю на Апворке, сейчас учу Постгрес. Плюс английский, естественно.
Вообще не понял смысл статьи.
Как-то мы решили, что наши бэкенд разработчики (разработчики серверной части web-приложений) должны владеть PHP и Python одновременно. На освоение нового языка мы им давали как раз 2 недели.
Интересно, из каких соображений был выбран именно такой срок, и каковы были результаты через 2 недели? Только честно.
Да никуда мы не исчезаем! Как работали, так и работаем.
А то, что нужно вечно бежать чтобы остаться на месте - тоже некоторое преувеличение. Если просто найти нормальную работу, и просто работать на совесть (не на отвали, лишь бы не уволили, но и не сжигать себя, работая по ночам) то развиватсья будешь просто выполняя свои обязанности.
С возрастом, знаете ли, приходит осознание, что время - это не бесконечный ресурс. И если его оптималнее тратить, если научиться фокусироваться на наиболее важном, то и на работе будешь успешным, и в личной жизни ни себя, ни близких не обделишь.
Если просто найти нормальную работу, и просто работать на совесть
... то для душевного спокойствия еще нужно держать всевышнего за гениталии и быть уверенным что в ближайшие 20-30 лет нормальная работа останется нормальной, а не продастся/не обанкротится/в нее не прилетит что-то с неба и т.д.
20-30 лет? Вот это горизонт планирования!
На мой взгляд, в среднем, 2-3 года стабильности вполне достаточно. А дальше, если что - можно просто найти еще одну нормальную работу. Мы же говорим о синьорах с 20+ годами опыта, не так ли? Поиск работы не должен стать проблемой.
К тому же, меняя работу (или должность) раз в 2-3 года вы, хотите того или нет, будете разносторонне прокачивать свой опыт.
Моя мысль не о том, чтобы найти себе теплое место и морально заранее превратиться в пенсионера.
Мысль в том, что вовсе не обязательно бежать впереди паровоза. Не надо бежать, чтобы остаться на месте. Все эти тренинги, конференции, курсы, самообразование, pet-projects, open source и прочее - это все очень хорошо, но вовсе не обязательно. Чтобы остаться на месте - достаточно просто работать на совесть и прыть по течению. Периодически менять работу, но не потому что "надо" а потому, что жизнь меняется.
Я вот сейчас осознанно стою на месте. Тимлидю в меру своих умений. В прошлом квартале намекали, что при моем желании можно из тимлида вырасти в техлида.
Но - нафиг, я хочу стоять на месте.
В этом квартале попал в топ-10% перформеров. Ок, спасибо, премия - это всегда приятно. Но я просто хорошо работаю. А вне работы заниматься повышением квалификации, изучением очередных модных библиотечек - не-не-не. Я буду заниматься семейными делами, хобби.
А в профессиональном плане буду просто стоять на месте. Я вышел на плато. Другие вершины покорять не собираюсь, потому что у меня помимо профессионального развития есть жизнь.
Старую собаку не научить новым трюкам (я не про технологии, а про отношении к работе вообще). Кто жгет в 30, жгут и в 50, без относительно ролей. Кто в этом видит лишь способ заработка, продолжают решать свои однотипные задачи.
Если не идеализировать, то айти ни чем принципиально не отличается от других видов интеллектуального труда. Ощущения исключительности это сигнал, что пора расширить кругозор.
> Если не идеализировать, то айти ни чем принципиально не отличается от других видов интеллектуального труда. Ощущения исключительности это сигнал, что пора расширить кругозор.
исключительность IT вероятно себя исчерпала уже лет 30 назад, но принципиальная разница есть - это уровень стресса, реальность такова что интересного самостоятельного программирования становится все меньше, а работы с чужим плохо написанным кодом все больше, плюс средний уровень management (us) постепенно приближается к плинтусу , соответственно статус среднего программиста в средней компании получается чуть выше мебели, у начинающих программистов бывает много иллюзий на этот счет, но годам к 40 большинству все становится ясно, и конечно вызывает не самые приятные ощущения, разумеется есть исключения и в смысле нормальных компаний и грамотных руководителей, но это меньшинство, так что выбор вероятно на данный момент (в us) - либо работа на износ ради более-менее приличных денег например в Big 4, либо типа специалистом в узкой высокоприоритетной области например real time, которые всегда нужны, поэтому отношение будет другое, стресса меньше и работа интересней
Вы полагаете в MANGA работают на износ? Ну, может разве что в N букве.
если имеете личный опыт, было бы интересно, особенно если типа ветеран и знаете обстановку, можно конфиденциально в личку конечно
Говорю по своему опыту, опыту знакомых и по опыту незнакомых, что в Blind пишут.
Work/life баланс в MANGA (за исключением Нетфликса и отдельных команд Амазона) гораздо лучше чем в стартапах каких.
Перерабатывать приходится исключительно если вы метите в exceed expectations (и соответственно повышение), на meet expectation (минимальная прибавка и бонус) надо лишь честно делать свою обычную работу. Что как бы логично.
Если хочешь заработать десяток миллионов за десять лет а после - выйти на early retirement, то да - скорее придется повкалывать. Если хочешь более спокойной карьеры - работай в своем темпе, это марафон а не спринт.
Возвращаясь к первоначальному вопросу статьи - именно в MANGA я видел наибольший процент "программистов за 40". Вот туда они, наверное, "исчезают".
Принципиально отличается спросом. Ни на какой другой интеллектуальный труд нет такого универсально высокого спроса почти в любой точке планеты.
Это, конечно, пройдет. Со временем. Но не факт что в этом веке.
Думаю, не помешали бы примеры, почему надо все время учиться, потому что видно, что есть недопонимание. Базовые вещи (алгоритмы) не особо поменялись (хотя, например, современный 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) - очень много появилось в последние два десятка лет.
И это надо знать - шифрование, сжатие данных, сети, контейнеры - это все входит в арсенал практически любого профессионального программиста. Если кому-то это не надо, то это очень узкий специалист.
Мне сложно сказать про криптографию, не специалист.
Остальное перечисленное вами - ну была другая аббревиатура или другая реализация, но "что-то подобное" уже было в прошлом веке.
Да, последний пункт ("сетевые протоколы" поверх базовых TCP/UDP) - туда масса усилий вложено после 2000, но вот каковы принципиально новые концепции, которых не было известно 25-30 лет назад? Возможно они есть, но вот прям такие что прям вау?
От того что конкретная реализация (сжатия, simd) появилась недавно - это же не становится новой концепцией, правда?
Websockets наделали много шуму.
Щас ещё gRPC
Цитато: "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е, хотя конечно не в таком развесистом виде как сейчас.
В теории теория и практика одно и то же, но на практике абсолютно разные вещи. Тот факт, что 30 лет тому назад нечто обсуждалось на уровне концепции, совсем не означает того, что вы сегодня сможете взять как технологию и применить в продакшн, не имея в этом ни какого опыта. Один и тот же функционал с availability 99.9 и с 99.999 архитектурно будут совершенно разными решениями, с разницей по стоимости на порядки. Да и сами технологии мутируют до неузнаваемости. Вон выше пишут, что с++ времён его изобретения и современный это по сути два разных языка.
каковы принципиально новые концепции, которых не было известно 25-30 лет назад? Возможно они есть, но вот прям такие что прям вау?
например, р2р-сети? Напстер где-то вблизи 2000 года появился, но это явно что-то новое.
Блокчейн (пусть вне криптовалют) - тоже существенно отличающаяся штука.
у нейронки основные принципы были известны достаточно давно, но мощно развиваться стали где-то с 2010
например, р2р-сети?
В 2000-х их прикрутили для обмена музыкой и оно пошло в массы. Сама технология-то куда старше. Даже Фидонет, по сути, p2p-сеть :)
Блокчейн (пусть вне криптовалют)
Блокчейн - да, пожалуй сравнительно новая архитектура. Но я вряд ли ошибусь, если скажу, что за более чем десятилетие его существования разумных применений вне криптовалют для него не обнаружено. Под "разумным применением" я имею в виду такие задачи, которые с блокчейном можно решить быстрее/дешевле/эффективнее, чем без блокчейна.
у нейронки основные принципы были известны достаточно давно
А здесь требовалась аппаратная база - нейронки стали распространяться, когда в продаже появились доступные многопоточные вычислители.
ага, p2p, блокчейн, ML - нормальный список (с ML можно обсуждать что новое, что было, но там действительно есть серьезные новые достижения в 21 веке).
Я ж не говорю что прям совсем ничего нового нет, все-таки гигантская индустрия работает. Просто вот исходный обсуждаемый список, с SSE и NEON, он уж совсем примитивный какой-то.
Ответ куда проще. После 35-40 лет сидеть по 8 часов к ряду - медленное самоубийство. До 30 у людей более высокая работоспособность.
До 30 у людей более высокая работоспособность.
Главное, чтобы не было как в анекдоте про машинистку: могу печать со скоростью 400 знаков в минуту, но такая ерунда получается.
Въезжать в новую технологию, как правило, проще, чем в новую предметную область. Потому, что технология начинает бить по рукам за ошибки быстрее, и специалисты быстрее учатся их избегать.
Просчеты в дизайне со стороны архитектуры или бизнес домена при таком brute-force подходе становятся заметны лишь на этапах эксплуатации, а исправление обходится дорого. Если вам удалось собрать достаточно такого опыта и не выгореть к 30, вы счастливчик.
Работоспособность - не скорость. Нередко надо удерживать много вещей в голове одновременно и легко между ними переключаться. Если человек вынужден вставать каждый час, он нормально не сконцентрируется. Если человек в зрелом возрасте, он быстро переключаться не может по физиологическим причинам. Он хорош только для анализа, прогноза, планирования. Но для них уже нужен большой предыдущий опыт.
Вставать можно, переключаться нельзя.
Умение переключаться это что-то из области темперамента. Мне всегда лучше удавалось писать код в состоянии потока, когда снаружи ни что не отвлекает. Поэтому часто работал по ночам. Трындеть же на митингах могу хоть весь день, на абсолютно разные темы.
Если человек вынужден вставать каждый час, он нормально не сконцентрируется.
видел кучу программистов бегающих курить каждый час
Если человек вынужден вставать каждый час, он нормально не сконцентрируется
Всё это индивидуально. Я, наоборот, постоянно переключаюсь между рабочим потоком и жвачкой до мозгов, у меня так наиболее продуктивно получается работать. И я в зрелом возрасте :)
А кто заставляет сидеть по 8 часов ? Работать надо не много, а эффективно )
Предыдущие 1С это локальная вариация на тему COBOL: такой же бизнес ориентированный DSL, и с такими же специфичными проблемами в плане сопровождения. Деление на сисмемных программистов и прикладных с узкой специализацией в своих предметных областях это не мейнстрим. Рынок подталкивает разработчиков к универсализации.
Нло прилетело и выгрузило всех потерянных 40-летних программистов в этом треде.
Кроме того, сейчас начали набирать популярность сервисы NoCode и LowCode, которые позволяют создавать несложные мобильные приложения в визуальном редакторе.
Всё-таки к вёрстке вы имеете очень опосредованное отношение, да?))
Потому что уже лет 20 существует такая софтина как Adobe Dreamweaver. Лет 15 назад у меня дошли руки её попробовать... Вкратце суть - либо лэйаут на основе корневого элемента table, либо абсолютное позиционирование. Ну как бы для любого сервиса (ну кроме непрофильных "хомяков" - адвокату домашнюю страничку своей конторы позволительно слепить в Тильде) это даже в те времена было лютой халтурой. Впрочем, это уже оффтоп.
По сабжу. Тезисно:
Мне 41. Профессий и увлечений я попробовал достаточно, но в итоге все равно вернулся в IT. "Вернулся", потому что "начал" лет в 12 - с подаренного отцом ZX-Spectrum. Разумеется, после освоения азов в таком возрасте (сейчас это не впечатляет, но это 93-й год был), "войти" в IT-шную специальность - не представляло какой-то особой трудности.
Потом много чего было. И уход на фриланс, и попытки попробовать на "постоянке в офисе", и несколько циклов выгораний, кризис среднего возраста, "поиски себя" и т.д. Сейчас, в принципе, я навел в голове порядок (хотя с мотивацией есть проблемы). И вот что хочу сказать - да, в IT действительно надо постоянно учиться. И? Почему это плохо? Преодоление физических нагрузок (прекратите без конца проводить аналогии со спортом! все и так в курсе что айтишники следят за здоровым образом жизни) совершенно не то же самое, что тяга к овладению новыми знаниями. Просто кому-то это надо, а кому-то категорически нет. Я смотрю на своих сверстников, которые сейчас "обросли жирком в кабинетах" и извините, но меня такая перспектива никогда не прельщала. Я предпочитаю, чтобы мой мозг постоянно работал. В конце концов, старческая деменция - не такое уж и редкое явление. Я в принципе не могу заниматься деятельностью на которой "тупеешь", какой-бы комфортной во всех остальных аспектах эта деятельность ни была (с алкоголем завязал по этой же причине).
А теперь довольно пафосный (ну что поделать - именно так я это и понимаю) вывод: в IT вам будет комфортно, если вы... не можете жить без IT. В противном случае вас эта кухня довольно быстро прожует и выплюнет. Ну вот актёры же тоже неплохо зарабатывают? И условия труда у них тоже вполне комфортные. И тоже выгорания случаются. И прям на "рабочем месте". И даже такая же патетика - "вы станете настоящим актёром, только тогда когда поймете что не можете жить без сцены". Только вот почему-то интернет не забит рекламой актёрских курсов. Потому что любому адекватному человеку понятно - случайные люди в профессии редко становятся квалифицированными специалистами. Но вот именно с IT это и не работает. Вот такое ощущение, будто большинство считает что для любой другой профессии нужны какие-то скиллы, талант, предрасположенность... а в IT сможет любой дурак... Откуда это пошло - непонятно... То ли обыватели решили, что раз они могут довольно просто установить на смартфон приложение - то им прямая дорога в IT))
Так что ещё раз: если чувствуете что IT - это "не ваше", бегите отсюда)) Будет только хуже.
Интересно, а почему, собственно, граница именно в 40 лет выбрана? Я вот тут давеча взял на работу дотнетного сеньора 52 года. Все по классике: старая школа МФТИ, 20 лет плюса, 20 лет дотнета...Ну... с пересечением в смысле. Так вот, доложу я вам, это не просто старый конь, что не портит борозду. Это, блин, землеснаряд! Он в легаси коде ориентируется как у себя дома и хреначит, хреначит, хреначит, только задачи успевай подносить. Причем, качество кода выдает такое, что хоть распечатки на стенку в золотой рамке вешай и в них носом джунов тыкай.
Мне кажется, что одна из очень больших проблем современного IT (помимо случайных людей), это HR. Я вот, как человек, который много лет занимался администрированием баз данных и который хочет вернуться к разработке, просто не могу пройти барьер в виде HR из-за того, что у меня в резюме указано. При всем при этом я со школьных лет и по сегодняшний день что-то пишу (автоматизация, для себя, в качестве обучения) и уверен, что на джуниорские и миддловые позиции вполне мог бы пройти собеседование, но хрен. Ну и 40 скоро уже.. Хотя я не ощущаю себя старше 25. Понимаю, что HR как фильтр нужны и люди вроде меня это те, кем можно принебречь. Но мне кажется, я ничем не хуже в профессиональном плане многих других и с этой системой что-то не так.
Думаете сидит себе HR и думает, как бы ему саму себе усложнить задачу. Так что ли?
Этот барьер не HR ставят, а клиенты (внутренние и внешние). Если они хотят видеть до 30-и, то HR то что должен сделать? подделать Ваш паспорт что ли?
Этот барьер не HR ставят, а клиенты (внутренние и внешние).
Иногда такой барьер вполне себе ставит сама ХРюшка. Особенно если она ищет таким образом себе мужа, формируя массовку нанимаемых (реальные истории, с 2000х слышал, и не раз)
да-да, именно так. именно все HR-ы незамужние девушки и вместо работы ищут себе богатенького молодого программиста
А молоденькие неженатые программисты ходят на собеседования не чтобы работу найти, а чтобы присмотреть молоденькую симпатичную HR-у (реальные истории, слышал еще до нашей эры)
Ах да, Вы же написали "иногда". А иногда бывает все, кроме встречи с динозавром (с которым, как известная, встреча 50х50)
Обсуждается ситуация в целом. что, SteelRat попадаются исключительно HR-ы, которые ищут мужа и поэтому не рассматривает его резюме? так что ли? к чем это ваше "иногда"
Я вам таких "иногда" историй могу рассказать, что хватит на целую книгу. А если еще подливать... Причем не тех, что слышал, а те, что видел своими глазами
Вот на ваших работах было, чтобы мидл-менеджеры дрались прямо в офисе? значит ли это, что все мидл-менеджеры деруться? значит ли что во всех обсуждениях мне надо писать "иногда мидл-менеджеры деруться"
Как программист, уже 25 лет назад переваливший через указанную сакральную цифру, могу сказать, что единственное важное - потеря мотивации.
Осознание, что на самом деле все усилия - только ради того, чтобы облегчить природе размножение идиотов, сильно убавляет энтузиазма. Тем не менее, после длительного перерыва в собственно программировании с огромным удовольствием вернулся к нему (на работе могу себе позволить заниматься только тем, что мне интересно) - соскучился. Но после февраля отрезало, наверно, окончательно. Исполняю, что должен, не более того.
А у меня многие знакомые (и я тоже) на старости лет ушли из программирования в сантехники небоскреба ИТ - в сисадмины :) Некоторые даже очень удачно - шарят в никсах, развертывают рабочие какие-то джайлы за 5 сек одним скриптом и т.д. А остальные тупо мышевозят в каких-нибудь мелких конторах и получается как-то поспокойнее.
PS Еще бы не путали нас с монтажниками (ноги и спина уже не новые) и не эти долбаные пучки телефонии, нарукожопленные кем-то в начале нулевых, которые просто страшно трогать, то было бы вообще замечательно :)
Ммм... мне полтинник и я давно подумываю об уютной палате с мягкими стенками.
Но пока не заработал :(
То есть сама отрасль лишает свой хвост работы, отбрасывая его.
Это естественный процесс отъёма поляны, который происходит в любой отрасли. В "гроздьях гнева" фермеров вытеснили трактора, а в IT более умные айтишники делают инструмент для отжима поляны у более глупых айтишников, которые тупо работают руками.
Профессионалы остаются востребованными и после 50-60 лет.
Тока надо, чтобы это поняли на рынке. Из недавнего разговора с HR:
"а вы же ещё и дизайнером работали?".
"Нееет, почему Вы так решили?".
"Ну у вас тут написано in chief designer role".
Получил моральное удовольствие от вкусной статьи. Спасибо. Не в стиле "пора на свалку", а жизнеутверждающе. Много вижу выгоревших глаз, много кто тянет лямку и ненавидит, боюсь детей толкать в ИТ, зная как там может быть выгорабельно.
Забавно, что в районе 40 исполнил давнюю мечту - написал НФ-повесть. Ну и начал после этого изучать писательство и сценаристику.
Надеюсь постепенно туда и уйти.
Где водятся Волшебники, где водятся Волшебники, где водятся Волшебники?
В фантазиях твоих.
С кем водятся Волшебники, с кем водятся Волшебники, с кем водятся Волшебники?
А с тем, кто верит в них.
В Таиланд переезжают. Или еще куда в теплые морские края.
Перед тем, как спорить с выдвинутым тезисом, хорошо бы его как-то обосновать. Я, напрмер, не замечал, чтобы программисты после 40 лет куда-то исчезали. Да, доля молодых людей больше, чем тех, кому "за", но это обусловлено, на мой взгляд, продолжающимся ростом спроса на число программистов со стороны бизнеса.
То есть, для примера, если число программистов за 10 лет удвоилось, то автоматически минимум половина программистов - это молодёжь.
Так что некая нормализация возрастного состава возможна только тогда, когда число программистов в мире стабилизируется, а пока, насколько мне известно, оно только растёт и растёт.
Выше уже приводили статистику, по которой кол-во программистов удваивается каждые 5 лет. Другими словами, программистов с опытом более 20 лет чуть больше 6% от общего кол-ва программистов, и то при условии, что никто из них не поменял сферу деятельности.
Ну, и наверно, когда рассуждают о 40-летних программистах в основном имеют в виду эту категорию, а не тех, кто закончил курсы по входу в IT в 39 лет.
P.S. Вот тут Роберт Мартин рассуждает на эту тему: https://www.youtube.com/watch?v=sPXk11hrWTM&t=969s
"Пошли мы без подготовки, как и многие другие. В целом, дистанция посильная для любого физически здорового человека."
100км за 24 часа это относится уже к экстремальному туризму и без подготовки туда нырять очень не рекомундуется, т.к. можно словить травму и потом мучаться до следующего года...
Всё-таки истина проста, хоть и уже набила оскомину: нужно заниматься тем, что нравится. Но, к сожалению, не всегда это получается. Далеко не всегда. Всё-таки работа - это прежде всего работа, а не развлечение по интересам...
Сам я учился на IT-специальности. После учёбы пошёл работать инженером ВКС в одну из дочек "Росатома". С 4 курса периодически занимаюсь программированием в вялотекущем темпе. Периодически бросаю на 2-6 месяцев, периодически возвращаюсь. Были мысли перейти в backend-разработку на Java. Есть возможность сделать это внутри компании. Как раз есть некоторые особенности моей работы, которые мне, прямо сказать, не нравятся: это сопровождение сеансов ВКС (из-за чего приходится с руководством сидеть в переговорках хоть целый день), это и периодический график с 7:30... Но после предыдущих заходов в программирование дошло до того, что я собрал всю необходимую литературу для обучения, но начать не могу. Лень и нет интереса. Я понял, что для себя иногда (прям очень иногда) написать что-нибудь - это классно, а вот работать программистом и постоянно следовать новомодным технологиям - нет уж, увольте. Коли нет интереса, нечего мучить себя. Я просто в итоге понял, что мне больше нравится образ жизни, который позволяет вести эта профессия: работать удалённо. Очень давно мечтаю уехать из Москвы на дачу и работать удалённо. Но даже ради этого не хочется заниматься нелюбимым делом. Ранее казалось, что ради заветной мечты могу себя пересилить, но нет. Программирование - не та сфера деятельности для таких планов.
Но и на текущей работе не хочу долго работать. Выше указанные и другие минусы прям покоя не дают :) Буду думать, куда перейти. Но программирование, наверное, всё-таки оставлю. Короче, занимайтесь, по возможности, тем, что нравится и не идите туда, где не нравится. Даже ради денег. Потому что есть риск выгореть ещё на этапе обучения, как я :) Каждый должен заниматься своим делом.
На самом деле, постоянно следовать новомодным технологиям вовсе необязательно. Консервативные программисты поддерживают старые продукты и получают за это нормальные деньги. Другое дело, что многим скучно заниматься из года в года одним и тем же, хочется чего-нибудь новенького, но если такого желания нет, то свой продукт всё равно найдётся, благо на Java написано немерянное количество кода. Даже программисты на древних Fortran и Cobol находят работу, причём в силу их малого числа им ещё и очень неплохие деньги платят!
Читаем:
На освоение нового языка мы им давали как раз 2 недели.
Потом это:
Flutter - хорошая технология, теперь у нас в компании нет разработчиков мобильных приложений на нативных языках (Java, Kotlin, Object-C, Swift), они проиграли конкуренцию по скорости и стоимости разработки.
Далее читаем профиль автора, и делаем очевидные выводы.
Капец как много текста и кода ))). ИТшник иль нет, по мне так был бы хороший (отличный) специалист...
IT для неайтишников: Куда исчезают программисты после 40 лет?