Возможно, моё мироощущение для современной молодежи выглядит так же чуждо, как когда‑то для нас выглядели перфокарты и БЭСМ. Они не застали ощущения той свободы и романтики, которая окутывала профессию в годы моей юности и отрочества.
Я начинал ещё в младшей школе с создания простейших игр на «Спектруме». Тогда все, кто хоть как‑то был связан с компьютерами, считались компьютерными гениями, а слово «хакер» было высшей похвалой, а не ругательством. Программирование привлекало низким порогом входа и возможностью создавать миры из нолей и единиц. По сути, у тебя под рукой не было ничего, кроме этого. Нужно было понять принципы структурного программирования, устройство памяти, ввод‑вывод — и ты уже был программистом! Основная задача программиста сводилась к тому, чтобы просто создать работающую программу. Это была творческая работа: требовалось придумать подход и оптимизировать алгоритм так, чтобы он заработал на том маломощном «железе». Ты отвечал за весь цикл разработки: понимал, что нужно пользователю, изучал его психологию взаимодействия с программой, разрабатывал интерфейс, реализовывал его и добивался работоспособности. Настоящим мастером считался тот, кто мог выжать максимум из оборудования и придумать уникальное решение. Например, у всех текст вводился в консоль, а у тебя — мышь и красочные анимации. Или у других жужжал дисковод, а у тебя всё загружалось мгновенно. Программистов тогда уважали и знали: если не создавать условия для работы, никакого «волшебства» не будет. Да и мстить они умели — уйдут, и система, поддерживающая предприятие, рухнет.
Со временем системы становились сложнее, и появлялись новые технологии и библиотеки. Уже не требовалось писать всё с нуля; новые инструменты ускоряли процесс и позволяли сосредоточиться на задаче. Программирование было именно инструментом: программисты не просто писали код, они создавали продукты и находили нестандартные решения для нужд пользователей. Главной задачей программиста было понять, что нужно пользователю, и реализовать это так, чтобы работало быстро и надёжно.
Когда наступил тот момент, когда не технологии стали инструментом программиста для решения задач, а сам программист — инструментом для обслуживания программного кода? Когда крутость программиста стала определяться умением стать корпоративным винтиком, надёжным и безотказным, а не умением «взломать» любую проблему? В мою молодость программистов привлекали проектами, которые обещали изменить будущее, а сейчас молодых привлекают печеньем на кухне и удобными креслами. Программисты соревнуются не в достижениях в демосцене или создании полиморфных вирусов, а в том, возвращать ли null. Почему сейчас «никто не любит задачи с литкода», хотя именно такие задачи раньше составляли суть профессии?
Вопросы, конечно, риторические. Когда не было выбора, бизнес терпел бунтарей, но искал способы усмирить их. Библиотеки и фреймворки из помощников превратились во врагов — выгоднее, чтобы ты учил их в нерабочее время, работая на проект за пределами проекта, но бесплатно. Таланты бизнесу не нужны — это риск, что если человек уйдёт, проект встанет. Лучше нанять десятерых средних и покладистых, чем одного талантливого, но своенравного.
Отдельно умиляют «софт скиллы». Думаете, за вопросом «ваши планы на 5 лет, чего вы ждёте от новой работы» скрывается интерес к вашим амбициям? На самом деле проверяют, сколько вы планируете быть винтиком на новом месте. HR ждёт ответа о привязанности к работе через ипотеку, а не о стремлении строить бизнес или научную карьеру. На словах от вас ждут лидерских качеств и самостоятельности, но не дай бог упомянуть о собственном бизнесе или управлении людьми. Лидерские качества и самостоятельность — это, по сути, лояльность и исполнительность. Все бизнес‑процессы в IT настроены на то, чтобы сломать волю, выжечь творческое, чтобы в вашем сознании сложилась картина мира, где бизнес соизволяет вам оказать честь служить ему, и никакой альтернативы этому нет.
По сути, современный программист — это чернорабочий на конвейере, его роль и доходы устремлены к такому же уровню. Разница лишь в том, что чернорабочих легко нанимают и увольняют, а программисту приходится пройти все круги ада, чтобы удостоиться чести стать винтиком в машине, обслуживающей чей‑то бизнес.
Комментарии (328)
urvanov
29.10.2024 16:17Про ваши планы на пять лет особенно смешно, когда ты даже не знаешь, что будет через год.
maxzh83
29.10.2024 16:17Справедливости ради, эту фигню уже давно не спрашивают как и почему люки круглые
artemmoscow Автор
29.10.2024 16:17Про планы справшивают как раз постоянно. Цель - выведать не является ли для тебя работа временной. А про люки как раз хорошие вопросы, люблю такие - они были актукальны в то время, когда нужны были абстрактно умные, а не хомяки которые зазубрили принципы солид и чем отличается интерфейс от абстрактного класса.
ganqqwerty
29.10.2024 16:17Этак и в IQ можно поверить. Давайте кружочки с квадратиками давать на собесах, оно ж проверяет умность! По сто раз же все признались, что люки не проверяют абстрактную умность и не коррелируют со временем, за которое тебя успеют уволить. Поэтому и нет люков ни у кого, даже у тех, кому нужны абстрактно умные.
И опять же, хомяки брали и прорешивали учебник "Занимательных задачек для восьмиклассников" так же как сегодня прорешивают литкод.
artemmoscow Автор
29.10.2024 16:17Люки это и есть задачки на IQ. А что бы вы спрашивали, если у вас вакансия, специалистов на которую нет на рынке, и вы ищите человека с высоким IQ и со склонностью к нестандартному мышлению? Попытки все порашать зарание - ну это по сути такой же хак со стороны соискателей как попытка использовать шпаргалку на обычное собеседование. Потому что обычно просят признаваться, если знаешь задачу
ganqqwerty
29.10.2024 16:17Неделю вместе плотно поработать, вот что бы я спрашивал, а лучше месяц-два. И до сих пор только так и получается кого-то толкового нанимать. Задача понять, подходит ли человек для работы за 120 минут собеса - нерешаемая в общем виде. Ответ вы не получите. Зато на собесе можно понять, любит ли человек решать головоломки. Или усвоил ли он первые два курса по CS в институте, чтобы от зубов отлетало. Или может ли написать какой-нибудь несложный код. Это за 120 минут проверить можно, ну и проверяют. К работе это имеет слабое отношение, но хоть какое-то имеет, ну и нормально.
А IQ проверит, надо ли посылать кандидата в "класс коррекции" или нет. Большей предсказательной силы он не имеет, там можно только одно деление оставить (в районе 85).
mclander
29.10.2024 16:17Пособедуйте кандидатов. Когда чел пришёл на мидла и не смог написать цикл в JS. А на предложение решить через map/forEach вообще сделал круглые глаза. Люди не понимающие, где может возникнуть исключение, а где можно свалиться в бесконечный цикл, просто потому, что не проверяешь параметры, внезапно составляют чуть ли не половину от кандидатов. Притом с реальными резюме) На их фоне люди биндящие функции-стрелки (потому что раньше в Реакте "надо было всё биндить") на этом фоне очень даже.
artemmoscow Автор
29.10.2024 16:17и что тут такого? я тоже цикл foreach на листике в js не напишу. я такой код обычно копипащу. Для меня как раз показатель эровня того, кто это справшивает. значит сам последние 10 лет только циклы и писал. Если это мой 10-й язык, в голове остаются только принципы. вообще с тем что вы пишите легко ИИ справляется.
ForestDront
29.10.2024 16:17На листике? Тут недавно на собесе меня просили прокомментировать код. Ну вроде обычное дело. Только код был написан на листике от руки и его тыкали в камеру. Потыкали секунд 5, потом плюнули и начали зачитывать вслух.
artemmoscow Автор
29.10.2024 16:17да дело не только в этом. я и в блокноте не напишу. если бы я каждый день писал этот map то наверное помнил бы, а так мне достаточно знать, что он есть. когда в среде с подсказками работаешь то уже в мышечную память все уходит. ну очевидно в map будет лямбда функция а как оно в коде выглядит - прям по памяти - хз. нахрен мне помоями голову забивать?
mayorovp
29.10.2024 16:17Не то тут тот факт, что от мидла ожидается опыт работы. И не может быть такого, что мидл никогда не работал с массивами в прошлом. И если ты не знаешь ни одного способа работы с массивами - ты не мидл, ты стажёр-недоучка. Это во-первых.
А во-вторых, вы не сможете написать цикл, потому что забыли синтаксис, или потому что не умеете писать циклы в принципе?
Первое простительно, и на бумаге никто не мешает написать как помните. Второе говорит о том, что вы даже школьную программу не смогли освоить.
artemmoscow Автор
29.10.2024 16:17я думаю что людей не знающих что такое циклы не существуют. меня вот спросили недавно что такое спред оператор.. я такой хз что за оператор. говорю вы наверное три точки справшиваете? ну да.. какой синтаксис. и тут я впал в ступор. Слева или справа? когда смотришь код оно естественно как то. Говорю блин не помню слева или справа, но это штука которая может поля сразу все копировать или в массив развернуть.. в общем они сделали вывод что я на js не писал совсем и им вру.. хотя считают для фулстек программиста это простительно - то спрашивают как индексы реализованы и блокровки запросов то как память, там про алгоритмы черно-красных деревьв.. как это в голове держать? конечно стараешься не захламлять голову, зачем помнить справа оно или слева, в коде-то видно
mclander
29.10.2024 16:17Это нормально. Я тоже не сразу вспомнил, что ... - это именно спред-оператор. В принципе и сейчас можно найти деятеля, который спред реализует, через _.clone, потому что он всю жизнь под 10 эксплорер на jQuery писал для какого-нибудь ГУ. И транспайлер - это для него какой-то корабль из ЕВЕ-онлайн скорее
mclander
29.10.2024 16:17Именно так. Синтаксис я бы подсказал. Любой, даже сеньор может позабыть, какие-то детали в моменте. Понятно что в реальной работе ты открыл консоль, написал короткий сниппет и всё вспомнил. Плюс задачу можно было решить через map/forEach/reduce, ну не помнишь или не любишь reduce напиши через forEach. Через _.map я бы тоже зачитал бы, даже наверно с плюсом)
Теперь вопрос. Что можно написать на JS не умея в циклы и map?
mclander
29.10.2024 16:17Во-первых в JS нет цикла foreach) Во вторых... и первого достаточно (с) Тот самый Мюнхаузен
ganqqwerty
29.10.2024 16:17Да я так же собеседую. Вот массив объектов, сделай из него другой массив объектов. Понимать как штуки по ссылке передаются Такие вещи оно проверить может. Но обманывать себя и думать, что можно проверить что-то глубже — не надо
mclander
29.10.2024 16:17Всё программирование - это издевательство над данными. Есть одни - надо получить другие. Если чел, может в этом хоть чуть-чуть - он не безнадёжен.
tuxi
29.10.2024 16:17Люди не понимающие, где может возникнуть исключение,
внезапно составляют чуть ли не половину от кандидатов.
Больше. Искали на позицию фронтенд джуна с опытом год +-
Давали сделать тестовое задание, есть rest api с 2-мя ендпоинтами, надо сделать запрос(ы) и отобразить таблично полученный список.
На некоторых сочетаниях параметров, в апи реализовали отдачу сервером ошибок. ТЗ тестового максимально проработано, открыл в сваггере - все варианты ответов сервера перечислены.
95% не сделали обработку ошибок.
mclander
29.10.2024 16:17Кстати половина кандидатов - это про собеседования миддл+
От джуна я бы не ждал обработки ошибок и чеков параметров.
tuxi
29.10.2024 16:17В резюме был заявлен опыт разработки таких вещей, значит уже должны были пройти этап "слепой веры в то, что ответ от сервера приходит всегда". Ну хотя бы 403, 404 и 503 должны были отработать же.
artemmoscow Автор
29.10.2024 16:17это не промышленный код, а скрининг "на листике". люди по умолчанию кидают решение на которое потратили не больше 15 минут времени, с той стороны не знают что вы проверяете, может синтаксис. обаботка экспешинов неразрына связана с бизнес логикой, если не прописаны эти кейсы, какая разница что упадет браузеру в консоль? Я бы джунам такие говно конторы советовал обходить 10-й дорогой. Если год якобы ищут, просто веером рассылая тестовое, рассчитывая что классный спец пройдет на минимальную з.п. как джун. Подозреваю что вы не FAANG и не контора мечты к которой люди шли всю жизнь, что бы прям готовится и все идеально делать.
mclander
29.10.2024 16:17хотя бы обработать catch)))
Но вообще джунов надо предельно чётко ориентировать. Потому что если джуна не надо ориентировать, то он уже миддл)
unreal_undead2
29.10.2024 16:17Угу, для джуна - обработать catch, для сеньора - рассказать с аргументами и отсылками к своему опыту о вреде исключений )
artemmoscow Автор
29.10.2024 16:17Слушайте, конторы абсолютно разные с абсолютно разными требованиями. Я например пришел в одну контору и мне сказали что у меня плохое качество кода, потому что коментарии не пишу.. не помню что бы в других местах их кто-то писал. Где то на ревью режут потому что лишний пробел в коде, а в других корпах код ревью только внедряют. У всех требования очень разные! И программисты все очень разные, с разным мышлением, для всех понятие важного разнится. Кто-то на алгоритм смотрит, а кто то на оформление. Меня например задачи на рефакторинг бесят. Дают кучу бессмысленного кода - например вот у нас числа фибоначчи в базу пишутся, и такие - а что исправить? Да что тут исправлять, такой задачи на проде просто не могло быть, откуда мне знать что вы от меня хотите?
tuxi
29.10.2024 16:17Да именно этого и ждали. Если не знаешь что сделать, ну выведи хотя бы надпись "тут все упало" и/или спроси уточни, что требуется.
artemmoscow Автор
29.10.2024 16:17Ну а вы в ТЗ написали, что нужна обработка ошибок и что сервер их может возвращать?
Как человек должен был догадаться что их нужно обработать?
Сами сделали спецификацию на двойку, а начинающий программист должен был за вами подтирать. Причем бесплатно!
tuxi
29.10.2024 16:17Написали конечно же, все варианты ответа сервера были перечисленны.
Получился тест на достоверность утверждения, что сам реализовывал такой фронт, а не вносил модификации.
Кстати первым кандидатом который реализовал обработку ошибок, оказалась девушка лет 28, и остальное она сделала весьма прилично, видно сразу, что уже был реальный опыт. Но к сожалению ее перебил зарплатой другой работодатель.
mclander
29.10.2024 16:17Да-да. Помню мне как куча банков не хотела давать кредиты (серая зарплата и техническая просрочка платежа на день, не работал сайт онлайн, а я был в другой стране). А потом как те же банки задолбали предложениями... А я ремонт уже окончил.
Wesha
29.10.2024 16:17"Банки всегда рады предоставить кредиты человеку, которому они на хрен не нужны" (c)
artemmoscow Автор
29.10.2024 16:17ну если это было в тз, то тогда надо было сделать. но все равно это не уровень джуна. Джун - это уровень того, кто курсовые в универе делал, по определению без промышленного опыта.
tuxi
29.10.2024 16:17Я не знаю как назвать уровень человека, который имеет 1..2 года опыта, большей частью свои мелкие пет-проекты и полгода год в реальной разработке. Это уже не стажер, это еще не мидл. Получается что джун. Что не так то? Был бы нужен стажер (нам не нужен), задание было бы другое.
А так, по итогам собеседования, принималось решение - предлагать кандидату тестовое или нет. Человек соглашался. Делали тестовое кстати не больше 33%
Если в вашей парадигме джун не должен понимать, что все что связано с сетевыми делами, может иногда и не работать и об этом надо как то сообщать юзеру в простом виде "упс что-то пошло не так", то это ваша парадигма. Зачем ее обобщать на всех?
artemmoscow Автор
29.10.2024 16:17Для меня это деление вообще бессмысленно. Так-то по логике если человек закончил универ и 2 года (я не понял что вы имели в виду 2 года опыта но работает пол года) работает, то это уже вполне готовый специалист. Тестовое оно на то и тестовое, что это скорее наброс, некий проттотип. Я конечно согласен, что если вы написали, что нужна обработка ошибок и чел не знает как ее сделать, то брать такого не надо. Но если он должен угадать ваши требования к тестовому, это уже какой-то искуственный фильтр. К ПО может быть огромное число требований - откуда мне знать что именно вы хотите проверить
artemmoscow Автор
29.10.2024 16:17Для меня это деление на касты вообще бессмысленно. Для одного проекта это джун, для другого сеньор. Так-то по логике если человек закончил универ и 2 года (я не понял что вы имели в виду 2 года опыта но работает пол года) работает, то это уже вполне готовый специалист. Тестовое оно на то и тестовое, что это скорее наброс, некий проттотип. Я конечно согласен, что если вы написали, что нужна обработка ошибок и чел не знает как ее сделать, то брать такого не надо. Но если он должен угадать ваши требования к тестовому, это уже какой-то искуственный фильтр. К ПО может быть огромное число требований - откуда мне знать что именно вы хотите проверить
mclander
29.10.2024 16:17Сеньор это человек, который тебе делает мозг только при обсуждении задачи. И если у задачи есть риски, сразу их подсвечивает ещё на берегу. Т.е. тратит минимум времени заказчика и команды, при этом довольно надёжно даёт результат. Набор технических средств для этого может быть довольно скудным
artemmoscow Автор
29.10.2024 16:17посмотрел ваш блог, вы там спрашиваете почему && автоматически пропускает второе условие, а два подряд идущих if - нет. Ну как по мне такие вопросы чисто джуновские, почему так я еще в школе знал. Оператор && пропускает проверку второго оператора, если первый проходит, я это еще в школе знал, когда на си программики писал, а вы мало того что не знали, так еще и сами разобраться не смогли и целую статью накатали.. Я это пишу не к тому, что бы оскорбить, а к тому что у всех опыт разный, и что для вас очевидно, не значит что очевидно для все. IT гигантская область и знания и требования у всех разные.
tuxi
29.10.2024 16:17Вы так торопились написать ответ, что даже не пытались вникнуть в суть статьи
Внятного обьяснения, почему компилятор Go не оптимизирует код и всегда проверяет второе условие, даже если первое ложно — я не нашел.
artemmoscow Автор
29.10.2024 16:17Внятное объяснение элементарное. && прописано в спецификации, а условный оператор - нет. Это шло еще со времен Си и распространилось на другие языки. Потому что && оптимизировать элементарно, просто реализовать(перегрузить) саму функцию так, что бы второй оператор вычиалялся только если первый true, а вот второе условие - это уже нужна определенная эвристика, плюс си-стайл написания предполагает что возможно вам нужно проеврить второе условие. Я это знал еще в 11 классе.
tuxi
29.10.2024 16:17Мы точно об одном и том же говорим?
// вариант 1 for _, value := range arr { if exp1 && exp2 { .... } } // вариант 2 for _, value := range arr { if !exp1 { continue } if exp2 { .... } }
Вариант 2 выполнялся на той версии Go, на том процессоре и на той операционной системе быстрее. Там в комментариях был листинг дизассемблирования (видно автор ушел с хабра вместе с комментариями), по нему было видно, что в варианте 1 происходит переход в конец цикла, а в варианте 2 после первой проверки происходит переход сразу в начало цикла.
Причем здесь язык С я не очень понимаю.
artemmoscow Автор
29.10.2024 16:17может я чего то не догоняю но не понятно в чем заминка? код делает ровно то, что написно. В первом случает проверяет expr1 и идет до конца цикла, во втором команда continue переводит в начало цикла, что не так? Почему код на go в данном случае должен компилироваться по другому чем на си? интуитивное ожидание пользователей что он будет работать так, т.к. си-подобный язык и явный наследник
tuxi
29.10.2024 16:17В первом случае, если итоговое выражение false, он переходит на конец цикла. Во втором случае - в начало. На маленькой выборке этого не видно, но когда массив приближается к максимально возможному значению 32 битного целого, разница может доходить до 10%.. Конечно есть зависимость от сборщика мусора (особенно если внутри условия выполняются каике то операции сложнее присвоения целочисленной переменной нового значения) и тп, но в целом разница устойчива.
artemmoscow Автор
29.10.2024 16:17тут нет выделения памяти, причем тут GC. В коде вы так и написали, что в первом случае должен перейти в конец массива, а во втором в начало. Он делает то что вы написали, в чем вопрос?
tuxi
29.10.2024 16:17В конец цикла, а не массива.
Вопрос в тот раз состоял в том, что например в java время выполнения было одинаковое. А в go оказалось что нет.
artemmoscow Автор
29.10.2024 16:17ну видимо в java конца цикла как такового нет (нет операций в конце). В этом коде тоже не очень понятно какие операции в конце цикла, но если там можно ставить брейкпоинт, значит что-то все же есть
tuxi
29.10.2024 16:17мы разобрались с вопросом?
посмотрел ваш блог, вы там спрашиваете почему && автоматически пропускает второе условие, а два подряд идущих if - нет. Ну как по мне такие вопросы чисто джуновские, почему так я еще в школе знал.
artemmoscow Автор
29.10.2024 16:17Разобрались с чем? Я писал не к тому, что бы показать, что вы плохой программист или что то типа того, а к тому, что у разных людей затыки могут быть в самых неожиднных местах. Я бы например не факт, что догадался бы отлавливать эксепшин на фронте, если бы меня не попросили сделать это прямо, у вас вызвал ступор оптимизация условного перехода - это не значит что вы плохой программист, просто в этом у вас было меньше опыта
tuxi
29.10.2024 16:17Что значит не просили? openapi.yaml есть? есть (я писал в исходном сообщении про это). В нем описаны варианты ответов? Описаны. Делайте.
Тем более сгенерить код можно прямо из сваггера в тыщи языков.
artemmoscow Автор
29.10.2024 16:17мля ну честно говоря openapi.yaml совсем не похоже на дужновскую тему. не удивительно, что вы годами людей ищите. и утвердили меня в принципе никогда не делать тестовые. Но если была спецификация, вы правы, надо делать.
tuxi
29.10.2024 16:17По-моему как раз похоже джуновскую тему. Нет недопонимания, все четко прописано, вариативности ноль. Вот когда на пальцах описано API это боль.
Годами мы не ищем. Уже нашли, ушло 5 недель и около 30 собесов.
artemmoscow Автор
29.10.2024 16:17я например про этот ваш yaml только недавно узнал и эту вещь человек априори может только в корпах узнать это точно не для пет проектов. то что на такие условия (низкая зп, сложное тестовое и высокие требования) у вас под дверью очередь из кандидатов говорит что с рынком не все ок
tuxi
29.10.2024 16:17Послушайте, ну сделайте опрос. Должен ли фронтенд-джун с опытом до 1 года и скиллами vue/react в резюме, знать что такое swagger/openapi ? Я думаю, выборка из 100 ответов вас точно переубедит.
artemmoscow Автор
29.10.2024 16:17что такое сваггер думаю должен знать, а как генерить из ямла код - не факт. можно выкатить полный список требований? А то может я тоже уже по современным требованиям даже не джун, а стажер.
artemmoscow Автор
29.10.2024 16:17век живи - век учись. У меня в .net core такого меню нет. Как его включить?
artemmoscow Автор
29.10.2024 16:17почему издеваюсь? я особо не вникал в эту тему, для меня сваггер это просто ui библиотека которую можно подключить в дотнете для тестирования контроллеров. быстро нагуглить как включить меню как у вас мне не удалось, у меня такого меню нет. Там нужна новая версия или стороннее по?
tuxi
29.10.2024 16:17это скрин сайта "редактор сваггер", там даже адрес виден
думаю, что плагины к IDE или онлайн сервисы есть, надо просто искать
romanbatygin
29.10.2024 16:17Цикл то написать легко, но когда начинают уходить в обработку кейсов уровня Double.NaN и Double.Infinity и делают вывод, что кандидат не знает базу, это полный бред. Я вот за 6 лет работы может 1-2 раза сталкивался с такими кейсами, так зачем делать на это упор?
vvbob
29.10.2024 16:17Этак и в IQ можно поверить.
"Вы не поверите..!!!" Жена еще когда джуном была, как-то на одном собесе сдавала.. Правда фирма и в остальном оказалась полностью отбитая, я ей очень сильно не рекомендовал там работать.
artemmoscow Автор
29.10.2024 16:17у меня недавно попросили оценки из приложения к диплому показать. Сейчас рынок такой, что работодатель изголяется как может
mclander
29.10.2024 16:17Хорошо, что не школьный аттестат у меня на его фоне диплом прям отличный. Хотя были деятели, которые замечали, что 6 лет учился, а не 5)
artemmoscow Автор
29.10.2024 16:17и чем спрашивать диплом (на скрининге просили выслать!) лучше задачек про люки?
mclander
29.10.2024 16:17Это не ваши проблемы - это их проблемы. Что они не могут спросить то, что их 10 лет назад не спрашивали, когда на работу брали
ganqqwerty
29.10.2024 16:17Хыхыхы, это предсказуемо, раз в этой фирме думают, что интеллект можно свести к паре циферок.
gev
29.10.2024 16:17Давайте кружочки с квадратиками давать на собесах
Теория категорий на собесах – это уже слишком =)
aspirinne
29.10.2024 16:17К слову о хомяках.
Если сравнивать опыт Японии и России, приходишь к выводу, что хомяки обеспечивают более высокий уровень жизни как себе, так и компании. Люди, способные точно и добросовестно выполнять инструкции нужнее (пусть даже в целом они довольно одноклеточные), так как качественная реализация существующего - более насущная проблема, чем создание нового.
jackshrike
29.10.2024 16:17качественная реализация существующего - более насущная проблема, чем создание нового.
не понимаю вас.
"реализация существующего" это и есть "создание нового".
не прямо прорывного нового-нового как фон Браун, а примерно как Королев.rinace
29.10.2024 16:17Вернер фон Браун вообще то реальный член СС. Организации признанной преступной по решению Нюрнбергского суда.
jackshrike
29.10.2024 16:17в случае фон Брауна США в лице своих иммиграционных офицеров (или их руководства) наплевали на решение Нюренбергского суда и ничего ему не сделали за членство в СС. чем я хуже иммиграционных офицеров США (или их руководства) ?
artemmoscow Автор
29.10.2024 16:17Какой то странный пример. Вы работали с японцами, считаете что они не способны на креатив, или что?
И так же можно привести в пример множество стран, где люди работают на назкоквалифицированных работах по 12 часов, но нищие
aspirinne
29.10.2024 16:17Большинство не способны работать вне скрипта. Только четко следовать инструкции.
Речь не о квалификации. Но разница между "креативным, изобретательным разгильдяем" и "заскриптованным, но идеально следующим инструкции служащим" в том, что прорывными технологиями невозможно пользоваться, если не воспроизводить их с постоянным качеством, в должном количестве и в срок.
А для этого нужны эти хомяки, которые не станут отвлекаться на велосипеды (которые хз, сколько времени займут и чем обернуться).
В авто индустрии много всяких инноваций, но нужны не они, нужны условные Тойоты.
f-tech
29.10.2024 16:17А про люки как раз хорошие вопросы, люблю такие - они были актукальны в то время, когда нужны были абстрактно умные
А что сейчас модно отвечать на вопрос про люки?
Просто у меня в голове самый скучный ответ из сопромата – обеспечивают самую равномерную нагрузку и одинаковые линейные деформации. Наименьший шанс заклинить в рамке. Поэтому такие же в бункерах и на подводных лодках. Иногда их делают немного выпуклыми в ту сторону, откуда идёт нагрузка.
Можно катать без помощника? Ну возможно. А ко всем, которые не должны проваливаться в проем, просто приваривают петли. Чердачные люки не дадут соврать )
artemmoscow Автор
29.10.2024 16:17я никогда не слышал правильного ответа (только вопрос), но мне казалось, что самый очевидный - это то, что бы они не проваливались в дырку.
RodionGork
29.10.2024 16:17Есть подозрение что вы смотрите на ситуацию через какую-то призму или фильтр который омрачает вам видение. Конечно ситуация здорово изменилась, что-то интересное ушло, что-то пришло. Просто теперь вообще программистов стало больше (спектрум-то раньше был далеко не у каждого, не так ли).
Почему сейчас «никто не любит задачи с литкода»
Почему вы считаете что "никто не любит"? возможно просто не там смотрите. я вышел в новую команду - обнаруживаю что моя коллега, барышня 24 лет - звезда LeetCode. На более продвинутом сайте CodeForces 13 тыщ человек только из России. Я уж скромно (не) умолчу о моём собственном сайте с 400+ задачами и 50000 пользователями. Неужели все эти люди просто притворяются?
Areso
29.10.2024 16:17спектрум-то раньше был далеко не у каждого, не так ли
компьютер и сегодня есть далеко не у каждого.
в развивающихся бедных странах смартфон тупо дешевле, под него больше нужных программ, плюс встроенный бесперебойник (что актуально в Африке, ряде мест Латинской Америки, в Индии, в Юго-Восточной Азии и Океании). Да и в развитых странах для зависания в социалочках (тик-токах, фейсбуках, и далее по списку), послушать музыку и посмотреть видео достаточно смартфона или планшета. И даже игры есть. И даже игровые смартфоны (хотя еще недавно люди спорили, могут ли быть "игровые" ноутбуки быть игровыми).
А даже если компутер есть - сегодня у многих отвалилось воображение, зачем, если картинка фотореалистичная? Спектрум раньше - признак гика, компьютер сегодня - просто компьютер. Как цветные волосы - сегодня это ничего не говорит.
no1D
29.10.2024 16:17фильтр который омрачает вам видение
Этот фильтр - потеря статуса.
Раньше были "интеллектуальной элитой", а теперь "винтики".
Отсюда же и уничижительное отношение к "винтикам" как компенсация утери статуса.
Ydhduucyw
29.10.2024 16:17Я тоже помню те времена, когда все делали руками и головой. :)
А сейчас программисты это "копипаст" и уборка багов. :)
Спрашиваю программиста, что это за цифра и за что она отвечает? Что будет если поменять ее на другую?
Ответ:ХЗ
Но это же твой код!
Печально все это....
Минусуйте.... :'(
rinace
29.10.2024 16:17Я как то реализовал граф и алгоритм Дейкстры для реализации иерархической структуры . Когда рассказал на дейлике, получил вопрос - ух ты , а какую библиотеку использовал ? И долго понять не мог - о чем это они ....
"Вы зачем используете эксклюзивную блокировку? Это не мы , это фреймворк такой".
DMGarikk
29.10.2024 16:17тут есть некоторый подводный камень который вы не учитываете, вот вы уйдёте из компании, а кто будет ваш граф и алгоритм разбирать, разрабы сеньорского грейда когда в компанию только миддлов берут?
я уже насмотрелся на проекты где люди зажатые сроками тупо забивают разбираться в сложном самописном коде, ставят ифчик и новый функционал пишут рядом который по факту дублирует старый но написанный тупо в лоб на фреймворке..криво, медленно, зато быстро взял задачку - быстро выкатил фичу
печаль да, но бизнес требует именно так
rinace
29.10.2024 16:17кто будет ваш граф и алгоритм разбирать
Однако, когда я учился теория графов и комбинаторика это 2й курс КАИ .
Если для современных разрабов это проблема , это ещё раз подтверждает грустную истинность данной статьи - "те времена прошли"
Когда наступил тот момент, когда не технологии стали инструментом программиста для решения задач, а сам программист — инструментом для обслуживания программного кода?
DMGarikk
29.10.2024 16:17Я бы сказал что те кого вы называли программистами, стали архитекторами и топ.сеньорами
А обслуживание кода, так так и было, ведь кто-то платит за вашу работу, а ваша работа написать и обслуживать.ю код который приносит деньги
rinace
29.10.2024 16:17сказал что те кого вы называли программистами, стали архитекторами и топ.сеньорами
Это утверждение не истинно.
Не знаю как насчёт тех кто вы назвали топ.сеньорами , но за всю жизнь, я лично знаю только одного архитектора из программистов . Наверное , есть и другие , просто мне не везёт .
DMGarikk
29.10.2024 16:17я лично знаю только одного архитектора из программистов
я честно говоря вообще очень мало таких людей встречал, зато встречал реликты оставшиеся от них, вроде ядра системы написанного 10 лет назад и настолько удачно что его никто все эти 10 лет не трогал, сервисы написанные в одно лицо и работающие идеально... и они все или уехали из страны или стали какимито высокими начальниками (в тех случаях где я видел)
rinace
29.10.2024 16:17Таких баек тика "во время ремонта наши в замурованной комнате почтовый сервер компании" тоже наслышан ;-)
встречал реликты оставшиеся от них, вроде ядра системы написанного 10 лет назад
Мне не повезло. Пока ни разу не встретил, хотя , в принципе с начал эпохи всеобщей ITзации с начала 90-х прошло достаточно времени.
GothicJS
29.10.2024 16:17Простую вещь люди не видят - это не для программистов проблема, это специфика работы сейчас другая - под нее и подстраиваются программисты. Там, где в алгоритмы нужно хорошо уметь, там программисты под это и адаптируются. А где не нужно - развиваются в других направлениях.
rinace
29.10.2024 16:17Простую вещь люди не видят - это не для программистов проблема, это специфика работы сейчас другая - под нее и подстраиваются программисты.
Категорически не согласен . Современные разработчики они реально другие.
Я с ними каждый день пересекаюсь, во время аварий - на кофколлах слушаю что говорят.
Это можно отдельную книжку написать с перлам:
-Вы зачем эксклюзивную блокировку используете?
-Это не мы, это фреймворк такой.
(с) Мое любимое.
-Почему у нас запрос на сервере СУБД отрабатывает миллисекунды, а форма минуты рисуется?
Вы не поверите, наверное, но по поводу этой ситуации даже собирали конфколл с вендорами СУБД, ОС, подрядчиков, и присутствием топов.
Мир изменился . Они реально другие.
fen-sei
29.10.2024 16:17тут есть некоторый подводный камень который вы не учитываете, вот вы уйдёте из компании, а кто будет ваш граф и алгоритм разбирать, разрабы сеньорского грейда когда в компанию только миддлов берут?
я уже насмотрелся на проекты где люди зажатые сроками тупо забивают разбираться в сложном самописном коде, ставят ифчик и новый функционал пишут рядом который по факту дублирует старый но написанный тупо в лоб на фреймворке..криво, медленно, зато быстро взял задачку - быстро выкатил фичу
Так делают и с незнакомыми фреймворками тоже. *lol и фейспалм одноременно*
Так что, использование фреймворка - абсолютно не гарантия того, что так не сделают.
WASD1
29.10.2024 16:17алгоритм дийкстры .. разрабы синьорского грейда
Мне кажется вот и ответ на вопрос:
- когда профессия свернула не туда?
- когда умение понять алгоритм дийкстры (с соответствующим комментом) стало признаком синьора.
venanen
29.10.2024 16:17Вроде печально, но есть нюансы.
1) Покрыта ли эта реализация графа тестами (не как обычно, парочкой, а полноценно, весь функционал)? Если нет, то где гарантия, что оно не упадет? Даже великие совершают ошибки. В библиотечной реализации Дейкстры все тесты уже есть, и все баги починены (скорее всего). Боль личная - особенно когда вместо нативных методов (типа сортировки) люди хотят плеснуть ерундицией и делают велосипед (вроде кастомного пузырька), который потом не работает, и фиксить это нужно уже другим людям;
2) Есть ли исчерпывающая документация? Тоже личная боль - тут уже из области железа. Стандартная библиотека, например, для работы UART нам не нравится, мы свою напишем. Потом получается длинный нечитаемый код с кучей ифов, одно-двухсимвольными переменными и магическими константами. Как это править - непонятно;
3) Ну и самое главное - программист в найме в любом случае решает некую задачу. На задачу ему выделяется время, деньги и ресурсы. Потому что иначе можно формы регистрации начать делать с реализации сетевого стека. Это как приходите в ремонте одежды Вам скажут, что мы вам куртку не зашили, так как это колхоз, а сделали с нуля. С вас не 1000, как договорились, а миллион.
P.S. Еще программисты забывают простую и очевидную истину - то, что очевидно мне, может быть неочевидно окружающим. Я, например, могу БПФ реализовать (потому что работал и помню его), но я сомневаюсь, что его сможет подавляющее количество людей, даже если они знают алгоритм Дейкстры, и не потому что они плохие программисты, а просто потому что знать все на свете нереально. И если мне понадобится БПФ, я возьму его из стандартной библиотеки типа np или scypi. Если мне потребуется умножить матрицы - я сделаю точно так же. Это будет оптимизировано (сильно лучше, чем сделать в лоб), быстро, лаконично, легкочитаемо, легкоподдерживаемо.Wesha
29.10.2024 16:17знать все на свете нереально.
«Всю водку не выпить, всех девок не перепортить — но это ещё не повод к этому не стремиться!» ©
vanxant
29.10.2024 16:17Есть такой момент, что все эти БПФ, А*, В* и прочие алгоритмы - это кирпичики. Готовые, но кирпичики, из которых ещё нужно сложить что-то полезное для пользователя.
А здесь, как пишет автор, всё ещё нужно понять этого самого пользователя, продумать интерфейс и т.д. и т.п. И потом суметь реализовать из кирпичей того или иного размера.
За 40 лет изменилось только то, что вместо унылых команд бейсика для спектрума, в котором даже массивов строк не было, у нас теперь есть всякие БПФ и рекурсивные селекты по материализованным представлениям.
imanushin
29.10.2024 16:17Если мне потребуется умножить матрицы - я сделаю точно так же.
С этим, кстати, довольно сложно. Если у Вас в программе уже есть модель данных, уже созданы все классы, люди имеют писать тесты, то добавить функцию перемножения матриц будет проще, чем добавить дополнительную библиотеку, а далее адаптировать модель к ней, плюс тестировать слой интеграции.
Более того, если в приложении довольно много математики, то такие тривиальные вещи, как перемножение матриц, могут вообще почти не повлиять на сложность.
По сути, тут необходимо смотреть, что же выгоднее на самом деле - добавить библиотеку и слой интеграции или же просто реализовать функцию. Хуже всего, что ответ будет очень сильно зависеть от технологии (даже выбирая из JVM/Python/.Net), от задачи (код запускается только на х86, или же требуется arm?), от процессов в команде (новая библиотека в монорепозитории может запустить серию долгих согласований; хитрый алгоритм может запустить дискуссию в PR) и еще от многих других вещей.
Так что Вы полностью правы - всегда необходимо смотреть на то, какую проблему мы решаем.
artemmoscow Автор
29.10.2024 16:17Тут еще в чем фишка. Матрицы придумал Бог, а фреймворки придумали индусы. Разбираться в смысле Матриц все равно что общаться с Богом. А в смысле фреймворков - это нюхать следы жизнедяетельности индусов.
bolk
29.10.2024 16:17…такие тривиальные вещи, как перемножение матриц…
Вот эта фраза хорошо показывает то, почему нужны стандартные библиотеки. Существует несколько алгоритмов их перемножения и работы по их совершенствованию продолжаются. Готовы ли вы вернуться к своим старым проектам, если в этих алгоритмах появятся новые результаты?
В случае стандартной библиотеки её можно просто обновить.imanushin
29.10.2024 16:17Готовы ли вы вернуться к своим старым проектам, если в этих алгоритмах появятся новые результаты?
Если это было бы важным для производительности, то я бы начал бы с этого. Именно исходя из таких вещей я выбираю между тем же Python, Rust, .Net и пр. Всегда важно понимать, какую проблему мы решаем, и, если производительность этого куска программы важна на самом деле, то тогда лучше оптимизировать.
В случае стандартной библиотеки её можно просто обновить.
И нет. Перемножения матриц как раз нет в подавляющем большинстве стандартных библиотек. Оно будет в отдельных, подключаемых библиотеках. И да, их тоже необходимо обновлять и следить на совместимостью.
unreal_undead2
29.10.2024 16:17Оно будет в отдельных, подключаемых библиотеках.
В отдельных давно есть, будет и в стандартных. Хотя вопрос, насколько в libstdc++ будут вкладываться в микроархитектурную оптимизацию под конкретное железо.
unreal_undead2
29.10.2024 16:17то такие тривиальные вещи, как перемножение матриц, могут вообще почти не повлиять на сложность.
Эти "тривиальные" вещи могут не влиять на сложность описания алгоритма другому человеку, но при этом потреблять 90+% процессорного времени (как в каких нибудь нейронках). И написать свою реализацию, которая по максимуму использует возможности CPU, GPU и прочих акселераторов достаточно нетривиально. Так что я возьму скорее возьму библиотеку от вендора железа - или OpenBLAS при отсутствии, всё таки к ней Гото-сан в своё время приложился.
imanushin
29.10.2024 16:17но при этом потреблять 90+% процессорного времени (как в каких нибудь нейронках).
Самый главный вопрос, ответ на который необходимо четко понимать: "какую проблему мы решаем?"
Если перемножение матриц будет постоянно использоваться, да еще и с серьезной математикой, а вдобавок еще и с большим потреблением памяти, то будет один выбор (скорее всего, тут будет Rust или иной язык, а также библиотеки оттуда).
Если планируется получить очень большой долгоживущий сервис с громадным объемом бизнес логики, но с малым числом слабонагруженных реплик в k8s, то, скорее всего, выбор падет на JVM, а далее уже следует просто прагматично подбирать пакеты.
Если планируется очень маленький сервис без жестких требований по части типов, то может подойти и Python, но тогда потребуется серьезнее подходить к оптимизации математики.
Собственно, далеко не всегда отдельная библиотека принесет пользу. Условные Eclipse Collections помогут в Java, но не будут иметь смысла в Kotlin.
И да, где-то подключение еще одного пакета будет целесообразным, а где-то - нет. Самое важное - какую конкретно проблему мы решаем?
unreal_undead2
29.10.2024 16:17скорее всего, тут будет Rust или иной язык, а также библиотеки оттуда
Скорее бинарники от производителя железа, например MKL или cuBLAS. Да, я рассматриваю сценарий, когда мы долго (возможно, несколько месяцев на кластере) умножаем эти матрицы. Если это делается эпизодически на небольших матрицах - возможно, и простого кода с тремя вложенными циклами хватит.
mayorovp
29.10.2024 16:17Покрыта ли эта реализация графа тестами (не как обычно, парочкой, а полноценно, весь функционал)?
Как там у него - не знаю, но в целом как раз подобные алгоритмы гораздо проще покрыть тестами нежели бизнес-логику или UI.
Revolt-or-die
29.10.2024 16:17С другой стороны такие самописные реализации, без документации и падающие если их использовать не так, как автор задумал, часто работают по 20 лет в продакшене и кушать не просят. Т.е. то, что ее потом выкинут, потому-что не смогли разобраться это грустно, но оно себя окупит много раз.
unreal_undead2
29.10.2024 16:17Ну а настоящий сеньор сможет убедить руководство корпорации выложить реализацию в open source и сделать индустриальным стандартом )
DMGarikk
29.10.2024 16:17Чтобы убедить руководство корпорации, надо пробить свою активность через юристов, которые по умолчанию просто не захотят это делать. а тратить рабочее время юристов и сеньора на то чтобы согласовать вывод какойто софтины в опенсорс никто не будет, оно не принесет коммерческой пользы
p.s. внезапно я этим озадачивался, делали форк либы django-keycloak (с поддержкой последней версией кейклока и фиксом пары недоделок) гдето год пытались согласовать выкладку его на гитхаб в виде форка...и все погибло у юристов в плане документального оформления..
unreal_undead2
29.10.2024 16:17Я согласен, что это непросто (сам выкладывал только одну мелочёвку, и то пришлось несколько месяцев ждать разрешений), но всё таки возможно и в больших корпорациях это более-менее постоянный процесс.
kenomimi
29.10.2024 16:17Во-первых, надо разделять игрушки-развлекушки и бизнес. Бизнесу нужно делать фичи, чинить баги, и чтобы быстрее. Бизнесу нужен не многорукий шива-хакер, знающий кванмех и криптографию, могущий поломать Пентагон и написать игру в машинных кодах, нет... Бизнесу нужен техножрец, который, даже не понимая сути, может локализовать/решить проблему быстро, и так, чтобы решение прошло тесты. Не оптимально? Сервера стоят дешевле человекочасов, докупим железа. Может поломаться через 5 лет? Вот через пять лет и будем думать, а сейчас чиним быстро.
Во-вторых, происходит тоже самое, что еще недавно происходило в медицине... Когда-то был один доктор на все болезни
в плаще и с клювом, потом началось дробление. И чем дальше шло развитие, тем дробление было мельче, специализации уже, знаний всё больше... Появилось профильное образование, лицензирование, и так далее. Сейчас никому разумному уже не взбредет в голову самого себя назначить доктором и пойти лечить больных, когда как 300-400 лет назад это было нормой вещей. IT сейчас на этапе перехода от врачевателей с клювом к современной медицине, так сказать... И да, окулист понятия не имеет, как собирать травы, кардиолог не знает про молитвы и лечебные заклинания, но в целом современная система работает намного эффективнее одиночек-самоучек, какими гениальными они не были бы.jackshrike
29.10.2024 16:17самого себя назначить доктором и пойти лечить больных,
два слова - "народный целитель".
когда как 300-400 лет назад это было нормой вещей.
чушь. могло прилететь от гильдии (корпорации) медиков и по закону и по понятиям так что мало не покажется.
M-M-I
29.10.2024 16:17Вот через пять лет и будем думать
это наверное самое жопоподжигающее)) я своим руководителям и всем всем всем кричал, что если сделают так как они хотят, то потом вылезет такое, что Кардашьян обзавидуется... вот, сидим, разгребаем.
Seraphimt
29.10.2024 16:17Если вам охота докапываться до мелочей в аналогии с медициной, вот вам другая - математика. Лет 150-200 назад почти все математики были универсалами, да ещё зачастую и физиками в придачу. Сейчас же все строго разделены, всю современную математику не вместит в голове даже сотня гениев и какой-нибудь специалист по ТФКП не знает, что там у занимающихся теорий групп творится.
Wesha
29.10.2024 16:17Вот через пять лет и будем думать
Я на своём рабочем месте уже более десяти лет. Теперь думают.
mclander
29.10.2024 16:17Бизнесу нужны прогнозируемые сроки. Путь долго, пусть дорого, пусть доп расходы на поддержку. Но и нужно знать, когда они смогут пользоваться инструментом, который им для чего-то нужен.
Alexey2005
29.10.2024 16:17Медицина тоже куда-то не туда движется. Ещё в середине 90-х постановка диагнозов происходила не в пример быстрее. Большинство диагнозов ставил напрямую терапевт путём осмотра-ощупывания. И простейшие процедуры тоже он производил. А где вы сейчас найдёте терапевта, способного, к примеру, удалить гнойную пробку из миндалин? Или который на всякий случай прощупывает вам шейные лимфоузлы? Это всё осталось в прошлом.
Знаете, каждый раз, когда я приношу свою кошку в ветклинику, я ей дико завидую. Потому что у неё сразу, на месте, берут анализы, через полчаса-час уже готовы результаты, и сразу назначено лечение.
А что происходит, когда я прихожу в поликлинику для людей? Сперва попадаю на приём к терапевту, отстояв две очереди (в регистратуру и собственно к терапевту). Он тут же выдаёт направление к узкому специалисту, в данном случае к дерматологу, который принимает только с утра, так что идти к нему придётся уже на следующий день.
Дерматолог сразу же отправляет на сдачу кучи анализов. При этом часть анализов делается только по нечётным числам, часть только по средам и т.д. Так что отстоять в очередях приходится три раза, и ходить три дня подряд.
С результатами анализов снова идём к дерматологу. Тот, изучив их, говорит, что проблема не на его стороне (вызывается какими-то проблемами с ЖКТ) и переадресует к гастроэнтерологу.
К нему, понятно, также можно попасть лишь на следующий день. Приходим, он в свою очередь выдаёт направления на анализы. Минус ещё два дня и две очереди.
Приходим к нему с результатами анализов и наконец-то получаем диагноз и лечение. Финиш.
Вот только какого хрена больной человек из-за любого пустяка вынужден полмесяца ходить в поликлинику как на работу? Только мне кажется, что тут что-то не так?
rinace
29.10.2024 16:17Наверное мы ровесники
Я помню как было
https://youtu.be/zWZybFMQNqw?si=MARbyD5F2eFbAJGw
И мне невыносимо грустно от того, что стало
DMGarikk
29.10.2024 16:17всё это осталось, ладно вам прям печалится, просто людей в отрасли стало больше
грубо говоря было раньше "5тыщ настоящих программистов, который ооо, всё изобретали, воевали с машиной"...и сегодня ... 5 тыщ настоящих программистов так и осталось, и ещё 100500 тех кто просто за бабки работает...этих 100500 мы тут все и наблюдаем и за ними 5тысяч теряются
а те самые "настоящие", это небольшое подмножество сеньоров/тимлидов/архитекторов которые изобретают нынешние огромные продукты... те кого выперли из мейнтейнеров линукса... никуда они не делись
TheCoolKuid
29.10.2024 16:17И что включается в понятие настоящие?
sergey-gornostaev
29.10.2024 16:17Думаю, автор комментария использует термин "настоящий программист" в контексте взглядов автора поста.
TheCoolKuid
29.10.2024 16:17Даже из поста не ясно о чем речь. Пропали инженеры с горящими глазами? Нет, я лично знаком с парой. Пропали инженеры? Да нет, прорывные технологии продолжают выпускаться - тот же ChatGPT. Пропали алгоритмисты? Да нет, таких я тоже знаю лично, да и литкод и все похожее процветает. По большому счету очередная история как в моей молодости пломбир был вкуснее. Автор и автор комментария имеют полное право ностальгировать по прошлому, но вот устраивать дележку на правильный и неправильный некорректно.
sergey-gornostaev
29.10.2024 16:17С постом как раз всё ясно - ворчание на тему того, что в отрасль за деньгами пришло много неувлечённых людей. Я с вами согласен, тоже не люблю деление программистов на настоящих и нет.
artemmoscow Автор
29.10.2024 16:17Нет творчества. Ты не можешь сказать что писал программу, ты ничего не создал, а обслужил код. Работать стало тяжелее - не нужно испльзовать ум и фантазию, а только память. Да и нагрузка возрасла в разы.
kitmarty
29.10.2024 16:17Какое творчество может быть во внедрении очередной ERP или какой-нибудь BPMS? Утилитарные задачи - утилитарные исполнители. Такую работу можно делать хорошо и плохо, быстро и медленно и т.д. Можно что-то придумать оригинальное, но это не творчество.
Может свой пет-проект - это подобие творчества или изобретение собственных "велосипедов" (желательно не на работе).
Но раньше было лучше, по крайней мере новую работу было искать проще)
artemmoscow Автор
29.10.2024 16:17а на внедрении ERP такие вопросы никогда и не справшивали. Это вопросы или от руководителя которому нужен специалист в области в которой он не разбирается и хочет проверить хотя бы интеллект ну или просто контора, которая считает, что им нужны люди с нестандартным мышлением (в их понимании). Я начал сталкиваться что стали интересоваться оценками в дипломе, который получил 15-20 лет назад. У кого то и такое понимание ума
vanxant
29.10.2024 16:17Какое творчество может быть во внедрении очередной ERP
Да там как раз именно творчество. Большинство проектов внедрения ЕРП заканчиваются неудачей. Именно потому, что внедрять нужно творчески, в чисто гуманитарном смысле. Здесь видим и восхищаемся, здесь не видим и рыбу заворачиваем. А приходят какие-то унылые задроты и начинают пытаться учитывать всё честно. Конечно такое не взлетит.
yarrrman
29.10.2024 16:17Любое внедрение, может оказаться очень творческим, особенно на крупном предприятии. А писать в пятисотый раз быструю сортировку... Ну, такое себе творчество.
GothicJS
29.10.2024 16:17Наоборот, именно ум и фантазия требуется. Просто сводить все к алгоритмам и условному "программированию на спектруме" это очень узкое понимание ума и фантазии.
artemmoscow Автор
29.10.2024 16:17так это вы передергиваете и сводите мои слова что программировать на спектруме это круто. Вы свои тезисы чем-то подтверждайте, а каменты сводящиеся к КГ/АМ читать не интересно, да и штамповать такое много ума не надо и как раз признак неумения мыслить системно
GothicJS
29.10.2024 16:17Ну вы же свои тезисы не подтверждаете, и много ума, чтобы такую статью написать не надо, вот вам и комменты соответствующие, в уровень.
Никто ж не обязан с вами соглашаться, а при выражении несогласия не обязан отчитываться. Поэтому вам и отвечают на уровне декларирования и аналогий, потому что иначе пришлось бы целую работу провести, чтобы лично вам объяснить, почему дважды два четыре.
WASD1
29.10.2024 16:17По большому счету очередная история как в моей молодости пломбир был вкуснее
Да нет же. Просто обычная жизненная история: с ослаблением отбора падает средний уровень навыка.
Другой вопрос, что "вот такой вот как сейчас рынок", - это факт объективный. На него можно жаловаться его можно не любить, но это объективный факт. С ним вам жить в любом случае.
А вопрос, который вызывает подозрения - как такой замечательный супер-программист оказался +/- в медиане рынка на +/- рядовых позициях. Что-то какое-то несоответствие заявленной позиции и наблюдаемых эффектов.artemmoscow Автор
29.10.2024 16:17Я не писал, что я замечательный, я средний (средний среди опытных). И за запрплатой не гнался. Лучше иметь 2 средний работы или другие доходы, чем рвать одно место, но зарабатывать на 20% больше чем сейчас.
WASD1
29.10.2024 16:17Ну вы средний по тем временам (когда фильтр входа в профессию был "спать не могу как интересно пока программу ХХ не допишу" - я если что бывало до 2 ночи лежал думал, а потом когда родители засыпали вставал и за комп дописывать прогу садился).
По нынешним у вас фора в виде офигенного буста в начале карьеры + 15 лет опыта.не гнался
Кажется (могу ошибаться, но неоднократно видел такое в жизни) вы попали в ту же ловушку, что и "блатной продавец в СССР" -> "продавец пятёрочки" (к счастью для вас - на пару уровней выше).
Зачем мне напрягаться мне и так неплохо?
А потом прогресс и технологичность дошли до вашей области. И всем кто не напрягался и почевал на лаврах присунули "трекер рабочего времени".
Теперь напрягаться по стрессу и/или часам работы - что в линейном персонале что в условных архитекторах/principal engineer надо примерно одинаково. Только у архитектов и ЗП повыше и задачи поинтереснее. А прыгнуть с вашей текущей линейной позиции в principal - уже ой как не просто.
Wesha
29.10.2024 16:17что включается в понятие настоящие?
(Кладя руку на плечо, задушевно:) Скажите, в каком году Вы собрали свой первый... нет, не компьютер — логический элемент?
Riketta
29.10.2024 16:17Программисты 20 лет назад: один придумал Clang, LLVM, Swift, другой пакет инструментов Sysinternals, третий ОС свою написал. И все это в основном на энтузиазме.
"Программисты" сейчас: "ну я это, пук срень, жсончик тут не могу сформировать без гугла на жабаскриптике".
sobeskiller
29.10.2024 16:17Не свернула, а подожрали low hanging fruits. Это в 95м можно было в одну харю написать на Дельфи какой-нибудь "календарь месячных", и даже зашибать на нём бабло. Альтернатив-то особо не было. А сейчас на любой чих и пук уже готового - горсть россыпью, обвыбирайся. А что-то более масштабное пишется только большими командами. Со всеми из этого вытекающими.
rinace
29.10.2024 16:1795м можно было в одну харю написать на Дельфи какой-нибудь "календарь месячных", и даже зашибать на нём бабло. Альтернатив-то особо не было.
Вы не правы от слова совсем. Все с точностью наоборот . Как раз тогда альтернативы было не просто много а очень много . Все же только начиналось. Полная свобода и инициатива во всем. Манагеров , еоцчероа , скрам- мастеров и прочих попутчиков прос о не было в природе . Я участвовал в информатизации республиканской налоговой. Перед этим был тендер и сравнительные испытания проектов . Вот прям настоящие испытания на уровне - а как ваша система справится с такой ситуацией , а ваша ?
Как сейчас происходит выбор поставщиков я не хочу распространяться ......
Тогда был выбор всего - начиная от железа , кончая ос, СУБД и даже языка программирования .
Я не буду спорить, но утверждать , что монополизация и поглощения и слияния почему то обошли IT , точно не буду.
panzerfaust
29.10.2024 16:17Как раз тогда альтернативы было не просто много а очень много
Тогда был выбор всего - начиная от железа , кончая ос, СУБД и даже языка программирования .
Возьмите 2 столбика 1994 и 2024 и выпишите сколько было там и там СУБД, ОС и ЯП. А еще мессенджеров, соцсетей, банковских приложений, поисковиков, облачных сервисов, IDE, видеохостингов, VDS. Про железо даже говорить смешно.
artemmoscow Автор
29.10.2024 16:17Сейчас postgres и mssql.. ну по сути все. В конце 90х была россыпь в провайдерах odbc - dbf, paradox, db2, sql server кстати уже был по моему, плюс всякие фокс про, клипперы, ms access - причем все актуальное. Для банков понятное дело Oracle. Правда языков было всего 2 - паскаль (делфи) для масс и c/c++ для продвинутых.. Причем на чистых плюсах мало кто писал тогда. Ну да, еще ассемблер - что бы носить гордое звание системный программист, прикладников тогда не особо уважали. Не помню что можно было получить респект за календарь для месячных, тогда рулила демо-сцена и полиморфные вирусы - как признак мастерства и небожителя.
Areso
29.10.2024 16:17а Оракл? А Мускуль\Мария?
А еще есть целая куча т.н. "претендентов" - кокроачи, тидб, и т.п., десятки их.
А еще бывают всякие Монго и т.п.rinace
29.10.2024 16:17а Оракул
А расскажите как сейчас Оракл? Особенно на уровне предприятий . Я могу рассказать , как сложилось у моих коллег которые ушли в Оракл с оутсортинга, ну вернее детали то я не расскажу конечно, но намекнуть могу.
Я в PostgreSQL пошёл.
Areso
29.10.2024 16:17Потихоньку заменяется на Постгрес, но в микросервисной архитектуре команды могут сами выбирать себе СУБД по вкусу.
Writer4
29.10.2024 16:17Так все с Оракла пытаются свалить на Postgre. Масштаб бедствия зависит от количества имеющегося PL/SQL. Довольно непросто переносить систему с 2-3 млн строк пакетов. В этом случае даже проще просто с нуля передизайнить, но тут проблема, что эти 2-3 млн строк не просто там появились, там куча функционала и знаний, которые не хочется терять.
artemmoscow Автор
29.10.2024 16:17по моему мускуль и оракл в целом ушли с дистанции? Я не встречаю в вакансиях. Так то можно много чего вспомнить, tinySql еще какой то был, файрбейз.. но на практике 90% парочка мною упомянутых
venanen
29.10.2024 16:17Сейчас postgres и mssql.. ну по сути все.
Собственно, ответ на заголовок статьи. Оно никуда не сворачивало, это изначальный вектор.
https://dev.to/shreyvijayvargiya/list-of-45-databases-in-the-world-57e8 - а ведь там нет, например, ClickHouse.
Языков было не два, а гораздо больше. Некоторые до сих в проде - например, Cobol.artemmoscow Автор
29.10.2024 16:17можно вспомнить вижуал бейсик тот же, клиппер.. ну они по сути были разновидностью всего того же, да и мало их было. В целом - плюсы были основным коммерческим языком, и долго казалось, что так будет всегда. По сути делились разрабы на плюсовиков и всех остальных.
playermet
29.10.2024 16:17Какой-то уклон в программистский аналог АУЕ - критерии респекта, неуважение к прикладникам, и т.д. Демо-сцены это очень круто, трудоемко и результаты красивые, но алгоритмически никакого небожительства там нет, и само написание кода проще чем под современные процессоры. Написание вирусов является одной из тем в учебниках по ассемблеру для начинающих, а полиморфность достигается тривиально.
artemmoscow Автор
29.10.2024 16:17Я таким в 15 лет занимался но не уверен что современная молодёжь заточена под такое. Пусть это и не ракет саенз но элемент творчества был. Сейчас мне сложно описать чем вообще занимался. Какие то переносы и интеграции кода, митинги, речью.. за пол года на проекте я не знаю его функционал
vvbob
29.10.2024 16:17Вот да, натурально АУЕ какое-то! Написать какую-то довольно бесполезную демку для древнего компа - "это респект и уважуха", а написать какую-то офигенно нужную фичу для бизнеса - фу, "быдлокодер-формошлеп-крудопил", притом что второе может потребовать усилий на порядок больше чем первое.
artemmoscow Автор
29.10.2024 16:17не может. ваша супер полезная программа под офис 97 на вижуалбейсике по определению проще
vvbob
29.10.2024 16:17Прикиньте, под офис 97 уже лет так 20 с гаком никто ничего полезного не пишет, и вижлбейсик это древнее нечто, которое далеко от современной разработки примерно так-же как далека от нее демка на Спектрум. Вы безнадежно отстали от современной разработки, увы.
artemmoscow Автор
29.10.2024 16:17Я написал что во времна моей юности системные программисты не уважали прикладников. Вы пишите что это странно, т.к. системные программисты пишут древние как говно мамонта компы, а прикладники современные системы. Вижу что логика вышла покурить. Системные программисты на крутейших по тем временах 486dx120 заранее считали себя говном мамонта и ненавидели энтерпрайз программистов из будущего, вы себе такую картинку нарисовали? Ниче, что они соревновались с программистами из своей эпохи а не текущей? Или для вас, как современного разработчика и это надо было уточнить?
vvbob
29.10.2024 16:17Логика у вас вышла покурить. Отвечал я не вам и не на ваше сообщение, но вы за каким-то лешим влезли со своим вижлбейсиком. Особенно странна ваша интерпретация моего текста, где вы там страдающих комплексом неполноценности системных программистов на 486-х увидели, вообще решительно непонятно, это уже СПГС уже какой-то запредельный.
artemmoscow Автор
29.10.2024 16:17тогда демки не были совсем уж бесполезными, это было что-то вроде бенчмарака и концепт-кара, показывало потенциальные возможности компов, это было что-то вроде спорта, аналог лит-кода современного. А вы явной манипуляцией заниматесь, берете школьные воспоминания из 90х и сравниваете с современностью.
sobeskiller
29.10.2024 16:17тогда демки не были совсем уж бесполезными, это было что-то вроде бенчмарака и концепт-кара, показывало потенциальные возможности компов
И вы хотите и 30 лет спустя "показывать потенциальные возможности компов"? Совершенно естественно что за 30 лет индустрия выросла из "демонстрации потенциала" в стандартный промышленный конвеер.
artemmoscow Автор
29.10.2024 16:17Сейчас так же народ с нейросетями играется и выкладывает в сеть асболютно бесполезные, но эффектные демки, которые в будущем станут основой для конвеера
unreal_undead2
29.10.2024 16:17И сейчас системное программирование никуда не делось и человек, разбирающийся в потрохах ядра линукса, llvm или Postgres и способный их развивать может вполне нормально зарабатывать, занимаясь любимым делом.
artemmoscow Автор
29.10.2024 16:17В роли такого же винтика, работая по скраму, только на пустом и безперспективном рынке.
unreal_undead2
29.10.2024 16:17Скрам для продуктовых команд, в R&D - когда разрабатываются прототипы реально новых фич - несколько поспокойнее. И насчёт "пустого бесперспективного" не понял. Таких специалистов с руками отрывают и в обозримом будущем потребность не уменьшится.
artemmoscow Автор
29.10.2024 16:17У меня есть плюсы в бэкграунде. Смотрел по вакансиям, предложений на порядок меньше, чем под веб, а з.п. в целом ниже. И скилзы хотят такие, которые потом сложно продать
unreal_undead2
29.10.2024 16:17Важны не сами плюсы, а экспертиза в конкретной области. Тогда вы знаете, какие компании в этой области работают, знаете людей в этих компаниях и они знают вас. Публичных вакансий может и не быть.
artemmoscow Автор
29.10.2024 16:17смысл какой? Получить слабовостребованную экспертизу и привязаться к одной конторе, которая сможет тебе выламывать руки как хочет. Сомневаюсь, что за такое платят 500K+. Скорее так же или ниже рынка в целов (т.е. от силы 350). По факту большой риск просто профессионально похоронить себя, а плюсы какие? Тебе так же будут говорить - дескать творчеством будешь заниматься дома
unreal_undead2
29.10.2024 16:17Таких контор даже у нас в стране в большинстве областей не одна, так что поторговаться можно.
Сомневаюсь, что за такое платят 500K+
Продолжайте сомневаться )
ForestDront
29.10.2024 16:17llvm нафиг никому не сдалось. 5 лет работал с llvm, а потом 6 лет не мог найти работу по этой теме
unreal_undead2
29.10.2024 16:17Странно, что вы за эти пять лет не узнали про другие места, где оно тоже нужно. Навскидку - если сможете добавить нормальную автовекторизацию для RISC V, уверен, что Yadro вас точно примет (если что - я с ними никак не связан, просто немного представляю, что и где происходит).
sobeskiller
29.10.2024 16:17Не помню что можно было получить респект за календарь для месячных,
Это видимо потому что вы с целевой аудиторией близко не общались. ;) У демок и вирусов тоже была своя ЦА. А не потому что эти продукты сами по себе что-то значили.
Самое главное что рынок таких программок был пуст, поэтому в одиночку можно было состряпать что-то восстребованное ЦА и получить какое-никакое призвание (и $$$). А сегодня можно сколько угодно писать тетрисы, но Пажитновым вам уже никогда не стать.
Но это не относится к СУБД, ОС и прочим софтам для налоговых. Это изначально большие объёмы работ, большие деньги - а значит корпораты. А корпораты это [почти] всегда работа обычным заменяемым винтиком.
sshikov
29.10.2024 16:17Ну, давайте так - может у кого-то все только начиналось, а я таки в 95 уже 20 лет как программировал. И я вам так скажу: СУБД, ОС и ЯП уже было достаточно. Это не значит, что они были те же, что и сегодня, нет. Но разнообразие уже давно наблюдалось. Вас же не удивляет, надеюсь, что лисп у нас 1958 года рождения, а хаскель - 1990? Разумеется, все что касается интернета, с тех пор изменилось радикально.
Это я к тому, что считать в штуках тут неправильно. Я бы с другой стороны зашел бы: вот у меня чисто в качестве хобби стоит задача анализа видео. Т.е. выделение в кадре объектов, измерение их скорости, вычисление точек пересечения траекторий и т.п. И хотя лично я не готов в одно лицо прямо сесть и такое реализовать, я точно знаю, что сегодня эта задача вполне решаема, и вопрос уже скорее стоит так - решить ли ее на телефоне, или лучше в облаке, и что выгоднее? Я думаю вы легко найдете тут на Хабре пару статей за неделю, где описаны подходы вот прямо к этой задаче (т.е. анализ матчей в футболе, скажем). При этом в том же 1995 такую задачу я с трудом могу себе представить - хотя бы по причине слишком разного железа (в 1995 у меня был мейнфрейм с 16 мегабайтами памяти, и парой гигабайт дисков, что сегодня довольно смешно выглядит).
panzerfaust
29.10.2024 16:17Это я к тому, что считать в штуках тут неправильно
Вы ветку читали? Один человек говорит, что раньше было много низко висящих плодов. Ему отвечают, что нет, всего было "не просто много а очень много". Ну я и предлагаю сравнить то "много" и наше "много". Если не уходить в "трава зеленее" и "у меня при Сталине мейнфрейм стоял", то в общем про низко висящие плоды все так и есть. Поэтому индустрия по-другому выглядит. А не потому, что она свернула не туда.
По такой логике горнодобыча тоже свернула не туда. Раньше палкой ткни в гору - там уже руда. А сейчас это сложная многомиллиардная индустрия без всякой романтики.
sshikov
29.10.2024 16:17Смотрите, с вашей постановкой вопроса я скорее согласен, чем с противоположной. Индустрия никуда "не туда" не сворачивала, она развивается, хотя иногда и не в тех направлениях, куда предполагали 10 лет назад. И мой пример про задачу как раз к тому, что наши задачи тоже сильно усложнились.
Отвечаю же я на конкретное предложение посчитать в штуках языки, ОС или СУБД. Конкретно лишь оно мне кажется малоосмысленным. Многие сегодняшние популярные языки и ОС и СУБД тогда уже существовали. Что мы принципиально нового имеем сегодня в области реляционных СУБД, если к 1995 оракл и DB2 уже были написаны? Нам точно их количество важно? Потому что если их в штуках считать, то была например такая СУБД Informix, довольно популярная когда-то. Где она сейчас? Я думаю мало кто сходу скажет (при том что она существует). Нишевый продукт. Это как оценить, как прогресс или наоборот?
IvanGanev
29.10.2024 16:17Романтический флер исчезает со временем из любой профессии. Когда-то электрики тоже были полубогами которые делали невероятные вещи. Прикол при чем в том что современный электрик даже может быть и круче чем электрики конца 19 века, но это никого не волнует - романтики нет. Пожалуй единственная профессия из которой романтика никогда не исчезнет - это профессия военного.
Stawros
29.10.2024 16:17Пожалуй единственная профессия из которой романтика никогда не исчезнет - это профессия военного.
Если военные будущего будут сидеть за джойстиками в офисе, то возможно и их постигнет та же судьба.
IvanGanev
29.10.2024 16:17Нет. Даже сидя за джойстиками в офисе от их действий будет зависит жизнь и смерть, а где смерть там и романтика.
ClayRing
29.10.2024 16:17Чья жизнь и смерть? С той стороны тоже военные за джойстиками сидят.
playermet
29.10.2024 16:17Даже если допустить что всю пехоту заменили на роботов, а все операторы сидят в недосягаемых конвенциональным оружием подземных бункерах далеко в тылу, любой успех одной из сторон означает движение по территории. А на территории живут обычные люди, даже если это город который год под обстрелами.
ru1z
29.10.2024 16:17единственная профессия из которой романтика никогда не исчезнет
Не помню, чтобы такую профессию кто-то в окружении считал романтичной. Может в детстве разве. Взрослея наверное люди либо по деньгам выбирают (точнее сравнительно более простым методам заработать на жизнь, например, экономисты и может те же военные) или по интересам (например, программирование). Романтика она в детстве больше - стать космонавтом, лечить людей и т.п.
Format-X22
29.10.2024 16:17Я хотел стать пилотом, но фильм Матрица сказал мне что программистом быть круто. Забавно что фильм на 99.9% состоит не из процесса программирования, но это не помешало проникнуться идеей и начать писать код.
gsaw
29.10.2024 16:17Да, раньше достаточно было знать, где находится any key и ты был Компьютерщиком. Без ваших энтих интернетов, с парой книжек, знаешь, как отредактировать config.sys и оно потом все равно запускалось. :)
Имхо нынче проще стало получить образование программиста. Да даже не образование, а просто базовый набор программиста. Людей стало больше, которые могут включить компьютер и установить винду, да даже ubuntu. То-есть кодеров навалом. ИИ теперь еще помогает писать вполне рабочий код.
Как у Пушкина. "Мы все учились понемногу Чему-нибудь и как-нибудь, Так воспитаньем, слава богу, У нас немудрено блеснуть. "
Ну и индустрия поменялась. Все постепенно утряслось, все стандартизировано, унифицировано, все основные принципы утряслись.
Недавно прошелся по выставке старых автомобилей. Каждый автомобиль произведение искусства. Собирались в ручную. Не то, что нынешние безликие кары. Попался недавно ролик, как в Порше подгоняли двери в автомобилях в 50-60-х. Щель между кузовом и дверью заливали оловом, а потом ножом вручную, пока горячо, прорезали щель! Получалась подгонка двери с миллиметровым зазором. Сейчас штампованные кузов и двери подходят намного точнее (на Порше), целый процесс подгонки отпал сам собой.
Что бы создать продукт уже не нужно ваять свои библиотеки, выдумывать новые самые-самые фреймворки. Большинство продуктов создаются на уровне абстракций и идей. Тут уже не кто лучше сделает, а кто быстрее войдет в рынок.
Короче программистов теперь как гумна, потому время свитеров и бороды ушло, и свое взял бюрократизм и офисная культура. Отношение другое. Попроще. Встань в строй и не высовывайся. Одних знаний программиста недостаточно, надо теперь еще уметь в офисные игры иначе тебя просто не поймут.
artemmoscow Автор
29.10.2024 16:17Требования не только к программистам растут. Раньше были отдельные профессии - машинистка, переводчик. Сейчас это просто один из скилов в списке других. Дума. что и тот же бухгалтер или юрист при СССР знал меньше чем современный.
ForestDront
29.10.2024 16:17Раньше IT было фронтиром, теперь - инфраструктурой. Стада больше не ходят по прериям, стойловое содержание эффективнее. И только старые ковбои грустно поют песни об ушедших днях.
vvbob
29.10.2024 16:17Тоже писал еще на Спектрум, потом на писюке сначала на Турбо Паскале, потом на Делфи, С++. Да и то время застал, когда ты в одно лицо делал все от кода до БД и пользовательского интерфейса. Да, это было прикольно по своему, но.. Ох уж это "но". Заработки тогда были ну так себе совсем, по крайней мере в провинции, получать 500 баксов в месяц - это было почти мечта, столько в Москве платили. Да и мозго..ли хватало всякой, как раз из-за этой универсальности. То сервак упал посреди рабочего дня и надо с горящей задницей его поднимать из мертвых (никакого резервирования нет, и сервак уже давно еле дышит ,потому что экономия!), то какая-либо Мариванна из бухгалтерии опять не может свести
счеты с жизньюбаланс из-за того что списывала траты не на тот счет, то внезапно надо ехать куда-то в другую часть города ,потому что там в филиале "все не работает" (очередная мариванна не осиливает отключения капслока) и т.д. и т.п...Как по мне - сейчас лучше. Да, может задачи временами и скучнее, хотя не всегда, но зато и з/п хорошая и всякой левой фигней тебя не озадачивают, и не приходится заниматься компьютерных ликбезом среди "мариванн".
rinace
Спасибо .
Я помню те времена .
Wesha
Я помню!