Comments 182
В С++ сейчас каждые 3 года новый стандарт. А работы существенно меньше и оплачивается ниже рынка. Сам ушел с С++/Qt на Golang. Может с ситуацией импортозамещения что-то изменится....
РФ конечно (Ростов-на-Дону). Отрасль - десктоп разработка, системное программирование.
https://rostov.hh.ru/vacancy/81389407?from=vacancy_search_list&query=программист С
Ну... Строго говоря, чистый С в целом более способствует.
Чтобы писать высокопроизводительный код на С++ надо очень хорошо знать как устроены его библиотеки (та же stl) внутри. Иначе, при бездумном использовании, рискуете нарваться на множественные динамические выделения/освобождения памяти, что не очень способствует высокой производительности.
Также бездумное использование исключений может весьма отрицательно повлиять на производительность.
Так что тут прежде всего в голове, а потом уже в языке дело.
Есть конкретные примеры?
На самом деле *void это просто указатель на область памяти. И компилятору совсем не надо через него продираться
Я вот сейчас работаю с языком, где указатели не типизированы (точнее, там два типа - указатель на данные и на процедуру). А чтобы с указателем работать, нужно объявить связанную с ним переменную. Можно и несколько. И разных типов.
А вообще, написать абы какой код и надеяться что компилятор за вас вывезет, ну такое себе...
И любой универсальный метод может проиграть в скорости написанному руками под конкретную задачы с учетом специфики данных.
Как пример. Есть две строки суть которых набор двухсимвольных кодов. Их надо сравнить. Причем, порядок кодов не играет роли. Только наличие в строке. Т.е.
D1C2N1 == C2N1D1
Казалось бы отсортируй и сравнивай. Но с учетом большой плотности вызовов это непозволительная роскошь.
Вот и приходится включать мозг. Оказалось, что есть алгоритм со сложностью O(n). Т.е. быстрее любой сортировки.
И таких примеров полно в личной практике
std::sort компилируется в нулевой оверхед потому что для массивов таких размеров внутри вызывается insertion_sort (2 цикла), который естественно оптимизируется лучше, чем сложный qsort
Немного магии, меняем массив на {3, 5, 7, 2, 2} и оптимизация уже не работает https://godbolt.org/z/adjcPvsf7, по крайней мере на шестнадцатом clang и тринадцатом gcc все компилируется в ту же порнографию
Более того, на всех других массивах, что я пробовал, получается то же самое
Это какой-то специальный массив, подобранный для C vs C++ холиворов?)
Что внутри stdsort происходит? Разверните.
Что происходит внутри unordered_set и во что выливается toSet(s1) == toSet(s2) ? Разверните. Вы уверены что там внутри не будет поэлементного сравнения "каждый с каждым"? Плюс еще формирование наборов (там точно нет динамического выделения памяти под каждый элемент)?
Это типичное заблуждение "фреймворкеров" - кажется, что если все укладывается в 2-3 строки кода, то и в исполняемом виде будет те же самые 2-3 строки кода. Но это не так.
Чтобы сравнивать и понимать нужно брать хороший профайлер и смотреть - что там со стеком происходит (разворачивать-сворачивать стек тоже не бесплатно).
Что там с динамическим выделением памяти - это тоже небесплатно.
Если говорить о моем варианте, то там цикл по количеству элементов и внутри цикла две операции побитового XOR и три операции сложения целых чисел. на выходе еще операция побитового сдвига, две побитовых AND и операция сложения двух целых чисел.
Все. Больше там нет ничего (никаких динамических выделений, никаких конструкторов, никаких лишних вызовов функций и образованием нового уровня стека). На выходе сравниваем два целых числа.
Фактически - это своеобразный хеш, формируемый с учетом особенностей входных данных. Т.е. мы не идем "в лоб" сравнивая два массива, но считаем хеши и сравниваем их. Нам не надо знать чем отличаются массивы. На надо только знать совпадают они или нет. И решаем вот эту конкретную узкую задачу.
Если пойти еще дальше, то один набор хранится в таблице и может считаться один раз (при занесении в таблицу). и тогда хеш считаем уже не два раза, а один (старый хеш хранится в таблице и подтягивается при чтении записи, новый хеш считаем, если отличается - изменяем запись в таблице с занесением нового хеша). И сразу сокращаем в два раза время на операцию сравнения.
Почему это важно (скорость)? Потому что задача на самом деле в поиске совпадений по ряду признаков (строки - коды по каким признакам есть совпадения) двух наборов данных. Один набор порядка 50млн записей, второй - ну несколько сотен тысяч записей. И сравнить надо каждую с каждой. Естественно, что там на каждом этапе такое вот - выбор самого быстрого варианта из всех возможных. С максимальным учетом специфики данных.
Все подобные задачи у нас прогоняются через PEX (Performance EXplorer). Где можно смотреть полную статистику, с разворотом стека - там будет видно какая функция сколько раз вызывалась, сколько процессорного времени и ресурсов занимает и т.д. и т.п.
Вы пытаетесь сравнить теплое с мягким и из этого делаете вывод, что C++ лучше)
Если мне не изменяет склероз, std::sort использует 3 алгоритма внутри: insertion_sort для мелких массивов, собственно qsort, и heap_sort если qsort начинает слишком глубоко проваливаться в рекурсию
Сравнивать его с голым qsort, естественно, нельзя
Я уже написал выше - в данной конкретной задачке сортировка вообще не нужна :-)
Если же говорить о сортировках, то опять по задаче. Если речь идет о некоем кеше, который заполняется один раз и потом по нему 100500 раз что-то ищем - тут выгоднее сортированный массив.
Если идет постоянная работа с данными (добавили - ищем, удалили - ищем) - сортированный список ключ-данные где нет отдельной операции сортировки (новые данные сразу вставляются "по месту"). Хотя в целом поиск по такому списку насколько медленнее чем двоичный поиск по сортированному массиву, но в целом будет быстрее т.к. нет операции пересортировки после каждого изменения данных.
открою страшную тайну. Действительно высокопроизводительные библиотеки в HPC и около пишутся до сих пор в основном на C, С + интринсики, ASM ну и да, до сих пор Fortran (ну это правда чуть меньше уже, но кода много на нем еще поддерживается в быстрой математике).
Ушел с С++ после boost. Да, отличная штука, как и все остальные прибамбашки. Но мозг ломает, особенно то, что компиляторы по разному работают. Но жить будет, С99 точно.
Меня больше напрягает что у каждого компилятора свой С++, а комитет пытается лишь связать их всех вместе чтоб это был именно С++ а не С++gcc_edition. В других языках ситуация по лучше, ибо компиляторы и стандарты всегда одни, максимум мажорные версии не будут совместимы друг с другом.
Из-за таких приколов в С++, некоторый код просто не работает при использовании другого компилятора и приходится использовать минимум "кор-фич", ибо неожиданно какой-нибудь clang не будет иметь то что имеет mvsc или даже gcc, потому что clang посчитал что эта фича не нужна в языке. -конец-
Работаю на С++ в embedded, в частности в автоиндустрии. Германия. Я не люблю мериться зарплатами, ибо много ещё факторов, опытный разработчик на Коболе может зарабатывать в разы больше вообще кого-либо в программировании. Но я не жалуюсь, в общем не сказать что тут платят копейки.
Ну, как правильно заметили уже "новый стандарт" в С++ это "мы тут поправили косяки, которые притащили в прошлом стандарте, добавили новых, плюс подсмотрели в языке ХХХ классную фичу и перетащили ее к себе".
Что касается оплаты... Если работать только ради денег, то любая работа быстро надоедает. Когда сам процесс не доставляет удовольствия, напрягаться только ради результата все сложнее и сложнее.
Сам ушел с С++/Qt на Golang. Может с ситуацией импортозамещения что-то изменится....
На мобильной ОС Аврора, как я понял, стек разработки как раз С++/Qt. Есть смысл поизучать. Если проект взлетит, будет очень много востребованной работы, хотя бы по переписыванию нужных приложений с других платформ.
Теперь уже модно писать на react-next. И переписывать придётся очень и очень и очень много (
Docker существует уже 10 лет, по-прежнему цветет и пахнет, и никто от него не отказывается...
ну как сказать, kubernetes, например, отказался, а это показательный пример
А что теперь модно использовать вместо докера?
Пока в живой природе ничего кроме докера в качестве средства "недовиртуализации" я не видел. А полноценная виртуальная машина тут вроде как перебор получается. Или я чего не понимаю?
Нуууу, вопрос терминологии.
Для создателей OCI-совместимых образов не изменилось чуть менее чем ничего. Как писали докерфайлы, так и будут писать.
А исчезновение докершима и замена containerd на cri-o для рядового потребителя не особо видна, вроде.
Реакт был ООП подобный , сеичас функциональный. Перемены есть. И они скорее всего цикличны. Из ООП в функциональный и наоборот.
Вам в модный тэг #выгорание.
А вот у меня другое ощущение от текста. То что я прочел свидетельствует о мудрости автора и осознания суеты сует! Вероятно, пришло время засесть за докторскую или мемуары, или заняться еще чем-то "в вечность" -- пойти преподавать, например, в школу.
поверьте, докторская тоже - суета сует, и проблем не решает, и уже тем более - преподавание. Проблема в том, что автор работает на дядю, а с такими проблемами пора заводить свой стартап и заниматься искусством ради искусства.
Скорее похоже на усталость, потерю собственного драйва и интереса, которая ведёт в консервацию "хочу как раньше, раньше было классно".
Если в таком состоянии пойти преподавать или писать книги, то в них будет написано ровным счётом одно: "как же раньше было круто, почему сейчас всё стало не так, куда катится мир!"
Таких преподавателей мы видели, и это печально. Учитель без искры в глазах, не заряжающий на рост, а брюзжащий, что ученики глупы и ничего им не нужно. Препод, который классно знает свою тему, но не может передать свои знания ученикам, а только демотивирует молодое поколение.
Куда лучше поискать, где там завалялся твой драйв, и пойти зажигать других тем, что нравится тебе.
При этом всё равно можно и нужно быть несогласным с полезностью ряда вещей в современном IT, это называется "иметь позицию". Но только не когда вся твоя позиция - старое как мир "раньше было лучше".
пойти преподавать, например, в школу.
А можно не надо, а? Он же детям в голову ровно этим и будет срать, а им еще жить потом в современном мире.
выпускник 3-месячного буткэмпа знает больше, чем я, несмотря на мой опыт
Заранее извиняюсь, но если интерн реально знает больше человека с опытом, то это человек не с опытом, а с потраченным временем. Опыт - он ведь по большей части в умении видеть в новом знакомые паттерны и вообще понимать, откуда и куда мы движемся. Если это в инженер есть, то он не будет говорить "зачем нужна кафка и котлин, если мы и на сях огого как писали". Как раз с опытом становятся видны резоны внедрения новых технологий, и так же их сильные и слабые стороны.
А кто вас завернет? HR которая не увидит C++20 в резюме? Потенциальный коллега который сам относительно недавно перешел на новый стандарт? Или на собеседование специально прийдет C++ буквоед и завалит вас каверзными вопросами по стандартам? Командам обычно нужны люди которвм можно поручить задачи, с деталями стека, библиотек, проекта всеравно прийдется знакомиться. И стандарт языка тут зачастую совсем не главная сложность.
Не дело HR — решать, что в проекте важно, а что нет. Если у компании такой HR — вам вероятно туда не надо.
Буквоед? Ну значит этому проекту видимо люди не нужны. Вам туда тоже не надо.
Ну то есть, эти сценарии — они реальные, но не страшные. Они с большой вероятностью показывают, что вам с этой компанией не по пути.
HR должен проверять соответствование кандидата требованиям. Если в требованиях к вакансии написано именно C++20 - не ему решать, годится чел со знанием C++11.
Один из моментов, который понравился ге сейчас работаю, HR делает только первичный отбор (достаточно широкий) кандидатов и передает резюме в команду.
Дальше уже команда решает кого собеседовать, кого нет. HR организует встречу, но собеседование только с командой. Тот кандидат, кого выбрала команда, уже "уходит" к HR который организует прием на работу до момента "встретить в первый день и привести на рабочее место".
Т.е. HR решает все оргвопросы, но в технических участия не принимает.
И собеседование только одно - с командой. Достаточно неформальное, без тестовых олимпиадных задач. Просто поговорить - чем занимался кандидат, чем занимаемся мы. Понятно, что могут быть какие-то технические вопросы, но не "на засыпку".
Все равно готового человека на эту платформу практически нереально найти. Так что первые три месяца будет обучение с наставником (формально - испытательный срок, но с полной оплатой и это больше чтобы понять сработаемся или нет, научить азам, ну и самому человеку понять что к чему)
Именно так. У нас другая платформа, но примерно такой же подход. Готовых специалистов практически нет в живой природе.
У нас IBM i и RPG (на котором пишется более 80% кода под эту платформу). Готовых разработчиков в стране... Ну сотни три-четыре. Может пять. И все они так или иначе трудоустроены.
А платформа ну очень специфическая, радикально не похожая ни на что другое. Много тонкостей и особенностей на понимание которых может уйти год-два.
А требования к качеству и эффективности достаточно высокие - система высоконагруженная и при этом много задач класса mission critical.
Так что выход один - искать человека с хорошим опытом разработки и обучать самим.
Если там делов разобраться-то, сядьте вечером, почитайте список изменений, и допишите C++17 в резюме. В эту игру могут играть двое :D
Автор же не пишет, что он не может разобраться. Он пишет, что его достало количество "штук", в которых надо дополнительно разбираться.
Выскажусь с позиции человека, который в разработке просто "мимо стоял" - а нафига нужно новое, если оно не исправляет ошибок или не ускоряет/упрощает работу старого?
Это будет пустое заучивание, без прогресса в использовании. Этак можно IF менять на FI, а else на esle каждые два года и говорить потом что это-то вот истинный прогресс, ёптэ!
Очень понимаю автора, тоже в какой-то момент от кодинга стало воротить. После нескольких (на самом деле больше) тяжелых лет метаний, работы на нелюбимых работах и параллельного изучения математики успешно перекатился в data science. Теперь изучаю/применяю соответствующие алгоритмы, и математики еще столько что на всю жизнь хватит - вот где я нащупал свой интерес. К кодингу больше не отношусь серьезно, просто применяю в работе, а так чтоб прям сесть и изучать язык или фреймворк - да ну нахер эту скукоту, я просто осваиваю это в процессе работы надо задачами.
>> После нескольких (на самом деле больше) тяжелых лет метаний, работы на нелюбимых работах и параллельного изучения математики успешно перекатился в data science.
Что конкретно вы используете в DS ? Статистика ? А что еще там вы используете? Интересно просто.
>> Теперь изучаю/применяю соответствующие алгоритмы, и математики еще столько что на всю жизнь хватит - вот где я нащупал свой интерес.
А какие алгоритмы если не секрет?
>> К кодингу больше не отношусь серьезно, просто применяю в работе
Вы используете Python?
Что конкретно вы используете в DS ? Статистика ? А что еще там вы используете? Интересно просто.
В первую очередь статистику, да. А так-то в ML-либах под капотом много чего зашито: линейная алгебра, оптимизация например. Спускаться до них обычно не требуется, но иногда нужно (да и интересно просто, если время позволяет).
А какие алгоритмы если не секрет?
В первую очередь классический ML: линейную/логистическую регрессию, KNN, разные виды кластеризации (k-means, DBSCAN), понижение размерности (PCA) - это первое что вспомнилось. Сейчас вот нейросети изучаю и пробую применять. Плюс много работы с временными рядами, они дают свою специфику.
Вы используете Python?
Да.
Всё правильно говорит автор. С такой проблемой каждый айтишник сталкивается, особенно разработчик. Угнаться за всеми требованиями невозможно, да в этом и нет смысла - всё равно будешь далеко позади. Вообще непонятно - куда так все торопятся в плане разработки? Обогнать конкурентов? А дальше что? В итоге копится нехилый технический долг плюс дикая усталость наравне с выгоранием и отсутствием мотивации.
А я вот не понял причину плача. Почему-то константой считается необходимость скорой смены работы. А почему собственно? Что мешает оставаться на полюбившемся проекте и развивать его с помощью полюбившихся инструментов, обновляя их строго по мере необходимости?
Ну а если реальная необходимость переходов есть, то изволь соответствовать требованиям тех кто рулит в тех местах.
По-моему, всё просто. Не?
Хочу жить как человек, а не сидеть за компом 24/7, чтобы оставаться в теме.
Крипту не пробовали? :)
Если серьезно, может не 24/7, но мне интересна тенхо-струя.
Каждое утро - Хабр без фильтра. Иногда заминусованные статьи вполне интересны, просто иное мнение, а сейчас тепимость на плинтусе.
Каждый новый framework интересно оценить и сравнить.
Каждая новя технология увлекает новыми перспективами и возможностями.
В IT 30+ лет, и это не ageism, а объяснение что для меня IT работает.
Да, ежедневный зал - обязательно. Иногда дважды в день, иначе здоровью кирдык.
Принципиально не трогал Докер много лет, не хотелось вкладываться во что-то, не понимая, что оно дает. Прекрасно себя чувствовал всё это время. Потом в какой-то момент все же разобрался, стал чувствовать себя ещё лучше. Теперь докер почти такой же дефолтный инструмент для любого проекта, как git. С кубером недавно решил разобраться, тоже оказалось довольно полезно.
Я к чему. Не хочется — не надо. Придет время или крайняя нужда — познакомитесь.
Опасная идея. Я вот недавно работу искал, так когда хрюши узнавали что я ни одного микросервиса не написал — отказывали сразу же.
Вы хотите понимания технологий от HR, которая делает скрининг по ключевым словам? Понятно же, что это просто первичный фильтр, который надо просто пройти. Странно на это обижаться / удивляться этому. У нее в работе тоже, наверное, есть нюансы, которые ей очевидны, а вам - нет...
Смотря что они сами понимают под микросервисами. Если на экспрессе возвращать джэйсончики, то это другое.
Вот и хрюши считают что это другое. В смысле, "на экспрессе возвращать джэйсончики" и "на экспрессе возвращать джэйсончики в микросервисе" — две совершенно разные задачи, и программист который никогда не занимался второй — им не нужен...
В следующий раз скажите им, что писали такое. Потому что интересно какой будет тогда следующий вопрос. Хрюши могли бы сразу стек назвать, чтобы время не тратить ни свое, ни Ваше. Потому что на практике еще неизвестно как у них там дело обстоит.
А так, скорее всего должны спросить о контрактах, каким образом осуществлялся обмен данными между микросервисами, синхронная или асинхронная архитектура, как осуществляется e2e тестирование, как организована безопасность. Ну, это я фантазирую :)
Вопрос как к разобравшемуся с Docker: чем это лучше chroot или systemd-nspawn? Использую последние два в работе. Почитал про Docker и не понял, зачем оно мне.
У докера есть репозиторий (dockerhub) и докерфайлы, которые позволяют описать процесс создания образа с нуля и положить его в гит. И ещё есть docker compose, позволяющий декларативно описать частично изолированную группу контейнеров, что сильно помогает при возникновении желания "потрогать" фичу до слияния в основную ветку.
Я так полагаю, что docker compose это набор bash/python скриптов? Репозиторий есть и для контейнеров systemd. А какие-то фундаментальные различия есть? Я сходу не нашёл, как в Docker настроить сеть между хостом и контейнером с различными уровнями узоляции.
в Docker настроить сеть между хостом и контейнером с различными уровнями изоляции
Вряд ли. Это для изоляции процессов скорее. На nftables наверное можно наваять то что нужно.
Нет, docker compose это вообще не набор bash/python скриптов. Проекты compose декларативны, скрипты императивны.
Что же насчёт сети — что вы вообще вкладываете в понятие "уровня изоляции сети"?
чем это лучше chroot
Приблизительно всем. В смысле изоляции от chroot мало отличается. Но если нужно масштабировать за пределы localhost - chroot категорически не годится.
Хотите сказать, что если я сделаю образ файловой системы, затем смонтирую этот образ на каждый узел в сети и запущу chroot, то это в корне будет отличаться от использования Docker? Что насчёт systemd-nspawn?
Во первых это самописный костыль, который нужно запилить и поддерживать. Во вторых, uid/gid файлов внутри chroot должны одинаково соответствовать uid/gid на каждом хосте - очень желательно чтобы все хосты были одинаковые. А вносить изменения в это будет совсем интересно ;)
docker - установил, работает. Всё ;)
А может вам и не надо в ИТ? Не надо программировать? Как бы это вам сказать, если человеку нравится бегать. Улучшать свои показатели в беге, то вопроса, а зачем нужны упражнения СБУ у него не будет! В программирование надо идти, когда тебя от всех этих "шестеренок" прет и не важно, что шестеренка1 похожа на шестеренку2 изученную ранее. Понимаете? Занимайтесь программированием ради самого программирования!
А может вам и не надо в ИТ?
Птичка Автор уже внутри ИТ :) Не исключено, что на синьорской позиции или типа того. К нему, похоже, пришло понимание, что количественный рост (профессионализма) достиг фазы насыщения (пресыщения), а как расти качественно, он пока не вкурил, и в его окружении подсказки ждать не от кого. Об этом и сказ.
Хочу жить как человек
Так люди так много не зарабатывают.
Так и в чем проблема, если у всех модных технологий под капотом все те-же "вечные" принципы? Наоборот ведь, хорошо: все должно быть знакомо, ничего не должно пугать... Любой UI-фреймворк - это компоненты, шаблоны, привязка данных, контроль жазненного цикла... Какая разница, для опытного инженера, как оно там называется?
Мне 44 года, я, можно сказать, уже динозавр в веб-разработке, но меня вообще не беспокоит динамика изменений. И даже наоборот, я вижу, как многие вещи взрослеют и становятся, наконец, такими, какими они должны быть. И за этим приятно наблюдать.
Какая разница, для опытного инженера, как оно там называется?
До опытного инженера вы просто не дойдете. Эйчарша не пропустит — не увидит знакомых буковок в резюме.
В MAANG никого не волнует какой там у вас стек в резюме и опыт на модных технологиях.
Сможете рассказать содержимое книг от Таненбаума и Кнута и прорешать литкод задачи на харде с ходу. Будет вам работа на 200-300к долларов в год. Нет Ну значит вы свои инженерные навыки глубокого computer science явно переоценивайте и проблемы не в Эйчарах
Попасть на собеседования в такие компании легче легкого. Пройти алгоритмическую часть, вот тут большинство сыпется. Но потом жалуются что "Я инженер с 30 годами опыта и не хочу учить модный стек"
Многие из нас начинали просто с изучения HTML, CSS, JavaScript. Не было фреймворков, хватало знания этих трёх фундаментальных технологий для написания сайтов. С ними ты мог создать что угодно. Теперь же потенциальные работодателя от тебя требуют знания (и опыта работы!) с Vue.js, React, Angular, Svelte, Webpack, Tailwind, и ещё с десяток какой-то ерунды.
Не ставлю под сомнение основной посыл статьи, но вот это вот сравнение некорректно.
Сложность современных фронтенд-приложений несопоставима с тем, что писалось тогда. Попробуйте сейчас на нативном JS, без фреймворков – будет очень больно и, скорее всего, закончится провалом.
Не согласен. Я вот буквально три месяца назад делал свой небольшой веб-проект.
Специально использовал чистый JavaScript. А до этого голый JS (+jQuery) использовал лет наверное 15 назад. И должен сказать новая версия языка приятно удивила. Очень многое можно уже делать на нем и не плеваться не привлекая сторонних библиотек типа jQuery.
Да и CSS изменился в лучшую сторону.
В общем сделал на голом JS все и доволен результатом.
Правда и проект небольшой и есть опыт/понимание как нужно код и данные размещать.
У меня там 5 экранов. С небольшой интерактивностью. Проще и быстрее на JS это запилить в 7Кб, чем тянуть фреймворки.
Я стараюсь использовать принцип минимализма и не усложнять решение без нужды.
Инженерный подход. Жму лапу.
Согласен с вами. Уже достало каждый раз при открытии сайта, у которого контента на 2-3 страницы и больше никакого функционала, видеть размер его в 30+ мб и это без картинок… А вообще непонятно почему в современном вебе вся верстка до сих пор передается строкой!? Если бы это компилировалось, то занимало бы раз в 10 (а на крупных проектах еще бОльшая разница) меньше места. Да и работал бы js быстрее через байт код, условный, а не через «читаю - исполняю».
Чего там такого на мегабайты? Я недавно делал проект на Angular + Bootstrap, как раз на несколько экранов. В собранном виде около 300 кб. Остальное-то что? Неужели столько сео-шной хрени? :)
Ну вот вы прям каждый раз сидите с открытыми девтулзами и смотрите размер загружаемого бандла? Я могу понять, когда человек уехал куда-нибудь в лес и там медленный интернет и сайт грузится одну минуту. Но в городах интернет уже вроде бы достаточно быстрый и особой разницы между 7КБ и 30МБ не замечаешь.
Например в B2B, где не нужны немыслимые анимации, поблескивающие кнопки, тени в три экрана и прочие свистоперделки — легко и непринужденно.
Ну что ж... Я бы советовали все-таки искать что-то более низкоуровневое и более стабильное.
Предложений не сказать чтобы на каждом углу, но их есть. Всякие системные вещи (преимущественно по Linux) сейчас поднимают голову. Из того, что мне предлагали в последнее время:
разработка сетевых приложений и модулей ядра, обрабатывающих сетевой трафик под Линукс
разработка аналога Active Directory на основе SAMBA под Линукс
работа с ПЛК в области нефтегазового сектора
ну и еще что-то подобного плана. Везде С/С++, много где Линукс на уровне системы. Минимум фреймворков.
Уровень оплаты... Ну так скажем не нищенская, где-то в середине рынка, хотя и не топовая. Но проекты точно не рутинные - многое с нуля и вход в проект на начальном его этапе.
Ну или посмотреть какое-нибудь легаси типа банков (только самый нижний слой - центральные системы, то, что работает на уровне ядра АБС на центральных серверах - там не будет фреймворков, зато будет много замороченной бизнес-логики с высокими требованиями по производительности). Правда, там могут оказаться специфические языки всякие. Лично я оказался именно в этой области (попал можно сказать случайно, но затянуло - оказалось что это реально интересно - и платформа специфическая и язык основной, хотя и С/С++ тут тоже есть, и каждая вторая задача - головоломка в плане "как сделать это еще быстрее и эффективнее").
Или обратить взор в сторону промавтоматизации. Но там, говорят, платят совсем немного. Но скучно точно не будет.
Короче говоря, искать себе интересный проект. Да, придется поискать, но найти можно.
Да, согласен. На так давно было про это. Так что это последний вариант, наверное.
Я в свое время отдал этому значительную часть своей жизни (Система Мониторинга Инженерного Оборудования Зданий) - было безумно интересно т.к. начинали в 93-м году, абсолютно с нуля (в стране не то чтобы аналогов не было, не было даже идей что такое возможно как-то). И по деньгам некоторое время было неплохо. Потом по деньгам застопорился рост, какое-то время на энтузиазме и гордости (столько времени потратили, не гоже бросать) держались, но в какой-то момент довели очередную версию до прома и решили что все, хватит.
Случайно попал в банк (хотя этот вариант не рассматривал вообще, но позвали сами, решил просто сходить на собес, что называется, "жалом поводить" и вдруг понял что хочу). И зацепило. Да, дремучий легаси, да никаких фреймворков (кроме тех, что сами себе сделали), да, кровавый энтерпрайз.
Но при всем этом очень необычная и интересная возможностями (низкоуровневыми в том числе) платформа, достаточно интересный язык (процедурный, типа классического Паскаля на первый взгляд, но когда зарываешься в него глубже понимаешь, что там очень хорошо развиты возможности описания структур данных и это достаточно мощный язык для разработки бизнес-логики при всей его внешней простоте).
Поначалу, конечно, достаются рутинные задачки. Те, что делаются по стандартным шаблонам (скелетонам, как их тут называют) - берешь готовый шаблон, переименовываешь, наполняешь нужными структурами и переменными и готово.
Но потом начинают подкидывать уже реально интересное и нестандартное. Обычно такое, что требует разработки высокоэффективных алгоритмов и предельной оптимизации. И тут уже надо разбираться - можно так, а можно этак, но вот так будет работать быстрее. Там можно вместо двух циклов в один уложить, здесь что-то закешировать на входе один раз, потом из памяти тянуть. Где-то быстрее прямым обращением к таблицам БД, а где-то скулевым запросом (язык позволяет скули непосредственно в код интегрировать). А где-то комбинируешь - быстрее не втаскивать в скуль всю логику с различными group by и агрегатными функциями, но сделать его попроще, а данные уже просеивать в процессе обработки... И приятно видеть когда выкидываешь старый модуль, который 30 секунд работал, пишешь свой и видишь что он то же самое делает за 3 секунды...
Но потом начинают подкидывать уже реально интересное и нестандартное.
...а потом в личке объявляется эффективный менеджер и заявляет "ты написал в джире что потратил целых 8 часов на старинную задачу на которую три года все забивали!!! мы не можем столько платить!!! укажи там два часа и больше никогда не пиши столько!!!"
Не далее чем в апреле с таким столкнулся...
Хотел конкретно изучить Docker, но уже поздно - он больше не в моде, теперь же есть Kubernetes, Ansible, и ещё чёрти сколько технологий, которые я никогда не изучу.
Хотел я научиться плавать, но смотрю что гироборды больше не популярны. Если что, k8s/ansible не имеют особого отношения к Docker
Да, появляется много чего... Однако опыт как раз и нужен для того, чтобы сравнительно быстро понять, для чего эта штука придумана и стоит ли тратить время на её изучение? И вдруг выяснится, что в интересующей Вас области не так много и происходит...
Тут два решения - внутренее и внешнее (условно)
Решение "внешние" - выбирать не технологии которые меняются раз в 3 года, а выбрать какой-нибудь rust, или go, которые будут еще десяток лет спокойно и неспешно разиваться.
Решение "внутренее" состоит в том, чтобы перестать циклиться на том на чем написан продукт и думать о продукте, фичах и как его развивать. Для этого лучше работать в продуктовых компаниях. Тогда пофиг на чем писать, а если и захочется новый фреймворк, то с позиции "ту фичу которую я дебагал тогда 2 недели теперь можно за пол дня написать". Совсем другая мотивация для изучения чем "теперь надо что-то новое".
Многие из нас начинали просто с изучения HTML, CSS, JavaScript. Не было фреймворков, хватало знания этих трёх фундаментальных технологий для написания сайтов. С ними ты мог создать что угодно. Теперь же потенциальные работодателя от тебя требуют знания (и опыта работы!) с Vue.js, React, Angular, Svelte, Webpack, Tailwind, и ещё с десяток какой-то ерунды. И с каждым днём кажется, что ты отстаёшь всё больше.
Ну хз. Не мог тогда создать все что угодно. Все убогое было. Netscape, IE6, Opera, фреймы всякие, верстка на таблицах, Ajax с горем пополам через long polling, Perl, PHP 3, CGI, RealVideo, Adobe Flex. Современные веб-технологии дают в сотни раз больше возможностей. Наоборот, есть ощущение, что с каждым днем можешь все больше с новыми инструментами.
Да не беспокойтесь вы так, не надо никуда спешить, скоро программистов заменит ИИ и спешить придется лишь в очередь за пособием по безработице.
Согласен, это так заэбало, уже год как в веб разработке. А уже с такими же ощущкниями
Я думаю, что автору надо не язык разработки менять, а сферу, либо пообщаться с коллегами на эту тему.
У меня есть знакомые сеньоры, они делают типовые задачи, с которыми джуны и мидлы могут провозиться пару недель, за 1-3 дня. И им тоже скучно всем этим заниматься. Поэтому они ищут себе не работу с высокой зарплатой, а работу, которая им интересна. Т.к. зарплата на их уровне и так высокая. И они даже не пытаются изучить абсолютно все. Зачем им знать вью или новомодный го? Достаточно лишь обзорно ознакомиться с ним, чтобы иметь представление что это.
А вот к чему они стремятся, так это к интересным им задачам. Кому-то нравится лидить и обучать других, помогать менее опытным коллегам, кто-то уходит в анализ данных и машинное обучение, кто-то в прикладные задачи (например, сельхоз дроны, компьютерное зрение и т.п.). В общем, каждый ищет себе свой интерес. А само программирование это лишь навык, позволяющий решать эти интересные задачи.
Ещё бы добавил, что навык программирования универсальный и это даёт преимущество в скорости изучения новых языков, фреймворков и, уверен, даже докера и кубера(на уровне пользователя). А вот зачем разработчику ansible не понял, такое обычно только админам нужно.
Ещё состояние когда пытаешься за всё хвататься и ничего не успеваешь похоже на FOMO(Fear of missing out;) - прямой путь к выгоранию.
Пятничный вызов] перекур. Надоело программировать
так ответил в бюро пропусков привлеченный из-за периметра соискатель на сезонную позицию слесаря МСР по сборке изделий тройного назначения.
!?
Ну, тыж со своим С# и С+ по деньгам просядешь!!
Ну и что, говорит, -- зато руки от Клавы и мыши, да глаза от компа отдохнут.
ЗЫ: ничто, что со своими метизации побрегсад?)))
Ну почти, вывод немного неверный. Вообше нужно называть все своими именами. Никакого культа знаний нет, в реальности это способ создать нервозы, никакой команды и семьи нет, есть коллективная ответственность, никакой инженерии нет, есть капитализм. Никому не нужен софт, точка, нам насрать на всех, точка, нам нужны бабки, точка.
Конечно айтишников это все раздражает люди которые намного глупей их, неспособны вообше что либо создавать паразитирует на труде айтишников. Все эти эйчарки и менеджеры в реальности обсолютно не нужны. Почти каждая эйчарка это девочка 18 лет которая отсидела в педаузе или международном праве, ну или в языках.
Их прибавочная стоимость смехотворна. Большинство из них были наняты из за вешности.
Менеджеров не знают даже азов управления, из разряда задачу нужно делать на независимые и тд и тп Всё что они делают это паразитруют.
Тоесть меня нанимает какая-то гуляшая кукла, а управляет алигофрен "ну че там?".
Причём, если начать работать как следует, за каждым предложением имя, у каждого внедрения ответственный, за каждый факап наказывать. Мы уволим просто треть. Но в реальности, они не способными применять к себе же свой подход, потому что, изначально не хотят работать, их цель паразитация на чужом труде (сиди получаем деньги, пока эти мартышки пашут).
Большинство фирм это веб галеры - современные конвееры 21 века, а большинство программистов это обезьянки. Добро пожаловать в Sity 17. Скоро все буду за миской риса пахать за 500, пока не помрут как та тестировшица. Просто имх, наивные пони айтишники, которых капиталисты вместе с ХР шоблой и магагерами посадили на цепь как животное и доят
P.S. Никуда не нужно торопится, перерабатывть, получать копейки.Берегите себя, своих близких и свое здоровья. Разговаривать и играть в их игры не нужно, щуллер всегда обманет. Бейте на упражнение первыми как видите, что вас собираются поиметь.
И да, не верьте коммунистам и либералам, они нас обязательно придадут, просто берите свое силой
Это словоблудие, обман и шиза, зарплата одной хрюши примерно как у мидла 3к, загон обычно состоит из 3 голов, отсюда они за 8 месяцев закрывания сожрут несоизмеримо больше, чем просто мидла на месяц посадить разобрать всю эту стопку и нанять кого. Хотя в реальности, если поставить цель нанять и расширяться, это решается за 4 дня.
Да, за 8 лет ещё ни одного не встретилось. Вечно они нихуя не понимают, вечно за ними все нужно доделать, вечно у нас делайны, любые неудачи это вы дураки там понаписали чего-то, не оценили верно, не спланировали или еще че. Пока они сверх бонусы получают, летают в Дубаи нюхать кокос, и ходят с шлюхами по блокчейн митапам. Вот и вся суть этого вашего айти, а разбираться в сортах я очень устал, поэтому они мне все враги, как все слабовики. Тут же дело какое, я уверен были и нацисты которые в печи вели и думали, что они нивиноватый.
это решается за 4 дня
Любая работа выглядит простой, если ее делаю не я ;)
Код писать тоже ничего сложного, нажимай себе кнопки. Это не мешки ворочать.
Такого товарища забанили, эх...
Это где для хрюш такие шикарные условия? Срочно поделитесь названиями мест, я своим знакомым HR передам, они будут нереально счастливы иметь такие деньги.
За 3 не встречал, но за 1-1,5 полно, причем обычно по блату нанятые. Причем их работа не стоит даже этих денег.
А миддлу это нахрена надо? Миддлу интересно код писать, а не с кандидатами созваниваться и емайлы целый день строчить.
Я так понял, что созвоны все-таки на эйчарах, а мидлы должны резюме читать и первичный отсев осуществлять. Я тоже так считаю.
Вот эта фраза говорит о том, что вы не имеете вообще ни малейшего представления о том, как обстоят дела в реальности
Так в реальности обычно директор видит, что команда постоянно не успевает и дает указание нанять рокет-сайнса за 3 копейки. Пока эйчары проверят гороскоп каждого кандидата проходит месяц, потом они смотрят чтобы буквы в описании стека совпадали и т.д. Эйчары вынуждены затягивать процесс найма, иначе для всех станет очевидным, что в таком качестве и с такими з/п они просто не нужны.
Резюме – зависит от количества. Если их много, то опять-таки лучше, если эйчар их просмотрит и сделает выжимку
Это как? Резюме — это и есть выжимка. Если же эйчар должен выбирать среди разных резюме, то он должен пропускать их дальше по минимальному совпадению. Иначе это приведет к сверх-дорогому поиску иголки в стоге сена.
Мидлы могут читать резюме, если лид им это поручит
Я думал, что это подразумевалось предыдущими сообщениями в этой ветке.
Судить обо всей профессии по паре-тройке знакомых "блатных" – ну такое
Смысл не в блатных, а в том, что любой эйчар заинтересован в усложнении процедуры найма (впрочем как и любое другое подразделение заинтересовано в повышении своей значимости). А уже на завышенные з/п в эту сферу и идут знакомые знакомых.
Если рутина убила интерес, то все проблемы, - в недостатке мотивации. Я бы выбрал ту сферу, где профессиональные амбиции, желание и мотивация будут превалировать. Благо, сфер много!
Привет, как я тебя понимаю :)
Раньше сам программировал игрушки на С++/С# (комп графика, OpenGL, D3D, AndroidNDK, PhysX, Bullet, Newton Dynamics), но рыночек заставил изменить профиль. Плюс поменялись инструменты (появились Unity, UE4) + при пересчете трудозатрат на денежную выгоду я понял, что на С++ смогу себе заработать только сердечный приступ :)
>Хотел конкретно изучить Docker, но уже поздно - он больше не в моде, теперь же есть Kubernetes
ну как бы k8s использует внутри себя Docker и решает он внутри себя другие задачи. k8s - осуществляет управление docker контейнерами и zeroDownTime.
Есть docker swarm для этой задачи, но он для прода не очень годится (тема холиварная)
> А все эти «опыт работы с Golang от 3-х лет» меня очень раздражают (можно подумать там что‑то такое сложное, что аж нужно 3 года учиться)
После опыта в C++ вкатываешься очень легко, но переходя со стека на стек я внезапно наткнулся, что структура проекта тоже регламентирована (название папок) гайдлайнами. Тоже справедливо даже к синтаксической записи.
Ну и обычно — требуют знание каких-то общих библиотек, реализующую конкретную функциональность
Общий опыт на С++ помогает тут очень, но любой 'новый' язык — это своя экосистема
java 8 one love
Хотел конкретно изучить Docker, но уже поздно - он больше не в моде, теперь же есть Kubernetes, Ansible, и ещё чёрти сколько технологий, которые я никогда не изучу. А раньше было достаточно просто знаний администрирования Linux...
Ха-ха, у ТС фиксация на новых технологих почище, чем такая же фиксация у компаний, только в противоположную сторону.
Docker, Kubernetes, Ansible — это разные технологии, сделанные каждая под решение конкретной задачи. В чем проблема изучить докер сейчас? Ну да, не возьмут на работу, где есть задачи, требующие Kubernetes. Но ведь куча задач, где работает докер, будет доступна же, не?
Нет, будем ныть "чо вокруг все меняется", писать статьи на хабр, вместо того, чтобы локально поиграться с этими технологиями (это займет пару дней) и составить понимание, для чего они они нужны, какие проблемы решают и надо ли в это погружиться глубже. Проще, конечно, сказать что в наше время такого не было и отказаться от изучения просто по факту того, что они как-то слишком быстро появляются.
Изучайте то что не устаревает. Алгоритмы и математику вообще, компьютерсаенс. И не меняйте слишком часто работу, если возможно, что-бы не тратить время каждый раз на изучение всех этих модных технологий.
Это выгорание из-за ощущения бесполезности потраченного времени. Я тоже это когда-то ощутил, и с тех пор с энтузиазмом изучаю только фундаментальные вещи, а все эти технологиии только необходимый минимум для конкретной задачи.
Уверен, адекватные работодатели тоже все это прошли и совершенно адекватно относятся к не знанию каких-то технологий, но пониманию принципов подобных решений.
Вам нужно устроиться туда, где пилят один-два продукта высокой надёжности. Не знаю, набирают ли сейчас программистов у нас, но программно-технический комплекс диспетчеризации горных работ не переезжает с технологии на технологию раз в квартал. И раз в год не переезжает.
В первую очередь программист должен решать задачи бизнеса, а бизнес диктует такие условия. К сожалению.
я с этим столкнулся еще в 2001 году и просто тогда же решил не быть программистом, я безнадежно отстал за 3 года тогда и догонять просто не было желания. А в этом году я вообще поставил крест на ИТ и ушел в свободное плавание по совсем другому профилю - денег копейки, зато просто душевное спокойствие.
А больше всего я жалею что в 1992 году бросил кодить под 6502 ради х86.
[Пятничный вызов] Надоело программировать