Комментарии 69
ну, не вы первый, кто это отмечает:
книга Бытия 11:1-9
с чего началось: один язык
итог: много языков ;)
так что это происходит не сейчас а уже очень давно :)
но, кстати, есть решение - использовать BCI чтобы если надо - можно было напрямую обратиться к "накопленному всеми человеками знанию".
(там правда такой божественный канал откроет новые проблемы, но это уже предки будут их решать :) )
По моему скромному - даже в IT этот этап давно уже пройден. В той же самой середине (окей, второй половине) 90-х уже явно наметилось разделение между теми, кто программирует строго на языках высокого уровня, и теми, кто может спуститься до уровня "железа".
уже во времена Бэббиджа было разделение на тех, кто придумывает и делает (ну или хотя бы пытается делать) счетные машины и на тех, кто придумывает и записывает исключительно программы для машин :)
С одной стороны, точка зрения валидная) С другой - в те времена один человек в голове мог удержать и механическую инженерию этих тысяч шестерёнок, и логические абстракции, которые эти шестерёнки двигали. Разделяли, скорее, по вкусу, нежели чем по необходимости.
В условном 1997 структура произвольного процессора с точностью до вентиля (в физические дебри пролупроводников даже не лезу), архитектура произвольного же клиент-серверного приложения и, скажем, тонкости пространственного аудио с 3D рендерингом в одной голове шансов разместиться шансов мало имеют. А это - всё IT.
можно просто посчитать количество IT-специальностей. Думаю счет уже на тысячи идет
Несомненно, хотя в 1997 году существовали люди, которые до математических тонкостей порядка опознания сопроцессора по энному знаку после запятой могли опознавать разницу между FPU 80387, Cyrix, IIT и еще десятком всех возможных моделей, которые тогда только существовали, и "под Weitek" очень даже могли что-то очень хитрое математическое закодить. Но как же быстро такие изощренные навыки забываются, теряются и утрачивают актуальность в IT
Генералисты есть, просто они уже ушли на другой уровень, и вы с ними не пересекаетесь.
Простите, а что такое "генералисты" ? Сорри, ват из генералисты, майби ю мент дженералисты?
Зачем Вам это?
В стартапе не важно какая БД и язык, главное чтобы взлетело. А потом по ходу движения уже придут спецы по БД, оттюнят, поставят нужные ОС вместо дебианов или пропатчат БД чтоб память не текла.
К тому же проект это не нерушимое легаси, вчера было оптимально взять одно, а сегодня добавились новые функции и оптимально уже другое.
Круто конечно прийти на берег, собрать все нужное и пустится в плавание, но кто-то уже плывет, а ты все проверяешь наличие запасных ботинок у матросов.
Я согласен с вашим основным тезисом, что в стартапе важно быстро и дешево запуститься, сделать что-то (пусть и неэффективно, кривовато) и уже потом постепенно решить все "кривости". Но я часто делаю свои собственные хобби-проекты (технически можно воспринимать их как стартапные проекты) и вот две проблемы с которыми я сталкивался (из-за нехватки этого общего опыта, кругозора, эрудиции):
Часть проекта, на которую тратишь время разработки - оказывается, давно уже реализована, можно взять тот проект и использовать. Но я о нем даже и не слышал, когда начинал свой проект.
Есть риск, что сам проект, который делаешь - уже сделан, просто ты про это не знал, не все проекты на гитхабе посмотрел. Потом вкладываешь время, силы, деньги, получается готовый проект, который никому не нужен, потому что уже есть более развитый и известный.
Есть риск, что проект-то хороший, но сама тема "умирает". Все равно, что выпускать сейчас лучшие генераторы для ВАЗ 2101. Товар хороший, но потребителей уже почти не осталось, а через 5 лет не будет совсем. Делаешь что-то для админства и хостинга на дедиках - а все уже на VPS перешли. Делаешь что-то для VPS - а все уже просто выкладывают в облака или на JAMstack ушли.
В облака "все" не уйдут из-за их заградительно-высокой цены для среднего проекта. Я считал, у меня выходило 6-8 месяцев за 50 тысяч рублей (получил грант) в облаке... Для сравнения, на классической виртуалке у меня этих же 50 тысяч хватит на 2 года.
Я думал наоборот мелким и средним ещё нормально, а вот большим компаниям уже дорого, например сравнить облако 100 миллионов в год и 100 миллионов чтобы нанять админов, купить серверов и поставить в ЦОД на год, вроде разницы в первый год нет, но на второй год первый вариант также 100 миллионов, а второй всего 20
Облака, на мой взгляд, дают уникальную возможность быстрого масштабирования. Но я вижу для нее всего два применения
1) "Черная пятница" (с этим в самом деле столкнулся, и проблема была актуальна) - сервер вполне нормально справляется, держит магазин, обрабатывает продажи, но в Ч.П. посетителей и продаж так много, что он уже не вытягивает (в результате - куча продаж не случилось, потеряли, наверное, больше, чем если бы в пять раз больше за сервер(а) платили)
2) Быстрый успех стартапа. Делаешь какой-нибудь свой нетфликс, о котором знаешь ты, твой брат и твоя собака. Потом проект оказывается успешным, может быть инвестор появляется, и нужно за два дня проект "грузоподъемностью" в три человека, чтобы выдержал уже 30 000 000. Причем инвестор только тогда и найдется, когда проект сможет так вырасти (ему рост проекта в 10 раз до 30 человек не интересен).
С чисто коммерческим стартапом, да, стараются побыстрее запустится использую проверенные полуфабрикаты. Но если стартап сам по себе инновационный, типо новый блокчейн или что-то подобное. То быстро и дешево запустится там просто не на чем еще. Свой хобби проект делать на протухших решениях вообще смысла нет. Надеяться что хобби проект принесет миллионы, это примерно как надеятся выйграть в лотерею миллионы. Хобби проект, это скорее самообразование. А какой смысл учиться на овне мамонта, если ты конечно не археолог?)
Очень похоже на парадигму "держи пет проект, когда растешь в навыках"
Вроде и изобретаешь велосипед, но сам к нему приходишь в рамках математической шутки "если мысли ограничены, значит они сходятся"
Были времена, когда fail2ban НЕ существовал и я пилил на коленке bash-скрипт для занесения нарушителей в чёрный список с соответствующими правилами фаервола... Потом я узнал, что есть такой проект, но переделывать рабочие скрипты не стал. И таких тем море, НО иногда в современной конторе ВДРУГ всплывают задачи, которые для меня 10-15 лет назад были обыденностью, но о которых мои 30ти летние коллеги ничего не знают!!!(например Moxa USB-COM переходники и их работа под Linux для спец. оборудования - под виндами у них работало, а в РедОС возникли проблемы - пришлось объяснять ТП РедОС что мне от этих железок нужно и искать контакты конторы, которая может дать железки на тест для устранения проблем совместимости)
А потом по ходу движения уже придут спецы
Увы, как зачастую показывает практика, спецы не придут.
Потому что вслед за быстрым взлетом продукта бизнес начинает требовать его немедленного расширения, чтобы отчитаться перед акционерами и успеть заработать самим.
На доводку до ума, как всегда, не хватает времени.
Продолжая вашу метафору с кораблем, он поплывет быстро, но недалеко.
«Что наспех делается — недолго длится» (с)
Мудрость, заложенная в детской сказке про Ниф-Нифа, Нуф-Нуфа и Наф-Нафа, как была, так и осталась.
Ну я слабо верю что на старте проекта найдется человек который предскажет развитие проекта в нужную сторону, а также то что в нужную сторону разовьются технологии через несколько лет.
Все равно будут грабли легаси, по которым проект пробежит и от которых придется избавляться рано или поздно. Тут основная задача иметь команду которая сможет переписывать бэкенд на ходу, не теряя пользователей, менять бд с mysql на монго и обратно и тд. Только с ней можно добиться движения вперед по актуальным технологиям, а не надеяться на какого-то премудрого деда, который однажды при царе горохе сказал какую архитектуру проекта выбрать.
По поводу Блюд проблемы из пальца высосана. Блок это про хранение данных на длительный срок. Так что никаких новомодных проектов которые умрут через год, и в которых багов полно рассматривать нельзя. Так что вам в классический RDBMS. Там MaSql/PostgreSQL по большому счету без разницы и дело вкуса. Берите то с чем работать умеете. Nobody was never fired for choosing PostgreSQL :)
Ну я б себя не то чтоб уволил, но ласково отшлепал бы, за то, что для задачи хранения результатов мониторинга выбрал mysql (читай postgresql), хотя prometheus или другие time-series были бы удобнее. Среди них (time-series) вполне есть выбор взрослых, популярных и достаточно старых проектов, которые не умрут. Но я просто о них не знал в то время.
Аналогия с узкой специализацией врачей мне кажется не полностью релевантна.
В отличие от стоматолога, который врядли вырежет аппендицит бормашиной, любой узконаправленный DBA по какой-то одной платформе решит вашу бекэндовую задачу. Да даже не DBA... если у вас не самый сложный стартап, то, хорошо зная свой любимый инструмент, очередь сообщений можно сделать на чём угодно, хоть на рэббите, хоть на монге, да хоть на mssql... безусловно не максимально эффективно, если бы этот человек знал каждый продукт на 100% и мог выбрать из них наиболее подходящий под специфические требования очереди, а не только один и применял его везде... но при этом всё равно достаточно! эффективно, чтобы стартап работал.
Возможности большинства продуктов стали такие широкие, что шутка про OS Nero Burning ROM уже давно не шутка, и не прям критично критичную задачу на тысячи запросов в минуту можно реализовать в любом из них, так и не достигнув лимита производительности, ибо его запас у одного инструмента всё равно останется х10, а у более подходящего осталось бы х100. А на замечание, что "но ведь, если всё выстрелит, то х10 закончится быстрее, чем х100" - смотрим следующий пункт...
Ну а если у вас не стартап, то вы вполне можете позволить себе держать 10 DBA по каждому продукту и консультироваться с ними при первичном планировании архитектуры...
Сейчас на собесах никого практически не интересует не релевантный с вакансией опыт. Например будь у тебя хоть CCNP, на вакансии не сетевика всем плевать на это. На вакансии Devops инженера, зачастую плевать на твои познания работы с реальным железом и знания языков программирования. Да, ты должен уметь в bash, наверное в go, но то что ты знаешь условные python или java или можешь собрать кластер на коленке, чаще всего пофиг. Ты знаешь VMware, Hyper-V, KVM? Сори, но у нас тут как бы AWS or GCP или Яндекс.Cloud. Приходишь на другой собес, на похожую вакансию, там ООП им подавай, базовых знаний того же python уже недостаточно. Тот же Kuber сейчас всё чаще стал появляться в требованиях даже у джунов. Если раньше, у тех же админов был стандартный набор требований, то теперь всё сугубо индивидуально, зависит от конкретной вакансии. Узкий профиль специалистов в принципе это неплохо, вместе с поколением ЕГЭ всё пришло).
А чем это отличается от любой другой области знаний? IT просто в специфическом положении (было) т.к. область новая, но любые другие более старые как-то с этим справляются.
Например вот строительство - разумеется нет ни одного человека в мире, который знает как и может технически построить какой-нибудь БЦ или небоскреб в одно лицо, даже если у него будет доступ к любым материалам, машинам и большое количество рабочих необученных рабочих рук. А лет 300 назад главный архитектор, зодчий или что-то подобное вполне мог в теории это сделать. А сейчас есть большая команда с каким-нибудь главным архитектором во главе, которая только проектировать здание будет, а потом еще тысячи разных специалистов которые будут это воплощать в жизнь (не говоря уже о производствах, которые будут что-то там делать по заказу)
Про медицину - на самом деле все не так плохо. Во-первых есть целая специальность "терапевт", который как раз и есть тот самый профессиональный генералист. И нормальный терапевт это не бабушка выписывающая аспирин в гос. клинике, а хорошо подготовленный (и постоянно учащийся, как IT-шники) человек, основная работа которого "первичный траблшутинг" засбоившего организма. С передачей профильному специалисту после первичной диагностики, если нужно копаться дальше.
Во-вторых врачей учат как раз как "генералистов", в отличие от front-ender'ов после полугодовых курсов, умеющих только в свой JS/React и не знающих ничего больше. У них 4 что ли года общего высшего образования, универсального, а только потом специализация - еще несколько.
Касательно IT будет точно так же как везде: есть специалисты более общего профиля, обычно сейчас это называется какими-то вариациями на тему "архитектора" (software, solution, cloud, enterprise, подставь-по-вкусу), есть более узкие (те же самые архитекторы, но в более узкой области, например networking или security), и уже узкие специалисты в чем-то (front, back, devops, ml, sre, dba, etc).
Знать и уметь "все" - невозможно. На самом деле и 20 лет назад в IT это было невозможно. Вряд ли у вас есть опыт разработки на каком-нибудь COBOLе, навыки внедрения большого железа IBM, настройки SAP того времени и т.д. Просто спектр того, что мог исхитриться уметь хорошо один человек был пошире. Ну мир не стоит на месте.. так что продолжаем бежать, что бы хотя бы не откатываться назад и учиться каждый день ))
А чем это отличается от любой другой области знаний?
Быстротечностью. Ни одна другая область знаний не развивается с такой гигантской скоростью, как IT.
"Едва мы не успели освоить одно, как тут же не успели освоить другое" )
Я бы иначе даже подметил отличие. Агрономы изучают редиску, врачи - людей, биологи зверей, механики - движения тел. В общем, во всех этих темах предмет исследования достаточно ограничен и конечен. И, наверное, человечество к нему асимптотически приближается. Какой-нибудь биолог может сделать неожиданное открытие про подкустового выползня, но в целом это мало на что повлияет. В IT мы изучаем то, что мы сами наделали, и чем дальше в лес - тем больше делаем. Наверное, как и в математике, не знаю - есть ли там какой-то гипотетический конец исследованиям. Мы сами себе без конца создаем темы для изучения.
У меня как раз опыт в Linux 20+ лет - работал только в консоли, винду почти не трогал. В рамках конторы, в которой я 20 лет проработал этого хватало. Сменил работу и узнал овердох@я нового. И к сожалению обнаружил, что поколение 30 летних - писец какое поверхностное, они не знают элементарных азов в куче направлений, но пытаются гнуть пальцы "знанием" кубернетисов и прочей новомодной херни.... И они не пытаются разбираться в проблемах базового уровня. Так что для "генералистов" найдётся работа - подтирать носы и менять подгузники молодым узким спецам.
А были ли настоящие генералисты? Или это очень короткий период и специализация нарастала с прогрессией, просто её не сразу заметили?)
Я пожалуй не соглашусь - да количество всех сущностей IT мира неуклонно растет. Но и в 90-х из было дофига, просто тот кусочек который видели мы в РФ был действительно невелик. Просто не все до нас успело донестись.
В чем спасение, почему мы до сих пор не померли. Возьму привер с БД и дебианом. Сегодняшний генералист ответит - ну возьмите постгрес, он уже старый, надежнй, развивается, есть для всего и без багов. А те 30% возможного выигрыша, во первых если у вас фамилия не Маск и вы не запускаете корабль в космос (BTW панель управления в драконе на ноде!!!), то не факт что вы эти 30% заметите, а если заметите, то вот так митигируете. Да будет стоить на $10,000 больше на хотинге в год, но использование вот этой байды вам обойдется в $100,000+ на разработку. И не факт, что оно через 3 года не загнется.
Окно постоянно сдвигается, когда-то тот кто не умел паять IT-шником не считался. Сейчас можно не знать С++ и быть очень полезным специалистом широкого профиля.
Десть есть фундаментальные вещи, например что такое race condition и как правильно думать, чтобы его не было. Но таких вещей не так много и они как раз выучиваются за разумный срок это раз. Реально количество коитически важных штроким масссам для программирования вещей сокращается, это два.
Движуха за "Т-специалистов"?
Концептуальный вопрос, можно ли продолжать так же все усложнять или мы упремся в потолок сложности?
И второй вопрос, можно ли, используя текущие знания и умения создать по настоящему эффективную выборку, позволяющую новым студентам стать на плечи гигантов, не пытаясь поднять их груз? Не пытаться разобрать плохие подходы, использовать прямые пути там, где уже спрямили дороги, не учить гончарному делу, но литью по пластику.
Но да, размышление интересное.
Хочу отметить так же, что многие вещи в бурном технологическом потоке будут унесены историей, в то время как многие старые технологии - не динозавры, но акулы. Они живут и сейчас и по прежнему являются эффективными.
Нормальный путь, как и в науке, в средние века учёный был на все руки во всех областях, которые ещё не сформировались. Сейчас узкая специализация по областям. В медицине есть врачи общей практики. А "фейсбуки будущего" будут рисовать архитекторы, а строить по нарисованному плану специалисты.
Выходит, в этой схеме архитектор должен за 365 зней в году поиграться хотя бы по 10 дней (для поверхностного знакомства) с 365 разными СУБД? Проблема ведь еще в том, что сами темы не расчерчены четко. Раньше были просто "базы данных" и это было практически синонимом для реляционных баз данных. Сейчас видов баз данных оказывается очень много. А нет общей схемы, чертежа, где бы кто-то их обозначил и ввел новую должность, переименовал бы прежних "специалистов по базам данных" в "специалистов по реляционным базам данных", и учредил бы новую должность специалистов по базам данных, где были бы всякие графовые базы данных, документные, time-series и базы в блокчейне.
Я думаю, большинство архитекторов давно уже "там". В реале, это норм. Просто надо уметь слушать мнение профильных спецов.
А решения в целом, по сути не такие уж и сложные, если не решаешь задачу с заведомо сложными нефункциогальными требованиями
Мне думается, что "генералист" - это не тот человек, который знает, базу какого производителя лучше использовать, а тот, который знает, как решить задачу в принципе. Таких людей называют архитекторами. И они были, есть, и будут.
Очень давно, когда всех людей, создающих ПО, называли программистами, один умный человек определил, что хороший программист, это не тот, кто хорошо знает Фортран, или PL/1 (давно это было), а тот, кто хорошо знает японский язык. Он был японцем :-))
что такое "как решить задачу в принципе"? Ну вот мы делаем систему мониторинга, допустим. собираем метрики, храним их. Надо же их где-то хранить? Наверное, надо в какой-то базе, а не просто в текстовом файле? Что нам должен сказать архитектор (который при этом не является хотя бы "всего на метр" специалистом в СУБД), куда ему направить нас, если он (будучи архитектором) не знает о существовании time-series баз, степени зрелости этих проектов, насколько весомы их преимущества?
Конечно, архитектор тут может "изобрести велосипед", сказать, что обычная база как бы в целом и подошла бы, но не очень удобно, давайте сделаем (и тут описание основных фич time-series баз данных). Но тогда мы откладываем запуск проекта на 2 года, пока свой аналог Prometheus не напишем...
Выбор базы - уже производная задача. Задача, которую нужно решить "в принципе" - это построение системы мониторинга :-)
То есть, архитектор скажет глубокую мысль - "ну... для мониторинга надо будет где-то хранить метрики", без лишних уточнений? -)
Думаю, добавит ещё чего-нибудь. Но главное, что он сделает, это запросит требования как по бизнес, так и по не-бизнес части, на основании которых и начнёт что-то писать. Ну и говорить тоже. Вопросы зрелости той, или иной СУБД - вещь важная. Но, возможно, что для решения задачи хватит тупо файла с записями постоянной длины, или какого-нибудь sqlite :-)
Может быть, что и sqlite хватит, да. Но давайте допустим, что правильный ответ - prometheus или cockroachdb (относительно новые необычные базы). Как проект с нашим архитектором во главе дойдет до идеи "давайте попробуем, как с нашей задачей справится прометеус?". Кто-то уже должен как минимум слышать это слово.
Да, конечно. По моему опыту, это происходит так: нам нужна система, делающая вот это и вот это с такой-то производительностью. Что это может быть? Давайте спросим спеца в этой области. Но это уже второй, если не третий этап в решении задачи. Т.е. "генералист" сперва формулирует правильные вопросы. Ровно так же, как в конце-концов дело доходит и до спецов по сайзингу, которые решают, какая конфигурация железа нужна. Но во главе технической части процесса стоит тот самый "генералист".
Делегировать специалисту - это хорошее очевидное решение, но я как раз о том, что для того чтобы правильно делегировать, (правильно поставить вопрос) - уже нужен качественный и современный кругозор. Нужно понимать границы своей некомпетентности.
Представим, что наш генералист/архитектор знает про реляционные базы, но не знает, про другие типы. И тогда вопрос он передаст чуть более узкому специалисту по реляционным данным (и это уже будет ошибка, так как бызы бывают не только такие). Или даже еще хуже, мы знаем, что есть mysql, postgresql и oracle и передаем наш вопрос трем профильным спецам, каждый из которых оценит именно как справится с задачей его профильная СУБД.
Сейчас, на этом искусственном примере кажется очевидным, что надо еще задать вопрос "а нет ли каких-то новых, уже взлетевших, популярных стабильных субд которые нам подошли", но это только потому что мы с вами знаем, что они есть. А если бы не знали?
Вот иллюстрация для "не знали" - нужно поставить где-то сервер, для простой задачи, но должен работать очень быстро. Какую ОС возьмем? Ну из чего мы выбираем? Linux - номер раз конечно же. Возможно другие юникса. Может быть и винда. Такой ответ про ОС я бы дал и в 2000 году. А вдруг за четверть века что-то случилось и уже есть новый интересный фаворит? А мы даже и не знаем, и даже и не знаем, что мы не знаем. Вот при таком незнании - тяжело передать вопрос спецу, так как ты не видишь воообще выбора, нет даже вопроса (а справится ли QNX или ReactOS или что-то еще с нашей задачей), если ты вообще про QNX или ReactOS не слышал.
Делегрование хорошо работает когда уже есть кругозор и общий охват темы.
Не стоит волноваться, AGI всё разрулит. Человек уже достиг предела возможностей. Сингулярность, что поделаешь. Мозг не способен к обработке и хранению таких потоков информации, которых мы уже достигли.
надеюсь, что большинство шаблонных задач возьмут на себя нейросети(та что там, уже взяли), а человеку останется грамотно поставить задачу, проконтролировать правильность работы решения, и написать ту часть где нейросеть не справилась (справилась не так хорошо)
Ещё забавно, когда человек, выучивший С++ в 90-х и с тех пор никаких новых знаний не обретший, смотрит как человек плохо справляется, когда он пришёл работать над Ангуляром, а ему всунули проект на Svelte и велели переписать на React, и считает этого человека неучем и неумехой.
Чуть-чуть оффтоп, правильно "теорема Пуанкаре-Перельмана")) хоть он и отказался от денег...
А терапевт и общий хирург не в счет? :) Уж не говоря о врачах-диагностах. А то каждый специалист норовит лечит свою проблему, а тушке от этого не легче.
Если говорить про нашу область - это все делает разработку дороже, предвещая ее конец. Все эти no-code/low-code инструменты как тильда, которая похоронила веб-студии. Ведь сколько магазинов и сайтов крутится в сети, и какому проценту от них не хватает mysql/postgresql?
О, Тильда! У нас, с товарищем Гуглом есть что по ней сказать. Мне вообще кажется, что вебстудии - это какой-то ад, место где часто невежество встречается с невежеством. Приходит заказчик (скажем, СТО по ремонту дизельных двигателей - вполне хороший бизнес, хорошую СТО найти сложно, люди их ищут) и просит сделать ему веб-сайт. Заказчик разбирается в дизелях, а вот в сайтах - ни бум-бум. И ему делают сайт. Кто делает? Недорогой студент, который в этой теме едва-едва лучше него понимает. Либо просто "дед", уже матерый, но застрявший в начале 00-ых, на своем PHP/MySQL, возможно со своей самописной CMSкой или какой нибудь мадженто-друпал-вордпрессом. Главное мое обвинение вебстудиям - они делают то что им нравится (удобно, дешево, привычно) делать, а не то, что будет лучше заказчику. Игнорируя неписанное требование, что сайт должен соответствовать некоторым нормам качества (например, web vitals).
И что получается? В целом, когда заказчик смотрит глазами на сайт - да вроде все красивенько... синее - выглядит синим, зеленое - зеленым, справа контакты и телефон, по центру красивая машина нарисована. Он в общем-то это и хотел! Акт приемки работы, оплата - все проходит, все довольны.
Но получилось (возвращаясь к сайту) - адъ и израиль! При почти полном отсутствии контента - грузится долго, на устройствах с не таким разрешением экрана, как у разработчика - отображается криво (вплоть до невидимости элементов или невозможности на них нажать), пока не подгрузились все картинки - ничего не видно, а если начнешь что-то делать, то когда догрузится последняя - все поперекосое6ит, и твой клик на кнопку "отменить заказ" попадет на "подтвердить заказ". В общем, никакими web vitals там и не пахнет.
Естественно, гугл это видит. А он хочет вывести посетителя на хороший сайт. Если даже технически видно, что сайт - говно, то, гугл понимает, что они и сайты делать не умеют, и, наверное, дизеля тоже (поручают кому попало и не контролируеют результат). Гугл понимает, что это адъ и израиль, и что бесчеловечно пускать живых людей видеть ЭТО (при том, что по запросу "ремонт дизеля <город>" есть еще много сайтов, и некоторые из них выглядят (с точки зрения гугла) просто шикарно. Вот те и будут в результатах поиска, а этот ужас он спрячет подальше, ибо ценит своих посетителей.
Клиент, который обратился - он про это все не знает. Он вообще браузером мало пользуется (да и слова такого не знает). Он просто слышал, что нужен сайт, и вот.... . Разработчик, которого он нанял.... может быть тоже про оценку сайта гуглом не знает ничего. Ну или знает, но зачем ему это, догонять там метрики до "зеленых" значений, близко к 100%, если клиент об этом "градуснике" даже не знает и не оценивает по нему?
А на тильде - еще хуже...
Получается, интересная штука: то, что наш заказчик (дизелист) может увидеть глазами - это на самом деле стоит недорого и любой студент ему это сделает (или сам, на тильде). Но то, что ему в самом деле бустануло бы бизнес в небеса (при том, что велик шанс, что среди дизелистов в его городе *у всех* сайты уродские, и его сайт мог бы быть для гугла эталоном дизельного сайта) - он про это даже не знает, не может заказать (ибо не знает, что заказывать, кроме как "ну сайт... хороший..., как у Петровича, чтоб не хуже") и не может оценить качество работы.
то, что ему в самом деле бустануло бы бизнес в небеса… Это точно не сайт, прошу прощения. Вы в свою очередь попадаете в ловушку преувеличенной важности своей отрасли. Может быть, в начале нулевых это сработало бы. Сейчас… Сейчас больший поток клиентов даст скорее грамотно администрируемая группа в фейсбуке. Сайты, гугль этот ваш — это что-то для программистов, а мне дизель чинить надо.
И стоит еще четко понимать, что такие «железные» бизнесы — это не продажа сковородок Цептер, здесь привлечение новых клиентов любым методом работает на старте, и довольно недолго. Дальше на первые роли выходят репутация фирмы и сарафанное радио. Опыт тех клиентов, которые уже починили дизель, и радостно советуют тебя друзьям, и сами пойдут чинить к тебе дизель снова. Сайт тут никак не поможет, он по большей части не для набора новых клиентов, а для дополнительной связи с уже нашедшими.
— Как, говоришь, сервис называется? Гараж на Строительной? Ща глянем, эй, гугль, гараж на строительной ремонт дизелей. Ага, вижу. Этот?
Я не утверждаю, что каждый бизнес должен обязательно иметь качественный сайт. Некоторым достаточно некачественного. Некоторым вообще сайт не нужен. Но решение про это может принять (и оплатить расходы, или же оплатить недополученную прибыль) только хозяин бизнеса. А веб-студия ему должна описать варианты, отличия и разные цены. Мне кажется, что они (студии) немного мухлюют, не описывая минусы своих (быстрых в реализации, чтоб шлеп-шлеп и в продакшн) решений. Они подают сайт в виде "вот, сайт в лучшем виде, вы хотели в синей цветовой гамме и с тем шрифтом? вот - так и есть". И берут деньги тоже за сайт "высшего качества". Без приписки "сайт (3 сорт, не индексируется поисковиками) - 250 000".
То, то делают сайты третьего сорта - претензий нет, на каждый товар свой покупатель. Претензия - что скрывают, что сорт третий. А может быть даже сами не понимают этого. (И тильда тут - в самом деле неплохой бесплатный заменитель для сайта, на который все равно почти никто не придет)
Скажем так: я встречал людей, для которых маркером мухлежа будет уже фраза "в самом деле бустануло бы бизнес в небеса". И не на пустом месте. Чертова уйма бизнесов, и автосервисы к ним по большей части относятся, за исключением стартового периода, когда надо оповестить потенциальных клиентов, от положения сайта в гугловыдаче зависят примерно никак. Грамотный хозяин это понимает. Неграмотный ведется на "бустануло бы в небеса", тратит деньги зря, после чего проникается к айтишникам классовой ненавистью.
В остальном я с вами спорить и не готов, и не особо компетентен.
Истинно вам говорю это просто гадание. И да, это немного обижает мудьтипотенциалов. Впредь думайте о том, что пишите. И знайте, что не генералисты будут всегда и все время на хорошем счету. За счёт своих не генералистичных качеств. Они лидеры, они победители, в отличие от забитых профи. По крайней мере я живу хорошо и буду жить ещё лучше, чем генералисты, спецы, люди в черных балахонах. И так будет всегда!
"Генералисты" по большей части выплавляются в архитекторов. Такие люди нужны практически в любых сложных системах и структурах. Очень широкий кругозор, возможность охватить какую-то сферу целиком, но не вдаваясь в тонкости. Но могут и просто перейти в разряд специалистов в какой-то области, может в паре областей, просто будут ещё иметь и более широкий спектр познаний.
Конечно, свет на них не сходится клином, как лет 30 назад на любом сотруднике с должностью "программист", который и картридж с мышкой должен был уметь поменять, и в настройках ОС и в БД понимал на хорошем уровне, да ещё и мог\умел писал софт.
Сфера ИТ расширяется огромными темпами и скоро уже счёт ИТ-профессий и специальностей будет идти за десяток сотен. И как результат - необходимы будут как работники, кто способен обозреть общим взглядом весь предмет или задачу - единичные карды, так и гораздо более узкоспециализированные в намного большем количестве работники.
Автор правильно подметил - Через пару десятков лет после первого сеанса братьев Люмьер было несложно стать киноведом, который видел все фильмы. С ИТ - почти то же самое.
Спасибо за статью. Автор все правильно пишет. Я с этим сталкивался еще в 90е, что многих удивит. Уже тогда сфера ит была очень объемная. Именно поэтому я всегда смотрел в корень, изучал как работает машина вплоть до физического уровня, а не распылялся на прыжки по верхам (хотя разбирал на практике массу всего). В 2000х и позже я осознал куда клонят корпорации. Они порождают избыточные "технологии" чтобы никто не мог разобраться и взять контроль, удачно форкнуть (не обязательно с исходниками, можно просто повторить логику) и перехватить инициативу, повести развитие в оптимальную сторону. С 90х в логике работы компов поменялось не так много, как может показаться. Но везде возобладала колоссальная избыточность под предлогом "упрощения". Разработчиков массово вытеснили от работы непосредственно с ресурсами во все более высокоуровневые виртуальные среды. Часть "технологий" просто откровенно ограничивает доступ к ресурсам там, где он явно напрашивается. И везде демагогия про безопасность всего, от невинных ошибок до злонамеренных действия, однако контроль над кодом и данными плавно перетек к корпорациям, самым злонамеренным сущностям, какие только можно представить.
Ключ к реальному пониманию работы технологий лежит в доскональном понимании того, как работает комп на самых низких уровнях. Именно это определяет что может быть, а чего не может, сильно сужая область поиска при решении насущных проблем, в тч с незнакомым софтом, помогает оценивать качество работы этого софта по поведению в определенных ситуациях.
Но это не решает саму проблему засилья навязанного кривого софта и прокладок. Иными словами, иногда просто выбирать не из чего даже при обилии предложений на рынке. Разработчики, следующие "трендам рынка" сразу попадают в сети и в принципе не способны из них вырваться. Тем, кто не согласен мириться с положением вещей и находит неординарные решения, вставляют бесчисленные палки в колеса и таких людей просто мизер. Ситуация патовая, разруливать ее нужно законодательно и оч тонко, но решительно. Архисложная проблема. При этом все равно необходимо, хоть отчасти, поддерживать массу "технологий", уже втертых гнидами, поск на них зиждятся массы уже написанного софта.
Но здесь у меня есть проблеск надежды. Гугл выпустил Андроид всего то в 9-10г, и спустя неск лет рынок был завален продуктами на самые разные темы. Гугл мразь, но это говорит о том, что можно заново все создать в глобальном масштабе и наполнить содержанием в короткий срок. Но, тем не менее, по сей день под мобильными ос нет многих возможностей, привычных для винды или даже десктопного линукса. Есть продукты, разработка и вылизывание которых занимает много лет и компенсировать это тяжело. Так или иначе, но от нагромождения программных и аппаратных граблей нужно уходить, и чем раньше, тем лучше, а вузы должны начать готовить грамотных специалистов, понимающих как работает комп изнутри. Иначе грош цена такому "легкому" образованию.
Ссылаясь на примеры из статьи это возможно сделать. Когда то врачей учили быть универсальными специалистами и они могли диагностировать и лечить любые заболевания, хотя после первичной диагностики все же отправляли к тем, кто занимается узкими профильными проблемами, просто потому, что у них много практики и опыта в конкретной сфере. С тех пор организм человека никак не поменялся, а медицина шагнула вперед в понимании многих проблем, однако врач общей практики сегодня не знает почти ничего, а узкий специалист знает лишь частые проблемы своей области. Это результат криво работающих системы образования и организации работы медицины.
Ну и накладываются общественные проблемы, идеология. Повсеместно вялость и безделье, все сытые и ленивые, ответственности никакой, энтузиазма нет, переживания за дело и больных нет. Зато главное бабло.
А далее наша планета попробует в IT без генералистов