Современный смартфон это вещь. Мы как-то со школьниками искали в институтском коридоре силовую линию магнитного поля Земли. Нашли. ) Также использовал датчик магнитного поля для намотки катушки на станке.
Я предложил бы рассмотреть вопрос несколько с другой стороны.
Вы описываете ситуацию и ее развитие сугубо с технической стороны: "начало дня", "календарь", "расписание", "дейли в 10:30", "ушли в 23:00" и тд.
И далее описываете, как обнаружив, что система не работает, сугубо техническими подстройками пытаетесь достичь условий, когда система все-таки будет работать.
Чего не хватает в "ИТ", так это общегуманитарного и естественнонаучного подхода/бекграунда, где все эти проблемы известны, как и их решения, и не нужно заново изобретать велосипеды.
Вот смотрите:
Вы договорились, что дейли у команды в 10:30.
Договорились, что если человек на нем нужен, но вынужден пропустить, то предупреждает/согласовывает это.
Теперь внимание: происходит ситуация, когда сотрудники вынуждены регулярно уходить в 23:00. Вы продолжаете считать, что они должны быть на месте в 10:30 (да, не сообщаете им об этом, но продолжаете так считать). В "обычном" мире это называется что-то вроде "существенным изменением условий, когда договор или его часть теряют силу" - а для вас это как будто уникальная ситуация. (Причем в вашем случае изменение условий столь сильно, что, в общем, недействительность договора даже не нужно как-то специальгно фиксировать/подтверждать - это происходит явочным порядком.)
Т.е., ситуация, которая у вас возникла, вовсе не уникальная. Если знать несколько больше, чем "аджайл", то вы будете знать и про класс таких проблем, и как предупреждать их появление, а если появились, то как их решать на принципиально ином уровне, нежели наущупь пытаясь подстроить технические параметры и тд.
Так что предложил бы посмотреть в этом направлении.
Смотря "разработчик" и "разработка" чего, зависит от контекста. В вашем примере это разработчик систем, что, кстати, подтверждается и информацией в вашем профиле.
Когда же говорят "разработчик" применительно к программированию, то имеется в виду "разработчик ПО", еще точнее, "инженер-разработчик ПО".
Формально более правильно употреблять термин "инженер-программист", но, к сожалению, упомятутый вами термин программист несколько дискредитирован последние лет 20 (когда программистами кого только ни называли).
Кроме того, когда говорят "разработчик", имеет место и калька с английского Software Development Engineer - инженер по разработке ПО, что в обыденной речи редуцируется до "разработчика".
Кажется, вы только что придумали интерфейс IEquatable(T) — это как раз и есть внешний хешер и сравнитель)
Хотя идея ваша понятна — не объект передавать во внешний хешер (IEquatable), а хешер в объект — как стратегию, инвертировать эту ситуацию.
Если мы говорим о банках, то природа денег, и все, что с этим связано, значительно поменялась, когда вместо денег из ценных металлов появились бумажные деньги (в общем случае — обязательства).
Постепенно это привело к появлению банков.
Смотрим дальше — когда все платежи стали проходить через банковские карты, то природа всего того, что стало связано с деньгами, стала (при достаточных заработках в развитой экономике) похожа на то, что было описано в утопиях — зашел в магазин, взял, что нужно, вышел.
Когда стало можно платить смартфоном — опять же, при оговорке о развитости экономики и доходах — это и вовсе стало похоже на "от каждого по способностям, каждому по потребностям".
В какой то момент продукт видоизменяется до неузнаваемости.
Даже если копнуть в самую суть, о которой вы говорите — а точно банки по-прежнему живут на разницу между ставками кредитов и депозитов?
А пресловутый "банковский мультипликатор" не нарушает этот принцип (жить на разницу)?
А история многочисленных послеледних кризисов не показывает нам, что зачастую эта разница отрицательна, и ситуация спасается докапитализацией со стороны, в тч государствами?
Применение применению рознь. "хостинги, ЦОДы, системные интеграторы" продают ИТ-товары или услуги
Во многом верно, и именно поэтому "хостинги, ЦОДы, системные интеграторы" стали первыми ИТ-компаниями.
Однако, когда продукты тех же банков стали моделироваться и реализовываться в виде программных продуктов с мощным бек-ендом и доступным любому неподготовленному пользователю мобильным фронтом, то и сам продукт изменился настолько, что может считаться уже ИТ-продуктом.
Если же мы по-прежнему будеми считать, что банковские продукты — не "ИТ-продукты", то давайте задумается, а являются ли продукты и услуги "хостингов, ЦОДов, системных интеграторов"?
Условно говоря, хостер предоставляет прощадку и канал для размещения информации и передачи данных — по сути, ИТ-вариант типографии и почты.
Это я к тому, что сейчас продукты традиционного, "старого" ИТ, и те же банковские продукты — в равной степени ИТ-продукты.
Ну а ваш аргумент про СБ и СБТ — от лукавого же. Деление условное по совокупности конъюнктуры — вчера разделили, сегодня объединили, завтра опять разделяют (что, в реальности, собственно, и происходит).
А суть одна — банк превратился в высокотехнологичную ИТ-компанию.
Автор пишет, что "хостинги, ЦОДы, разработчики ПО, производители железа, системные интеграторы" это true ИТ, а вот право банков, такси и пиццерий называться/быть ИТ в статье оспаривается.
В чем же здесь фатальная, системная ошибка, из-за которой дальше все идет кувырком как в индустрии, так и в самой статье?
Автор в перечислении true ИТ-шников где-то в середине мимоходом, походя, упомянул "разработчиков ПО".
Так вот, есть разработка — как ПО, так и железа, и более общая разработка (R&D, алгоритмы).
А есть ИТ, где применяют результаты разработки. Поначалу ИТ действительно было ограничено "хостингами, ЦОДами, системными интеграторами".
Потом, в связи с интенсивным развитием и экстенсивным расширением технологической базы (впрочем, и социальной системы), объективно ИТ-компаниями стали становиться банки, страховые компании, такси и пиццерии. И это здорово.
И что здесь важно. Есть разработка (как научная R&D, так и просто инженерный development по результатам R&D).
Разработка, как и математика — внезапно, вечна. Она была и остается разработкой с ватманом, кульманом, Си и Паскалем, и последними версиями C#/Java/Kotlin/JS/TS и прочими легионами.
И именно ее никогда не заменит AI, чтобы тут ни говорили на этот счет.
И фатальная ошибка в смешивании разработки и ИТ.
И почему то первому поколению (хостинги и прочая) ИТ автор разрешает "пристегнуться" к разработке, а тем же банкам и такси отказывает.
Но те же банки по объективным причинам (безопасность, эксклюзивный опыт) ведут собственную разработку, и они в этом смысле "более" ИТ (ну если уж мы смешиваем разработку ти ИТ), чем хостинги или системные интеграторы, которые компонуют системы из готовых программных и железных решений.
Словом, нужно просто понимать, что есть разработка, и это уникальная область, и разработчиками не могут быть все (но можно войти в ИТ, если так хочется!).
А вот дальше статья производит совсем грустное впечатление.
Начинает казаться, что это очередной заказ про якобы "перегретые" зп в ИТ/разработке, про то, что "эти ИТ-шники слишком много получают".
И хочется в очередной раз, очередному автору, посоветовать почитать про пирамиду Маслоу и воспроизводство и расширенное воспроизводство рабочей силы у Маркса. И подумать, какая зп должна быть у разработчика, чтобы удовлетворять этим критериям.
Впрочем, автор на самом деле все понимает — ведь он пишет, что в ИТ зп вовсе не так высоки (и советует "вайтишникам" призадуматься — "а оно надо?"), а когда начинает приводить примеры, где зп более-менее приличные, внезапно, это как раз и подпадает под определение разработки, а не ИТ.
Ох уж эти около-ИТ персонажи.
Если человек в конце 90-х верстал голые HTML и CSS, а в начале нулевых руководил широко известной в узких кругах местной веб-студией, потом закрыл ее, а на волне роста ИТ-отрасли таки удержался в ней, устроившись ПМ'ом (а по настоящему найдя себя в стенд апе), то, по большому, счету, какое отношение он может иметь к разработке и как может предметно рассуждать о ней?
Так эти версии отнюдь не противоречат друг другу.
Ушла необходимость в упомянутых профессиях, образующих по сути средний класс (или ее ушли?), и все, можно вести более другую линию.
Коллега, раз уж вы вспомнили и цитируете классиков ("стоимость воспроизводства рабочей силы"), то рекомендовал бы вспомнить их же и обратить внимание на стоимость расширенного воспроизводства рабочей силы.
Стоимость квадратного метра была упомянута неслучайно.
Нюанс в том, что хайп вокруг новой технологии не ситуативный.
Падение реальных зп во всех секторах экономики за 30 лет, о котором вы говорите, это следствие окончания холодной войны и гонки вооружений, когда были востребовано огромное количество ученых, инженеров, рабочих, преподавателей, врачей, мастеров культуры.
К сожалению, с окончанием холодной войны и гонки вооружений (что само по себе хорошо) изменилась и ситуация с этими системообразующими в обществе профессиями.
А сейчас новый мировой тренд — биг дата в облаках.
И куют это теперь разработчики и в целом ИТ-работники. И этот тренд очень мощный и надолго. Так что хайп отнюдь не ситуативный.
Похоже на очередную "заказную" статью, что "программистам слишком много платят".
А много это сколько?
Если в Москве зарплата сеньора это ± 1 квадратный метр ближе к мкад, это много или мало, с учетом, что сеньором становятся не со студенческой скамьи?
В регионах цифры другие, но пропорция примерно та же: 1 зп — 1 кв метр.
Может, это не "программистам" много платят, а мало другим профессиям, где доход == зарплата?
Почему в обществе до сих пор считается, что зарплата это что-то такое, чисто на текущие потребности?
А почему именно разработчикам платят больше — давно говорю о том, что в силу ряда особенностей, разработчика, как правило, нельзя заменить представителями смежных ролей (тестировщики, пм, аналитики, не говоря уж о несмежных профессиях), а вот разработчик в большинстве случаев заменить другую позицию сможет.
Так что, почему разработчикам и в целом в ИТ платят больше (если говорим о тех профессиях, где работают за зарплату) — потому что рынок, закон спроса и предложения.
А вот в чем с автором можно согласится, так это с тем, что из-за этой ситуации (относительно высокие доходы в сфере работы за зарплату) в индустрии наблюдается огромный наплыв тех, кто пришел сюда из-за денег, что приводит к невеселым последствиям.
PS. И да, это уже несмешно писать откровения на тему "программистам много платят, и я этим недоволен".
Когда читаешь статью, то хабр показывает похожие статьи. Вот и под этой статьей хабр показал ссылку на статью 12 или 13-го года с аналогичным названием и содержанием. И это до всех последних кризисов, когда у программистов зарплаты были не такие уж и высокие, а в ряде сфер зп были выше в разы. И все равно зарплаты программистов кому-то уже тогда не давали покоя.
Мне же более интересен пример с тупиковыми, но при этом реально интересными ветвями, связанными с ИТ.
Привык получать, как C-level, а навыков меньше, чем
Ну, тут все просто. Похожих примеров полно и не в ит, и большой разницы ит — не ит нет.
Обычно такие возможности всплывают во время исторических перемен, во время смены укладов в экономике (и пока большие парни в новой нише все не устаканили и не привели зарплаты работников к обычной — на еду, одежду и кредит на авто), и во время локальных всплесков типа упомянутого вами майнинга.
Итак, если вы не прирожденный бизнесмен-предприниматель-директор, который постоянно постоянно пробует, падает, снова встает и пробует, инвестирует и растет, а, если правильно понял вашу постановку — что называется, обычный человек на зарплате, на которого свалилась эта манна, то первое и главное — не "прогулять" все это, а купить столько, условно говоря, "трехкомнатных квартир", сколько получится.
Второе. Что делать дальше (чем интересным заняться, когда лавочка закроется, а, повторимся, по условиям задачи, вы не инвестор) — ну или попробовать найти интересную работу с большой зп, ну или просто работать, но в свое удовольствие, не перенапрягаясь. Возможно, сдавать лишние квартиры в аренду.
Почему так говорю — в те же 90-е и 00-е полно было примеров, когда вот такая манна сваливалась обычным людям на короткий или не очень короткий промежуток времени (а то и лет на 10).
Но большинство к этому оказывались не готовы, поэтому просто жили на широкую ногу, а когда лавочки закрывались, все заканчивалось ничем.
А могли бы хотя бы по паре квартир прикупить.
Вы правы, историческая конъюнктура тут получается, накладывается на протяженность активной жизни отдельно взятого человека.
Но вариативность всегда есть.
Когда я таки да, полюбил турбо паскаль, а потом настало время выбора, мне было ясно, что через 15 лет будущее за "большим" программированием (еще до появления терминов "облака", бек енда, биг даты).
Но не за радиотехникой и "железом", которое все больше становилось управляемым через контроллеры и софтовые прошивки.
И не за популярными и быстро-прибыльными для начинающих специалистов ERP-платформами.
Далее с каждым годом предвестников становилось все больше — тут и ввод в платформы разработки сетевой и распределенной парадигмы, и веб 2.0, и прочая, пока не выстрелило окончательно.
Однако! Тогда же мне было ясно что будущее и за робототехникой, причем, возможно, даже на стыке с биологией и медициной.
И таки да, посмотрите, на ютубе воспоследовавшие ролики с роботами.
Но так же было ясно и то, что выбора в эту пользу нужно уже быть в среде с высокими экономикой и материальной культурой.
А с учетом, что турбо паскаль был милее, и для него нужны лишь компьютер и голова (меньше, чем чтобы заниматься робототехникой), то выбор был очевиден.
Но это я к тому, что есть вариативность выбора. При других исходных данных (если бы за паскалем не просматривалось бы перспективы) можно было выбрать и роботов.
А за другие профессии, право, не переживайте.
В 90-е и 00-е много у кого были шансы, и поболее, чем у программистов сейчас.
Те же названные вами зарплаты в 200-300 были не редкость до кризиса 08 (при тогдашних ценах).
Да и сейчас, если кто только вступает в жизнь, при должной шустрости, все должно получиться и без программирования.
Ну, знаете, а в нулевые, до бума в ИТ, как раз много у кого были доходы, по покупательной способности превышающие нынешние ит-шные.
А вы прям чуть ли не вину заставляете испытывать ит-шников за их более менее адекватные доходы.
И, похожее, уровень белых доходов программистов неслучаен, т.е, неправильно говорить, что "повезло".
Сейчас вся экономика и — бери шире — дискурс жизни строится вокруг больших данных.
И нужно, чтобы это кто то ковал. Вот программисты и куют.
А вот во второй половине 20 века все вертелось вокруг НТП и гонки вооружений.
Отсюда и средний класс — ученые, инженеры, врачи, учителя, культура.
К сожалению, доход в профессии в значительной степени зависит от исторической конъюнктуры, но это вовсе не "случайно" и не "повезло". А как раз таки предопределено.
Хорошо герой начинал, когда нашел будущую перспективную нишу — ну вот эти линуксы, сети и тд.
Впереди большинства (за несколько лет до того, как поднялся хайп).
И мог бы успешно в этом работать, развиваться и приходить к успеху, и в наши дни, и по сей день.
Но нет — поддался давлению окружения и спекся.
Ну и кто виноват?
А также много других "звоночков" в спиче героя интервью.
И да, самая мякотка в том, что практически все, что он рассказывает про свою прежнюю сферу — в значительной мере присуще и новой, только это он не успел это понять, хотя его смена нескольких работ в новой сфере, с сопутствующими обстоятельствами, намекают.
А там, где не "то же самое", то другая крайность.
Если в прежней сфере, по словам автора, люди могли годами получать зп и просто приходить на работу, буквально ничего другого ничего не делая, то в новой ведь скрам и аджайл, и нужно каждый день рассказывать что ты сделал вчера после скрама, и сегодня до скрама.
Нетрудно заметить, что невозможно каждый день совершать отдельно стоящие реальные свершения, а это значит, либо скрам превращается либо в ритуал (а реальная работа делается параллельно, и хорошо, если делается), либо каждый день плодится не очень хороший код, никак не увязанный с архитектурой и моделью (что можно приравнять к "ничего не делается").
А также есть мнение в индустрии, что такие ритуальные отчеты сильно напоминают присядание перед малиновыми штанами, что герою как раз не нравилось в прежней сфере.
Это все к тому, что крайности, они же встречаются в одной точке и оказываются одним и тем же.
Получается, это история про человека, который в самом начале поддался давлению и совершил ошибку, затянувшуюся на 20 лет, а теперь, не успев разобраться, испытывающего восторг неофита от новой сферы.
Тем не менее, изначально вы говорили о "накопить на машину за полгода", а не о машине стоимостью в полугодовую зарплату.
Ничего личного, но это хороший пример, демонстрирующий популярный подход к оценке размера зарплат.
Почему то зп оценивается именно так: "ах, я за полгода могу накопить на это и на то".
Или на собеседовании/переговорах о зп может быть:
"ну, смотри, какая прибавка, вот что купить теперь на твою зп можно".
Вот только при этом почему то считается, что на желаемое тратится вся зп за некоторый период.
А стоимость жизни, а другие расходы?
Штука в том, что очень давно прошли времена, когда можно было сильно ужаться на длительный период, и скопить большую сумму с обычной зп.
Давно выросла как стоимость жизни, так и сами стандарты уровня жизни (ниже которого вы не сможете и выполнять свою работу).
В этом смысле и большие зарплаты айтишников вовсе не такие большие, как кажутся.
Например, попробуйте выдержать современный ритм с переработками и постоянным переключением контекстов по скраму/аджайлу, питаясь, как в былые времена было принято, гречкой и макаронами.
А потом можно рассказать, как за счет этого удалось сэкономить и накопить большую сумму.
Возможно, вы правы, и F# можно рассматривать как полноценный и главный dotnet язык.
Было бы здорово, если бы это вошло в мейнстрим.
C# в каком-то смысле слишком низкоуровневый. При всем сахаре и новом FP-стиле он по-прежнему почти один в один маппится на IL и прочие платы платформенные вещи, т.е, своего рода "ассемблер".
А нужен более высокоуровневый именно язык, и без унаследованных backward compatibility вещей.
В мире Java та же история. Более высокоуровневым языком для JVM мог бы стать Kotlin, но перспективы в части back end пока не ясны.
Поддерживаю любые F#-начинания, но называться dotnet-разработчиком это, скорее, про понимание основных концепций dotnet ("что это такое" в целом, GC, CLR, CTS, IL) и основных встроенных и сторонних библиотек для работы с БЛ, сетью.
И, конечно, отличное знание языка и понимание, как он маппится на те же CLR, CTS, IL.
Лучше, конечно, больше чем один язык.
Но F# это скорее, все-таки про функциональное программирование. Хотя тут очень важно и понимание, как он маппится на механизмы dotnet.
Другое дело, актуальный разработчик должен давно использовать не только linq, но и придти к другим фунциональным парадигмам в использовании C#.
И тут совершенно логичным выглядит как минимум интерес к F#. А вот дальше сложнее — с вакансиями и реальным его использованием в проектах.
Одна из основных мыслей статьи — создание на F# чисто модели, и вынос ввода-вывода на периферийный контур — очень импонирует.
Делаем физическую лабораторию из смартфона своими руками
Как тимлиду найти идеального кандидата, и что делать с неидеальными
Спасибо за ответ.
Я предложил бы рассмотреть вопрос несколько с другой стороны.
Вы описываете ситуацию и ее развитие сугубо с технической стороны: "начало дня", "календарь", "расписание", "дейли в 10:30", "ушли в 23:00" и тд.
И далее описываете, как обнаружив, что система не работает, сугубо техническими подстройками пытаетесь достичь условий, когда система все-таки будет работать.
Чего не хватает в "ИТ", так это общегуманитарного и естественнонаучного подхода/бекграунда, где все эти проблемы известны, как и их решения, и не нужно заново изобретать велосипеды.
Вот смотрите:
Вы договорились, что дейли у команды в 10:30.
Договорились, что если человек на нем нужен, но вынужден пропустить, то предупреждает/согласовывает это.
Теперь внимание: происходит ситуация, когда сотрудники вынуждены регулярно уходить в 23:00. Вы продолжаете считать, что они должны быть на месте в 10:30 (да, не сообщаете им об этом, но продолжаете так считать). В "обычном" мире это называется что-то вроде "существенным изменением условий, когда договор или его часть теряют силу" - а для вас это как будто уникальная ситуация. (Причем в вашем случае изменение условий столь сильно, что, в общем, недействительность договора даже не нужно как-то специальгно фиксировать/подтверждать - это происходит явочным порядком.)
Т.е., ситуация, которая у вас возникла, вовсе не уникальная. Если знать несколько больше, чем "аджайл", то вы будете знать и про класс таких проблем, и как предупреждать их появление, а если появились, то как их решать на принципиально ином уровне, нежели наущупь пытаясь подстроить технические параметры и тд.
Так что предложил бы посмотреть в этом направлении.
Как тимлиду найти идеального кандидата, и что делать с неидеальными
Смотря "разработчик" и "разработка" чего, зависит от контекста.
В вашем примере это разработчик систем, что, кстати, подтверждается и информацией в вашем профиле.
Когда же говорят "разработчик" применительно к программированию, то имеется в виду "разработчик ПО", еще точнее, "инженер-разработчик ПО".
Формально более правильно употреблять термин "инженер-программист", но, к сожалению, упомятутый вами термин программист несколько дискредитирован последние лет 20 (когда программистами кого только ни называли).
Кроме того, когда говорят "разработчик", имеет место и калька с английского Software Development Engineer - инженер по разработке ПО, что в обыденной речи редуцируется до "разработчика".
Как тимлиду найти идеального кандидата, и что делать с неидеальными
>> (у меня не поднималась рука говорить что-то на эту тему человеку, который вчера ушел с работы в 11)
У вас гибкий график работает в одни ворота - т,е, уйти можно (разрешают - гибкий же график) в 23:00, но придти нужно в 9:00?
А вы именно в частном порядке решали не ругать за опоздание?
GetHashCode() и философский камень, или краткий очерк о граблях
Кажется, вы только что придумали интерфейс IEquatable(T) — это как раз и есть внешний хешер и сравнитель)
Хотя идея ваша понятна — не объект передавать во внешний хешер (IEquatable), а хешер в объект — как стратегию, инвертировать эту ситуацию.
Отчасти при реализации GetHashCode может помочь https://docs.microsoft.com/en-gb/dotnet/api/system.hashcode?view=dotnet-plat-ext-3.1
Да, это не внешний хешер, но структура, принимающая значимые данные типа, и вычисляющая хеш.
Эх, айти, куда ж ты котишься?
Если мы говорим о банках, то природа денег, и все, что с этим связано, значительно поменялась, когда вместо денег из ценных металлов появились бумажные деньги (в общем случае — обязательства).
Постепенно это привело к появлению банков.
Смотрим дальше — когда все платежи стали проходить через банковские карты, то природа всего того, что стало связано с деньгами, стала (при достаточных заработках в развитой экономике) похожа на то, что было описано в утопиях — зашел в магазин, взял, что нужно, вышел.
Когда стало можно платить смартфоном — опять же, при оговорке о развитости экономики и доходах — это и вовсе стало похоже на "от каждого по способностям, каждому по потребностям".
В какой то момент продукт видоизменяется до неузнаваемости.
Даже если копнуть в самую суть, о которой вы говорите — а точно банки по-прежнему живут на разницу между ставками кредитов и депозитов?
А пресловутый "банковский мультипликатор" не нарушает этот принцип (жить на разницу)?
А история многочисленных послеледних кризисов не показывает нам, что зачастую эта разница отрицательна, и ситуация спасается докапитализацией со стороны, в тч государствами?
Эх, айти, куда ж ты котишься?
Во многом верно, и именно поэтому "хостинги, ЦОДы, системные интеграторы" стали первыми ИТ-компаниями.
Однако, когда продукты тех же банков стали моделироваться и реализовываться в виде программных продуктов с мощным бек-ендом и доступным любому неподготовленному пользователю мобильным фронтом, то и сам продукт изменился настолько, что может считаться уже ИТ-продуктом.
Если же мы по-прежнему будеми считать, что банковские продукты — не "ИТ-продукты", то давайте задумается, а являются ли продукты и услуги "хостингов, ЦОДов, системных интеграторов"?
Условно говоря, хостер предоставляет прощадку и канал для размещения информации и передачи данных — по сути, ИТ-вариант типографии и почты.
Это я к тому, что сейчас продукты традиционного, "старого" ИТ, и те же банковские продукты — в равной степени ИТ-продукты.
Ну а ваш аргумент про СБ и СБТ — от лукавого же. Деление условное по совокупности конъюнктуры — вчера разделили, сегодня объединили, завтра опять разделяют (что, в реальности, собственно, и происходит).
А суть одна — банк превратился в высокотехнологичную ИТ-компанию.
Эх, айти, куда ж ты котишься?
Подискутируем.
Автор пишет, что "хостинги, ЦОДы, разработчики ПО, производители железа, системные интеграторы" это true ИТ, а вот право банков, такси и пиццерий называться/быть ИТ в статье оспаривается.
В чем же здесь фатальная, системная ошибка, из-за которой дальше все идет кувырком как в индустрии, так и в самой статье?
Автор в перечислении true ИТ-шников где-то в середине мимоходом, походя, упомянул "разработчиков ПО".
Так вот, есть разработка — как ПО, так и железа, и более общая разработка (R&D, алгоритмы).
А есть ИТ, где применяют результаты разработки. Поначалу ИТ действительно было ограничено "хостингами, ЦОДами, системными интеграторами".
Потом, в связи с интенсивным развитием и экстенсивным расширением технологической базы (впрочем, и социальной системы), объективно ИТ-компаниями стали становиться банки, страховые компании, такси и пиццерии. И это здорово.
И что здесь важно. Есть разработка (как научная R&D, так и просто инженерный development по результатам R&D).
Разработка, как и математика — внезапно, вечна. Она была и остается разработкой с ватманом, кульманом, Си и Паскалем, и последними версиями C#/Java/Kotlin/JS/TS и прочими легионами.
И именно ее никогда не заменит AI, чтобы тут ни говорили на этот счет.
И фатальная ошибка в смешивании разработки и ИТ.
И почему то первому поколению (хостинги и прочая) ИТ автор разрешает "пристегнуться" к разработке, а тем же банкам и такси отказывает.
Но те же банки по объективным причинам (безопасность, эксклюзивный опыт) ведут собственную разработку, и они в этом смысле "более" ИТ (ну если уж мы смешиваем разработку ти ИТ), чем хостинги или системные интеграторы, которые компонуют системы из готовых программных и железных решений.
Словом, нужно просто понимать, что есть разработка, и это уникальная область, и разработчиками не могут быть все (но можно войти в ИТ, если так хочется!).
А вот дальше статья производит совсем грустное впечатление.
Начинает казаться, что это очередной заказ про якобы "перегретые" зп в ИТ/разработке, про то, что "эти ИТ-шники слишком много получают".
И хочется в очередной раз, очередному автору, посоветовать почитать про пирамиду Маслоу и воспроизводство и расширенное воспроизводство рабочей силы у Маркса. И подумать, какая зп должна быть у разработчика, чтобы удовлетворять этим критериям.
Впрочем, автор на самом деле все понимает — ведь он пишет, что в ИТ зп вовсе не так высоки (и советует "вайтишникам" призадуматься — "а оно надо?"), а когда начинает приводить примеры, где зп более-менее приличные, внезапно, это как раз и подпадает под определение разработки, а не ИТ.
Илья Якямсев: Эффективность не работает
Ох уж эти около-ИТ персонажи.
Если человек в конце 90-х верстал голые HTML и CSS, а в начале нулевых руководил широко известной в узких кругах местной веб-студией, потом закрыл ее, а на волне роста ИТ-отрасли таки удержался в ней, устроившись ПМ'ом (а по настоящему найдя себя в стенд апе), то, по большому, счету, какое отношение он может иметь к разработке и как может предметно рассуждать о ней?
Разработчики — никакая не элита, а голые короли индустрии
Так эти версии отнюдь не противоречат друг другу.
Ушла необходимость в упомянутых профессиях, образующих по сути средний класс (или ее ушли?), и все, можно вести более другую линию.
Разработчики — никакая не элита, а голые короли индустрии
Коллега, раз уж вы вспомнили и цитируете классиков ("стоимость воспроизводства рабочей силы"), то рекомендовал бы вспомнить их же и обратить внимание на стоимость расширенного воспроизводства рабочей силы.
Стоимость квадратного метра была упомянута неслучайно.
Разработчики — никакая не элита, а голые короли индустрии
Нюанс в том, что хайп вокруг новой технологии не ситуативный.
Падение реальных зп во всех секторах экономики за 30 лет, о котором вы говорите, это следствие окончания холодной войны и гонки вооружений, когда были востребовано огромное количество ученых, инженеров, рабочих, преподавателей, врачей, мастеров культуры.
К сожалению, с окончанием холодной войны и гонки вооружений (что само по себе хорошо) изменилась и ситуация с этими системообразующими в обществе профессиями.
А сейчас новый мировой тренд — биг дата в облаках.
И куют это теперь разработчики и в целом ИТ-работники. И этот тренд очень мощный и надолго. Так что хайп отнюдь не ситуативный.
Разработчики — никакая не элита, а голые короли индустрии
Похоже на очередную "заказную" статью, что "программистам слишком много платят".
А много это сколько?
Если в Москве зарплата сеньора это ± 1 квадратный метр ближе к мкад, это много или мало, с учетом, что сеньором становятся не со студенческой скамьи?
В регионах цифры другие, но пропорция примерно та же: 1 зп — 1 кв метр.
Может, это не "программистам" много платят, а мало другим профессиям, где доход == зарплата?
Почему в обществе до сих пор считается, что зарплата это что-то такое, чисто на текущие потребности?
А почему именно разработчикам платят больше — давно говорю о том, что в силу ряда особенностей, разработчика, как правило, нельзя заменить представителями смежных ролей (тестировщики, пм, аналитики, не говоря уж о несмежных профессиях), а вот разработчик в большинстве случаев заменить другую позицию сможет.
Так что, почему разработчикам и в целом в ИТ платят больше (если говорим о тех профессиях, где работают за зарплату) — потому что рынок, закон спроса и предложения.
А вот в чем с автором можно согласится, так это с тем, что из-за этой ситуации (относительно высокие доходы в сфере работы за зарплату) в индустрии наблюдается огромный наплыв тех, кто пришел сюда из-за денег, что приводит к невеселым последствиям.
PS. И да, это уже несмешно писать откровения на тему "программистам много платят, и я этим недоволен".
Когда читаешь статью, то хабр показывает похожие статьи. Вот и под этой статьей хабр показал ссылку на статью 12 или 13-го года с аналогичным названием и содержанием. И это до всех последних кризисов, когда у программистов зарплаты были не такие уж и высокие, а в ряде сфер зп были выше в разы. И все равно зарплаты программистов кому-то уже тогда не давали покоя.
Московская история профессионального выгорания — от 1996 до 2017. Путь из топ-менеджера госкорпорации в исследователи
Ну, тут все просто. Похожих примеров полно и не в ит, и большой разницы ит — не ит нет.
Обычно такие возможности всплывают во время исторических перемен, во время смены укладов в экономике (и пока большие парни в новой нише все не устаканили и не привели зарплаты работников к обычной — на еду, одежду и кредит на авто), и во время локальных всплесков типа упомянутого вами майнинга.
Итак, если вы не прирожденный бизнесмен-предприниматель-директор, который постоянно постоянно пробует, падает, снова встает и пробует, инвестирует и растет, а, если правильно понял вашу постановку — что называется, обычный человек на зарплате, на которого свалилась эта манна, то первое и главное — не "прогулять" все это, а купить столько, условно говоря, "трехкомнатных квартир", сколько получится.
Второе. Что делать дальше (чем интересным заняться, когда лавочка закроется, а, повторимся, по условиям задачи, вы не инвестор) — ну или попробовать найти интересную работу с большой зп, ну или просто работать, но в свое удовольствие, не перенапрягаясь. Возможно, сдавать лишние квартиры в аренду.
Почему так говорю — в те же 90-е и 00-е полно было примеров, когда вот такая манна сваливалась обычным людям на короткий или не очень короткий промежуток времени (а то и лет на 10).
Но большинство к этому оказывались не готовы, поэтому просто жили на широкую ногу, а когда лавочки закрывались, все заканчивалось ничем.
А могли бы хотя бы по паре квартир прикупить.
Московская история профессионального выгорания — от 1996 до 2017. Путь из топ-менеджера госкорпорации в исследователи
Вы правы, историческая конъюнктура тут получается, накладывается на протяженность активной жизни отдельно взятого человека.
Но вариативность всегда есть.
Когда я таки да, полюбил турбо паскаль, а потом настало время выбора, мне было ясно, что через 15 лет будущее за "большим" программированием (еще до появления терминов "облака", бек енда, биг даты).
Но не за радиотехникой и "железом", которое все больше становилось управляемым через контроллеры и софтовые прошивки.
И не за популярными и быстро-прибыльными для начинающих специалистов ERP-платформами.
Далее с каждым годом предвестников становилось все больше — тут и ввод в платформы разработки сетевой и распределенной парадигмы, и веб 2.0, и прочая, пока не выстрелило окончательно.
Однако! Тогда же мне было ясно что будущее и за робототехникой, причем, возможно, даже на стыке с биологией и медициной.
И таки да, посмотрите, на ютубе воспоследовавшие ролики с роботами.
Но так же было ясно и то, что выбора в эту пользу нужно уже быть в среде с высокими экономикой и материальной культурой.
А с учетом, что турбо паскаль был милее, и для него нужны лишь компьютер и голова (меньше, чем чтобы заниматься робототехникой), то выбор был очевиден.
Но это я к тому, что есть вариативность выбора. При других исходных данных (если бы за паскалем не просматривалось бы перспективы) можно было выбрать и роботов.
А за другие профессии, право, не переживайте.
В 90-е и 00-е много у кого были шансы, и поболее, чем у программистов сейчас.
Те же названные вами зарплаты в 200-300 были не редкость до кризиса 08 (при тогдашних ценах).
Да и сейчас, если кто только вступает в жизнь, при должной шустрости, все должно получиться и без программирования.
Московская история профессионального выгорания — от 1996 до 2017. Путь из топ-менеджера госкорпорации в исследователи
Ну, знаете, а в нулевые, до бума в ИТ, как раз много у кого были доходы, по покупательной способности превышающие нынешние ит-шные.
А вы прям чуть ли не вину заставляете испытывать ит-шников за их более менее адекватные доходы.
И, похожее, уровень белых доходов программистов неслучаен, т.е, неправильно говорить, что "повезло".
Сейчас вся экономика и — бери шире — дискурс жизни строится вокруг больших данных.
И нужно, чтобы это кто то ковал. Вот программисты и куют.
А вот во второй половине 20 века все вертелось вокруг НТП и гонки вооружений.
Отсюда и средний класс — ученые, инженеры, врачи, учителя, культура.
К сожалению, доход в профессии в значительной степени зависит от исторической конъюнктуры, но это вовсе не "случайно" и не "повезло". А как раз таки предопределено.
Московская история профессионального выгорания — от 1996 до 2017. Путь из топ-менеджера госкорпорации в исследователи
Хорошо герой начинал, когда нашел будущую перспективную нишу — ну вот эти линуксы, сети и тд.
Впереди большинства (за несколько лет до того, как поднялся хайп).
И мог бы успешно в этом работать, развиваться и приходить к успеху, и в наши дни, и по сей день.
Но нет — поддался давлению окружения и спекся.
Ну и кто виноват?
А также много других "звоночков" в спиче героя интервью.
И да, самая мякотка в том, что практически все, что он рассказывает про свою прежнюю сферу — в значительной мере присуще и новой, только это он не успел это понять, хотя его смена нескольких работ в новой сфере, с сопутствующими обстоятельствами, намекают.
А там, где не "то же самое", то другая крайность.
Если в прежней сфере, по словам автора, люди могли годами получать зп и просто приходить на работу, буквально ничего другого ничего не делая, то в новой ведь скрам и аджайл, и нужно каждый день рассказывать что ты сделал вчера после скрама, и сегодня до скрама.
Нетрудно заметить, что невозможно каждый день совершать отдельно стоящие реальные свершения, а это значит, либо скрам превращается либо в ритуал (а реальная работа делается параллельно, и хорошо, если делается), либо каждый день плодится не очень хороший код, никак не увязанный с архитектурой и моделью (что можно приравнять к "ничего не делается").
А также есть мнение в индустрии, что такие ритуальные отчеты сильно напоминают присядание перед малиновыми штанами, что герою как раз не нравилось в прежней сфере.
Это все к тому, что крайности, они же встречаются в одной точке и оказываются одним и тем же.
Получается, это история про человека, который в самом начале поддался давлению и совершил ошибку, затянувшуюся на 20 лет, а теперь, не успев разобраться, испытывающего восторг неофита от новой сферы.
Приготовься к введению в России социального рейтинга
Тем не менее, изначально вы говорили о "накопить на машину за полгода", а не о машине стоимостью в полугодовую зарплату.
Ничего личного, но это хороший пример, демонстрирующий популярный подход к оценке размера зарплат.
Почему то зп оценивается именно так: "ах, я за полгода могу накопить на это и на то".
Или на собеседовании/переговорах о зп может быть:
"ну, смотри, какая прибавка, вот что купить теперь на твою зп можно".
Вот только при этом почему то считается, что на желаемое тратится вся зп за некоторый период.
А стоимость жизни, а другие расходы?
Штука в том, что очень давно прошли времена, когда можно было сильно ужаться на длительный период, и скопить большую сумму с обычной зп.
Давно выросла как стоимость жизни, так и сами стандарты уровня жизни (ниже которого вы не сможете и выполнять свою работу).
В этом смысле и большие зарплаты айтишников вовсе не такие большие, как кажутся.
Например, попробуйте выдержать современный ритм с переработками и постоянным переключением контекстов по скраму/аджайлу, питаясь, как в былые времена было принято, гречкой и макаронами.
А потом можно рассказать, как за счет этого удалось сэкономить и накопить большую сумму.
«Освоить F# не сложнее, чем Entity Framework или WPF»: интервью со Скоттом Влашиным
Возможно, вы правы, и F# можно рассматривать как полноценный и главный dotnet язык.
Было бы здорово, если бы это вошло в мейнстрим.
C# в каком-то смысле слишком низкоуровневый. При всем сахаре и новом FP-стиле он по-прежнему почти один в один маппится на IL и прочие платы платформенные вещи, т.е, своего рода "ассемблер".
А нужен более высокоуровневый именно язык, и без унаследованных backward compatibility вещей.
В мире Java та же история. Более высокоуровневым языком для JVM мог бы стать Kotlin, но перспективы в части back end пока не ясны.
«Освоить F# не сложнее, чем Entity Framework или WPF»: интервью со Скоттом Влашиным
Поддерживаю любые F#-начинания, но называться dotnet-разработчиком это, скорее, про понимание основных концепций dotnet ("что это такое" в целом, GC, CLR, CTS, IL) и основных встроенных и сторонних библиотек для работы с БЛ, сетью.
И, конечно, отличное знание языка и понимание, как он маппится на те же CLR, CTS, IL.
Лучше, конечно, больше чем один язык.
Но F# это скорее, все-таки про функциональное программирование. Хотя тут очень важно и понимание, как он маппится на механизмы dotnet.
Другое дело, актуальный разработчик должен давно использовать не только linq, но и придти к другим фунциональным парадигмам в использовании C#.
И тут совершенно логичным выглядит как минимум интерес к F#. А вот дальше сложнее — с вакансиями и реальным его использованием в проектах.
Одна из основных мыслей статьи — создание на F# чисто модели, и вынос ввода-вывода на периферийный контур — очень импонирует.