То есть задача (и профессия) вроде бы одна, но человек который её решает может быть как пешим курьером, так и капитаном корабля массой в десятки тысяч тонн.
И размер компании на сложность инфраструктуры практически не влияет. В небольшой ИТ-компании инфраструктура может быть намного более "тяжелой" и сложной, чем в крупной компании не связанной с ИТ.
Как следствие грубо (потому что важных параметров больше) инженера в ИТ можно позиционировать по 3-м "измерениям":
Сектор работы (грубо говоря профессию врача);
Профессиональный уровень (это как уровень больницы);
Техническая сложность проекта.
Вторая - как устроено управление в ИТ и какие цели у сторон.
В сфере ИТ ключевыми фигурами являются (но не всегда это конкретный человек):
Заказчик (он же владелец продукта, он же Project Owner). Это человек в интересах которого разрабатывается проект. Если проект бесплатный и открытый, то PO является сам разработчик, если проект коммерческий для широкого рынка, то в качестве PO выступает собственник компании разработчика или руководитель отдела маркетинга.
Руководитель направления (он же РН, начальник ИТ, начальник отдела разработки, начальник отдела поддержки инфраструктуры и т.п.). По сути это руководитель отдела, основная задача которого административная. Хороший управленец, даже без знаний ИТ, вполне успешно может работать на этой должности.
Руководитель проекта (он же Project Manager, или ПМ). Это человек который управляет проектом. То есть некоторой последовательностью действий, которые нацелены на результат. Хороший управленец, даже без знаний ИТ, вполне успешно может работать на этой должности.
Технический директор (Техдир). Это человек, который управляет техническим и программным набором инструментов в компании. Выбор того или иного решения это далеко не всегда "А лучше для Б", есть нюансы по стоимости лицензий, совместимости компонентов и т.д. и т.п. Это должность, которая требует как навыков управленца, так и как минимум среднего понимания в зоне ответственности.
Руководитель группа (он же РГ, TeamLead). Это человек который управляет работой инженеров-исполнителей, а именно - распределяет задачи и контролирует их выполнение, соблюдение сроков закрытия задач. Это должность так же требует как навыков управленца, так и как минимум среднего понимания в зоне ответственности. Грубо говоря этот человек должен во-первых понимать, что человека с проблемой глаза надо отправить к окулисту, а не к проктологу, во-вторых он должен понимать кто какую нагрузку держит и не перегружать, а так же следить за отсутствием простоев. Помимо этого выявлять желание сменить работу и т.п.
Архитектор решения (он же просто Архитектор). Это технический специалист очень высокой квалификации. В ИТ одна и та же задача может быть решена разными способами. Архитектор, это человек который знает максимально возможное количество путей решения задач в своей сфере, а так же преимущества и недостатки каждого из них.
Аналитик. Это человек, который по сути просто переводит с языка бизнеса на язык инженеров.
Инженер-исполнитель. Это инженер, который непосредственно решает задачи.
Пользователь. Это тот то пользуется продуктом.
Третья - как компания Apple строит свою стратегию продаж.
Стив Джобс (как и Билл Гейтс, Илон Маск и т.п.) это человек, который сочетает в себе два качества, которые позволили ему и ему подобным стать теми, кем они стали.
То, что делает "служба безопасности сбербанка" индивидуально и по телефону, они делают с гигантских сцен на массовую аудиторию.
Умение пройти по краю, когда мошенничество фактически есть, а юридически или совсем не доказуемо или настолько сложно доказуемо, что за это дело никто не берётся.
Как следствие из пунктов выше Apple (как впрочем и Microsoft) делает такой финт ушами - нанимается 100500 блогеров, которые представляются профессионалами и рассказывают "какой хороший продукт Х". По факту это - "говорящие головы", которые в лучшем случае выучили терминологию и болтаются на уровне каких-нибудь эникеев. По сути - инфоцыгане в ИТ.
Пользователь (потребитель) не имеет профессиональных навыков, которые позволяют отличить профессионала в ИТ от такой вот "говорящие головы" от профессионалов. Как следствие они просто верят этим "говорящим головам" в т.ч. тем, кто вещает с больших сцен. Количество профессионалов в ИТ - ничтожная доля от всего общества. 0,1 - 0,5 % и на голос такого профессионала приходятся десятки, а то и сотни "говорящих голов" и как следствие их мнение просто давится количественно.
Здесь можно привести аналогию, как на мнение 1 врача есть 100 мнений гомеопатов.
Жертвы гомеопатии тоже пытаются доказать каждому встречному и поперечному, что она - работает. Фактически же...
Выгода от этого всего - прямая и вполне материальная. Почти весь доход компаний таких лиц напрямую связан с количеством людей, которых убедили "говорящие головы".
Ну и общий вывод, от которого у огрызкофилов пригорает:
Давайте теперь обобщим написанное выше на аллегории строительства дома и рассмотрим подробно всю проблематику ситуации. Цифры абстрактные, алгоритм упрощён, всё чисто для понимания масштабов и процессов.
Есть Заказчик, который хочет построить дом площадью 100 кв.м. и имеет бюджет в 10 млн. руб. Он находит строительную компанию, где с РН и ПМ предварительно обсуждают "за 10 млн. руб. построите дом в 100 кв. м"? После сбора всех начальных данных вопрос передаётся Архитектору, который этот вопрос переводит в практическую плоскость из ряда вариантов решения (проектов дома 100 кв.м.). Эти варианты проверяет Техдир (по сути Главный инженер). Его роль - указать на организационно-правовые и финансовые проблемы проектов. Например, золотой унитаз - круто, но в бюджет не вписывается. Цемент марки 750 круто, но у нас не продаётся. По сути Техдир спускает Архитектора на землю ;-) После проверка РН и ПМ идут к заказчику и согласовывают с ним по какому проекту будут строить дом. Заказчик утверждает проект и бюджет. РН уходит решать свои задачи, а ПМу выделяется РГ (по сути прораб) и команда инженеров для работы над проектом. Аналитик, как переводчик, переводит договорённости с заказчиком на язык исполнителей. Задача ПМ - отвечать за коммуникацию с Заказчиком, РГ обеспечивает, чтобы строители (инженеры-исполнители) делали всё строго по проекту. И команда строит дом, который потом сдаёт РГ, который сдаёт его ПМ, а ПМ с РН сдают "дом" Заказчику. Единственный кто всё оплачивает - Заказчик. Заказчик платит за конкретный оговоренный результат. Безусловно, что вне рабочего времени человек может делать что угодно на чём угодно (в рамках закона), но в рабочее время сотрудник обязан выполнять задачи, которые ему поручили. Ему за это зарплату платят.
Реальную ситуацию в ИТ прекрасно описывает следующая картинка:
Вычислительная техника, такая как сервер, ПК, ноутбук - инструмент сотрудника. Например, это перфоратор. Как и у любого инструмента у него есть своя сфера применения т.е. задачи, которые он решает эффективно, под которые он "заточен". Основная задача перфоратора - создание отверстий в бетонных и кирпичных стенах. Помимо этого он может мешать раствор (но хуже бетономешалки), штробить стены (но хуже штробореза). С "творческим подходом" им можно даже забивать гвозди!
Но весь объём строительно-монтажных работ он сделать не может!
И вот тут мы плавно переходим к тому, почему профессионалы в ИТ считают "специалистов" с маками
прошлый пост дал очень много показательных примеров "логики" огрызкофилов (их в профессиональной среде вообще по другому называют, это очень мягкий термин).
Итак основные черты типичного огрызкофила (курсивом аллегория)... Это далеко не все, а ТОП-5:
Полное игнорирование других инструментов (всю работу на стройке можно сделать перфоратором).
Полное игнорирование других параметров работы (любой груз можно доставить на самокате)
Мак - святое, если там что-то не работает то так и надо (если не можешь 10 куб. м. бетона перфоратором за пару часов намешать, то значит не умеешь работать)
Полное игнорирование требований заказчика, руководителя направления, руководителя проекта и т.п. (если я не могу сделать это перфоратором, то это не нужно)
Полное игнорирование требований эффективности работы (буду в разы дольше мешать раствор перфоратором и пофиг что рядом бетономешалка стоит)
Примеры ситуаций к чему это приводит:
Задача - обслуживание оборудования. Драйвера есть только под Windows. Заявление: пусть заказчик меняет оборудование на Мак-совместимое, такое есть. Есть. Стоит 6 млн. руб. Дважды спросили про выполнение задачи на Win-ноуте. Дважды при других сотрудниках отказал. Дали выбор - пишешь 2 объяснительные по отказу выполнения должностных обязанностей, потом приказы на нарушение и 3 раз на увольнение. Или сразу пиши на увольнение. Написал на увольнение сразу.
Задача - доработка веб-приложения. Ввиду того, что тестовый контур на Маке не работал сотрудник работал на отдельном выделенном сервере. Неоднократно были ситуации, когда: у меня на Маке всё работает, это у вас сервера не правильные. В конце концов просто заебал. Тот же сценарий.
Задача - доработка веб-приложения (другого). Мак не поддерживает один из компонентов. Задачу передать некому. Ответ: не могу сделать на Маке, значит пусть делает кто-то другой. Тот же сценарий.
Это тоже ТОП, дааааалеко не все случаи. Для тех, кто считает, что примеры выше "взяты из головы"... Ну давайте почитаем, что писали огрызкофилы под прошлым постом (тоже ТОП, иначе надо не один пост писать):
ИП - исходный пост, ЦП - цитата исходного поста, ОФ - комментарий огрызкофила
ИП> разработка под огрызки в т.ч. веб-дизайн,
ЦП> который должен нормально отображаться в Safari
ОФ> А другие браузеры религия не позволяет установить?
Заказчик платит за интерфейс "который должен нормально отображаться в Safari". Огрызкофил предлагает установить другой браузер. Чтобы что? Какая будет репутация у компании, которой заплатили за одно, а она сделала другое?
ЦП> работа с небольшими датасетами и нейронками;
ОФ> Какими небольшими? Так то за 40к любой вин пк НОВЫЙ будет иметь производительность тупо ниже.
Архитектура SoC не позволяет нарастить ОЗУ. До того как цены на ОЗУ начали измеряться в Макбуках можно было брать миниПК за 17 - 20к ставить на них дополнительные 2 Тб NVMe и 64 Гб ОЗУ, после чего использовать и под нейронки (llama.cpp) и как сервера для расчётов. По сумме в 40к вполне укладывались. То есть идёт сравнение не с лучшим, а худщим вариантом.
ЦП> раскладка клавиатуры в части хоткеев не эргономична. Сотрудники с туннельным синдромом практически моментально чувствовали обострение.
Туннельный синдром - заболевание и серьёзное (сдавливание нерва, сперва просто боль, потом как минимум временный паралич кисти). Грубо говоря ОФ предполагает, что для того, чтобы вылечить сломанный позвоночник (а работа с клавиатурой при "тунельке" вызывает по сути тот же эффект паралича), достаточно поменять привычки.
ЦП> ввиду SoC-архитектуры: во-первых нет возможности апгрейда т.е. нельзя, например, нарастить размер ОЗУ, во-вторых всё устройство является по сути монолитом т.е. при поломках ломается сразу всё, что повышает стоимость ремонта кратно.
ОФ> Ты знал на что шел. 100% буков не важно маки или винбуки soc сейчас такие.
То, что мы знали на что шли - факт. И? Из серии "женщина сама виновата, что её изнасиловали" или "ребёнок сам виноват что его дикие собаки погрызли".
ЦП> ввиду закрытой программной архитектуры организация резервного копирования менее эффективная.
ОФ> Чегооо? У тебя есть штатная утилита time machine. Берешь любой внешний хард или ссд, подкидываешь его по сата 3 - туре-с и всё. У тебя идет постоянное резервное копирование.
Такое заявление в инфраструктурном отделе является основанием для увольнения. Потому что Time machine не является нормальным средством резервного копирования. Суть резервной копии в том, что при выходе из строя основной машины бэкап можно развернуть как каталог и извлечь из него данные, которые нужны здесь и сейчас. При этом критично, что бэкап должен разворачиваться ПОД ЛЮБОЙ ОС. Это связано с тем, что причиной может служить сетевая атака, которая выбивает все машины одного типа. Наивно верящим, что под айфоны и маки вирусов нет, то ещё в 2011-м счёт шел на тысячи. Свежачёк от августа этого года (https://www.securitylab.ru/news/566884.php). Time machine позволяет восстановиться, но только на Мак. То есть нужно или покупать 1 устройство про запас или ждать пока оно придёт. При этом ввиду постоянного подключения диска шифровальщик может спокойно угробить бэкап. То есть Time machine далеко не полностью соответствует требованиям к бэкапам.
А вот с системами резервного копирования (по крайне мере профессиональными) под Win и Lin таких проблем нет. Сдох у специалиста комп во время решения срочной задачи - вытащили из бэкапа каталог и отдали в работу другому, пока инфраструктурщики готовят замену.
ЦП> есть существенные проблемы совместимости с периферией в т.ч. с USB-хабами, KVM и HDMI-переходниками.
ОФ> Потому что не надо брать самое дешевое говно с wb\ozon
Только во влажных фантазиях ОФ "если не работает с Маком, значит дешевое говно". Есть проверенное годами и не дешевое оборудование которое работает со всей остальной инфраструктурой. От смартфонов (это про USB-хабы) до серверов стоимостью с квартиру в новостройке. Кроме Маков. Особенно забавно, что "не совместимым" может быть стоечная KVM, которая стоит дороже этого самого Мака... Нет, просто задача совместимости со всей номенклатурой действительно относится к сложным, а дизайнеры в Apple получают намного больше инженеров, поэтому у тех лапки.
ОФ> Оставлю и своё "фе" пожалуй. m1 air 13,3 16/512 куплен новым в 2022, для работы (ямлописательство и всё такое).
ЦП> - разработка программного кода. Преимуществ перед ноутбуком на Linux не выявлено;
ОФ> Стационарно - скорее соглашусь. А когда тебе 7 часов по самолётам/аэропортам шарахаться (Нвосиб-Хабаровск, велкам ту РФ, - через Москву лети, мальчик) - они, таки, есть. Автономность оч. хорошая, как и вес и габариты. Лично у меня, по сравнению с thinkpad что до этого был - еще и глаза меньше устают, экран приятный.
Очень интересно какой % рабочего времени разработчик (о чём он писал выше) шарахается 7 часов по самолётам/аэропортам и самое главное почему... Суть вопроса в том, что если эта ситуация разовая, то ссылаться на неё нет смысла - исключения не формируют правила. Если постоянная, то какой компании нужен программист, который не вылезает из аэропортов и самолётов?
ЦП> работа с контейнерами и виртуализацией. Провал. Во-первых нет ряда необходимых Docker-образов
ОФ> arm64 или эмуляция и всё работает. Костыль, но не больший чем условный wsl в windows
Стандартное требование в серьёзной работе - работать на том, что является целевой системой. Потому что НЕ ВСЁ работает. Когда сотрудник работает на целевой системе и тестирует сделанное, то отправленный на сервер результат в 99% случаев не требуется дорабатывать. Если АРМ инженера и целевая система имеют разные ОС, то наоборот - очень часто есть те или иные проблемы. Хуже всего, когда эти проблемы всплывают через много-много лет...
ЦП> во-вторых код отправленный на прод имел на нём ошибки, которые не воспроизводились на Маке.
ОФ> Ожидаемо. дев и препрод среды не просто так придумали.
То есть для работы на Маках нужно помимо него иметь ещё и второе устройство... Которое самостоятельно может решать те же задачи. Это как купить эвакуатор для машины, затянуть в кузов вторую и кататься на эвакуаторе. Можно? Можно. А зачем?
ЦП> - скриптинг. Провал. Не смотря на то, что вроде бы утилиты те же, но не 100%. Скрипты прекрасно работающие на Маках на Linux-проде довольно часто имели проблемы.
ОФ> По умолчанию на маках zsh, а не bash. Они разные. Что мешает запустить баш и писать из под него - непонятно. Зачем писать под интерпретатор отличный от целевого - тоже непонятно. С питоном проблем не наблюдалось. В целом лить на прод с машины разраба - очень плохая практика, не надо так.
То есть вывод команды df-h внизу абсолютно идентичный и у меня глаза в ... или кто-то звиздит?
Если вывод конвейером передать в awk '{ print $6 }' результат будет идентичным?
zsh и bash - оболочки, которые есть и на Linux тоже. Русским языком в исходном посте было написано, что некоторые утилиты имеют разный вывод. Да и ключи запуска тоже. Про пути в файловой системе вообще молчу.
Ну и "мосек" никто не отменял...
ОФ> Моё личное впечатление от вашего псто - "ниасилил". Как и всякий инструмент - макось - для эффективного использования нужно для начала изучить.
ОФ> Поддерживаю, сам выпал когда написал про резервное копирование, стало всё ясно, что «ниасилил»
ОФ> Просто руки были заточены не под MacOS или индусы сотрудники
Особенно порадовала эта моська:
ОФ> р&д - исследования и разработка. что ты там исследовал, лаборант карманный?
Которая своим комментарием показывает почему отстранение от R&D в ИТ любителей яблочных решений не просто оправдано, а необходимо.
В нормальных ИТ-компаниях перед R&D ставятся задачи:
Разработка новых решений (продуктов).
Сравнительный анализ вариантов решения задач.
Получение практических результатов в рамках управления рисками.
Публикации по теме в основном касаются п. 1, но только этим работа не ограничивается. Почитать об R&D можно например здесь:
ИТ-решения не существуют в вакууме. Это продукт, который стоит реальных денег. Компании, которые умеют считать деньги, понимают, что грамотно организованные R&D позволяют экономить большие деньги.
Например, для приложения нужна база данных. Любое "так возьми Х" будет идиотизмом. Потому что:
Разные размеры БД, хранящиеся в ней данные;
Разные нормальные формы и структуры данных;
Разная количественная нагрузка (количество запросов в минуту);
Разная качественная нагрузка (преобладание тех или иных вопросов);
Разные требования по отказоустойчивости, потери данных и времени восстановления
Помимо этого каждая БД имеет свои особенности на разных ОС и файловых системах. В простых случаях этим можно пренебречь, но далеко не всегда. Если БД достаточно крупная, то неправильный выбор БД может стоить сотни тысяч рублей в месяц всё время существования проекта.
Как итог проводится R&D которая позволяет выявить:
Сколько физических или виртуальных и каких ресурсов надо купить (CPU, RAM, дисковой подсистемы) для каждого варианта;
Какой должна быть конфигурация решения, для максимального соответствия задачам (параметры конфиг-файлов и т.п.);
Выявить хоть какие-то риски эксплуатации и учесть их в работе;
Сформировать документацию по развёртыванию, резервированию, обслуживанию решения. Это очень сильно экономит время и деньги при авариях. В идеале вообще их не допускает;
Понять сколько каждое решение потребует специалистов и какими навыками они должны обладать.
На основании данных R&D-исследований в т.ч. формируются бюджеты проектов.
R&D требует во-первых беспристрастности (которой у огрызкофилов нет по определению), а во-вторых высокой квалификации и знаний матчасти. Насколько с такими задачами могут справиться сотрудники использующие яблочную технику думаю понятно из цитат их сообщений выше. Никак.
Маки не полностью бесполезные. Есть задачи, где их нужно использовать, есть задачи где они один из вариантов использования, а есть задачи где сотрудник с Маком может быть только некомпетентным идиотом.
Аллегория из строительства: сотруднику нужен перфоратор, чтобы сверлить отверстия в бетоне и кирпиче, он может резать не сильно длинные штробы, может замешивать небольшие объёмы раствора, но, например, копать фундамент перфоратором - идиотизм.
Это универсальный принцип, который касается не только вопроса огрызкофилов. ИТ оплачивает заказчик. Как следствие или сотрудник выбирает решение задачи заказчика из адекватных вариантов, или его необходимо увольнять.
P.S. Я не огрызконенавистник. Огрызкофилами в посте называются не все собственники Маков, а только те, кто исповедует "Мак любой ценой".
P.P.S. Больше всего работаю в Linux (разные дистрибутивы, больше 5), помимо этого в Windows, FreeBSD, OpenWRT, с недавнего времени есть задачи для MacOS. Не считаю, что какая-то ОС лучше, а какая-то хуже. Есть подходящие под конкретную задачу инструменты и не подходящие.
